James Carr

While I was reading through my RSS feeds today I came across a post by David Walsh describing how to make a link to set the current page as the users home page (bad feature) with the remark:

The unfortunate part about creating websites for customers is that no matter what recommendation I make, if they want it, I have to give it.

I smirked a bit as I know I’ve implemented features customers have requested that I KNEW were bad features… but then I thought about it a bit, why do we continue to implement features for customers despite knowledge that such features are wrong?

The Customer is NOT King!

The common adage may be that “The customer is king.” but with software development nothing could be much further from the truth. The role of a software developer is to best realize the customer’s business needs via software. This may even go further for web development… a businesses website reflect their image and brand worldwide and with that in mind, poorly thought out features can tarnish that image.

Blindly following customer demands can be a quick and slippery slope to either project suicide or a bad end result. If we implement annoying and irritating features without questioning why, the customer may lose a lot of potential business. Further, I’ve been guilty in the past of accepting request after request of feature changes (because the customer is king) till the point the project either shipped incomplete or was aborted outright.

The Relationship Should Be Collaborative

As a professional, a developer should keep the customer’s best interest in mind and the relationship with the customer and developer should be collaborative rather than hierarchical. In my opinion, if a customer requests a feature that is ill conceived or that is known to be against proper design practices, say it! If they request blinking text to capture the visitor’s attention, tell them the truth… blinking text will irritate the hell out of any visitor and there are better alternatives for drawing attention. Don’t let them blindly dictate poor design decisions.

Work with your customer… find out the why of their feature request. Finding the true root of what they want can allow you to give them better alternatives, or even drill down to what they really want and avoid numerous feature changes in the future. Remember it’s all about collaboration!

So Now What?

We’ve established that the relationship with our customers when developing software should be collaborative, that we should work with them to create the best possible solution. However, I still can’t help but question… why do we continue to implement bad features our customer requests?

I guess in the short run, we just want to get paid. What do you think?

Recently I’ve been pondering my biggest pet peeve, the biggest burden on my productivity… the dreaded meeting. Or as my favorite QA Jacque calls them, the “M word.” Meetings (pardon my language) are the biggest mind number sometimes. I hate them. Everytime I’m getting productive or about to have a major breakthrough, a meeting takes place that crushes my dreams of accomplishing something. They’re that awkward event that you cannot live without yet can completely drain energy from a developer. Why???

The problem is having meaningful meetings… how often have you found yourself in a meeting that started strong and then quickly dwindled away into a horrible nightmare of empty talk of process or other boring things? I know I’ve attended several that I just kept screaming in my head “please someone just kill me now!” as I watched the clock tick from 2:30pm to 4:30pm. There’s even the time I attended a meeting on “time waste” that really felt like a big waste of time. ARRGGHH!!! It makes me want to pull my hair out!

Of course, as a developer you can’t just sit and code all day long every day (even though that would be absolute bliss) and meeting with customers isn’t just an option, but a requirement. So how do we keep them from being so boring? In my opinion, make every meeting a stand up meeting… no chairs. And no I don’t mean your morning stand up… I mean make EVERY meeting a required stand up, people standing will want to get done ASAP so they can go sit back down, right? Keep it to the point… remember it’s possible to compress any conversation to an absolute minimum by cutting out the cruft and focus on what’s important. It takes work from both customers and developers though.

Developers, be to the point. Discuss business logic and ask for clearification, but please don’t expose technical details. Your customer doesn’t need to know you’re using Very Crappy Fake MVC Framework^TM or that you’re storing data in Even Crappier RDBMS^TM! Would you really like to hear irrelevant details from your customer about product marketing, business processes that don’t even involve you or the software you’re developing for them, or specific procedures used by the legal department ? Of course not! Such details may be involved in their work, but it has nothing to do with you… so why do you think that such details in your work matter to them? Focus only on the relevant details and business logic they care about, not irrelevant techno babble to make their eyes glaze over!

Of course, I don’t really have the answers to everything, and I don’t portray myself as such. I’d just like to say that developers take pride in being creative and accomplishing goals versus spending insane amounts of time in long drawn out meetings. Even worse if it’s a meeting with other developers arguing about god knows what. Ideally, you should converse with your customers so much that the need for in room meetings are seldom and when they are required are short, quick, sweet, and to the point. Just keep it simple!

Only a mere five days from now I’ll be attending the NFJS Gateway Software Symposium for the 4th time… and I’m pleased to say I’m quite excited. NFJS is one of those conferences that just has a knack for being fun, small, easily accessible, and very very educating.

The “educating” part however is the only aspect that has me a little worried, since this being my 4th NFJS conference I worry there may not be much new to see… and a quick initial glance at the sessions I easily spot many of the usual sessions they’ve had in the past… so what to do?

Without a doubt, I’ll have to attend Michael Nygard’s session “Failures Come In Flavors.” I actually had the pleasure of meeting Michael last year at the GSS Fall edition at the hotel lobby bar… from the discussion we had about software development I could tell the session would be interesting, but unfortunately missed it due to having to head back to Columbia early on Sunday. So I’ll be “making it up” this time around. Additionally, he is also giving another session titled The 90 Minute Startup that sounds pretty interesting too.

The session that stands out is Nathaniel Schutta’s Designing for Ajax (Part 2). Why am I only interested in part 2? One reason… one reason only… Google Gears. Google Gears is one of the most interesting things I’ve toyed with lately that sadly your average developer has no idea what it is (but should).

Anyway, feel free to hit me up if you happen to be attending. If not, keep an eye here as I’ll try to post some fresh content daily from the sessions, if not just quick notes on what’s going on. Hopefully I’ll have something enlightening to post!

if you happen to be near Columbia, MO around January 16th, feel free to join us at CARFAX for the Mid Mo XP usergroup meeting. This week we’ll have a very special guest speaker: Ron Jeffries, the author of Extreme Programming Installed and the owner of the XProgramming site.

The topic of Ron’s presentation is “The Dynamics of Software Development”, which Ron has described as

Using simple “chalk-talk” charts describing projects’ delivery of
features over time, Ron shows why “running tested features” make
management of software projects easier for everyone, and derives
the reasons behind the practices recommended as part of doing
Agile well.

Should be pretty interesting, and it will be the first time we’ve had a presenter that is well known in the XP community. Hopefully Ron will be the first of many more guest speakers to come (Gary and I keep posting open invitations to XP Mailing List regulars to come out and visit any time they want).

Uncle Bob recently made an interesting post on TDD and test generators, and I couldn’t agree more! I’ve always despised test generators myself, mostly for the same reasons Martin makes.

In my opinion, desiring to use a test generator on fresh code is an attempt to cut corners and bypass testing, which really is counterproductive. From my experience thus far, writing code test first has helped me write more loosely couple code, while both legacy code and code written test last usually end up being a tightly coupled mess. Even if you design nice, loosely coupled code and generate the tests for it, there is still the problem that the test generator is not really going to be smart enough to figure out your domain logic, and TDD is a helpful tool for expressing domain logic in the form of both test inputs/outputs and object behavior.

Like Bob mentions, it’s helpful to use generators to provide coverage for a legacy code base (especially when refactoring… I once spent a couple days writing tests around a legacy system to prepare it for refactoring!) but if you’re using them for a fresh code base, you’re of course not doing TDD… and you lose all the benefits you could reap from practicing TDD!

As an aside, I noticed he mentioned that 33% of the codebase for fitnesse was unit tests… I’d go further and argue that one should aim for 50-60% of their codebase being composed of unit tests! I’m just extreme like that.

Recently I’ve been following an interesting thread on the XP yahoo mailing list asking the question… should we measure individual velocity?

The general response seems to be “NOT AT ALL!!!”, but I won’t repeat the discussion there when you can read it yourself, but I thought I’d pick out an interesting point from the thread that was mentioned and expand on it.

Velocity is not a team performance metric, but a planning tool that
helps the team realize how much they can commit to a given iteration.

This seems to be a general point of confusion that always seems to come up and definitely bears repeating. From my point of view, velocity is basically a way of saying “the team completed on average x number of units per iteration the last y iterations, so the customers can expect x units will be completed next week. So, dear customer, with x units to spend this iteration, what features would you like to see implemented?”

Using velocity as performance metric is dangerous imho because it assumes that a team is either doing poorly due to a decline in velocity, or that a high velocity means a team is superb and probably deserves a hefty bonus. Rubbish.

Measuring individual velocity would be a disaster of epic proportions imho… it would go against the grain of teamwork first of all, since why would individuals or pairs feel motivated to ensure that the overall team does well velocitywise? Likewise, it would be a poor metric. If pair A completes 10 1 unit cards that were freakin easy (lets say each card was doable in a session or less) and pair B completes one 3 unit card and one 1 unit card that winds up taking awhile due to external factors, you can’t really sit there and say “pair A is a lot more productive than pair B, since pair B only completed 4 units. Maybe we need to do something to get them moving!”

Velocity is not about performance… it’s about providing your customer with a close to accurate amount of “points” they can spend on features this iteration. Remember that.

Lately (thanks to Spring) I’ve been toying with dynamic languages a little bit running on top of java. I haven’t delved into JRuby on Rails yet, but I have been using them as scripted beans injected into java classes, largely in a way that exposes an application API to either a scripted environment, or to take advantage of their dynamic features. I have always loved Groovy, Ruby, and Javascript for two things: closures and the ability to add methods to a class at runtime. Something strikes me as great being able to to code something like:

tomorrow = 1.day.from.now;

Being able to write code that is so expressive like that is somewhat satisfactory, and I like being able to quickly prototype ideas with out the painful build process JEE development always entails. Let’s face it… JEE development is sometimes overly complex. Maybe we overcomplicate things by making or programs too abstract. Maybe we just need better “killer frameworks” to minimize the “plumbing work” (this is why I like Spring). Although the Ruby zealots will brag about what a breeze development is, imho they miss the point that the reason it’s such a breeze is because Ruby on Rails takes away all the boring work. Recently I almost felt like JEE is getting close while doing a Stuts 2 + Spring 2 + JPA + AJAX tutorial. Maybe we need Spring on Rails.

I don’t know… maybe I’m rambling, maybe Dave Thomas, Bob Martin and all are right saying “Java is the new COBOL.” Maybe JEE just needs to adapt to keep up with high paced development.

One thing is for sure… each time I use scripted beans with JRuby and Groovy to quickly prototype ideas I can’t help but think to myself, “Why not just write applications like that?”

Fear is quite obviously the worst emotion that any developer (agile or not) can succumb to… the fear to try new technologies, the fear to try something out, the fear to speak up, etcetera etcetera. The list goes on. In my honest opinion, fear is the one driving force that can break a development team and cost stakeholders time and money.

The fear to just “try it and see” would have to be the biggest one… and possibly the one I think is a root problem of any software development effort. We do “spikes” in XP for this very reason… so we can try something out and see how long it would take before giving our customer an estimate. Maybe it’s just easier than we thought it was, maybe not… either way, to just simply “try it and see” we are able to confidently tell our customers “X feature will probably be about 2 units of work” rather than muttering to ourselves “I have no idea how much work that could be, but it’s probably a lot!” and telling the customer that “X feature would probably be 12 units, just to be safe.” Argh… those large unit cards of uncertainty!

Some may take a different route… rather than trying something different, they’ll stick with what they know. This can be fine most of the time, except in the case where “stick with what you know” is shoehorned ad nauseam to the point of ridiculousness. How many times have you came across a nice 20 branch if-else if statement (okay, it’s rare, but it can be observed)? Or rather than investigating pre-made solutions to technical problems cross cutting a program, one might instead opt to “roll their own.” Sure, inventing your own custom made low level logging system is fun, but is it really giving the customer their most value? Of course, there DO exist cases where you may need a custom logging system, but just for the sake of the argument. In short, you should stick to what you know if it’s reasonable, but don’t be afraid to think out of the box and try something different. A programming problem could take a pair an hour that might take another full team days (or even weeks) depending how the problem is approached! If you find an alternative approach to solving a problem, just try it and see!

Finally, never ever ever be afraid to speak up. If your team is making a decision you disagree with, speak up! If they disagree with you, make sure you convey the information behind the “why” you disagree with them. Further, make sure you always participate with your customers… ask questions when they meet with you, be inquisitive, collaborate. If you ever have doubts or questions about a particular story or feature, never be afraid to get them on the line… I think in the end they’d rather you “bothered” them for a few minutes than build the wrong thing. Of course, if they consider your calls “bothering them”, you might have other issues.

I guess what I’m getting at in this long post is that every developer should champion courage as one of their traits… a successful developer is fearless… unafraid of change, unafraid of new technologies, unafraid to try something different out, and unafraid of any doubts in their mind.

Remember… do what you think is right, have courage, and above all, don’t let fear rule your development decisions.

Ever wanted to know what an agile software development environment looks like? Curious how teams are usually laid out, or just frankly interested in agile themed photos?

I’ve formed an “Agile Software Development” group on flickr… feel free to check it out and even submit any photos of your own.

On a side note, Friday we had a professional photographer onsite taking photos of us working… I’m going to try and see if I can snag a few for the group.

Edit: Don’t get me wrong… I still stand by my motto to “Automate All Tests” … my viewpoint here is that sometimes you should use common sense if an automated test provides zero value.

In a previous post, I ranted that we should work to “Automate All Tests.” And I still stand by my original sentiment… as professionals, we should always strive to write as many automated tests as we can to ensure quality. One posted a comment asking “How about when not to automate?” Well, I think this iteration I finally came across the scenario in a project when you shouldn’t automate.

Part of this iteration we had a few cards related to changing the look and feel of a few pages on our site (which all contained forms) and updating some of the static text. We made our changes, uploaded the images, and tested across browsers and made sure everything still worked. Then our QA (who is also a little new) asked, “Shouldn’t we have some automated tests for this card?” I shook my head no. “But shouldn’t we try to automate tests for everything?”

I think this is the case where you shouldn’t… and I’ll explain why. For starters, the UI is always a volatile place that can change frequently.. writing tests around that ensures you’ll have broken tests in the near future. Second, what business logic are you testing? Like I said before, writing a test for static text is silly… there is zero effort in adding that text, writing the test would be more time intensive, and again your test will break next time the customer wants to change it (and FFS, TDD’ing text is really plain out silly). And finally, building off the last reason, the domain is what matters most… that’s why we spend much effort decoupling our view from the model so that we can test our model in isolation.

This is why I tend to really criticize Fitnesse fixtures like HtmlFixture or even Selenium to an extent (I have found a lot of GOOD use for that tool however)… the domain language of these tests tend to be very web developer centric (elements, ids, etc) and as a result largely focus on the UI so much that they completely ignore the domain logic happening behind the scenes. IMHO a test to make sure form fields are present is a waste of time. On the other hand, a test that fills out those form fields with different combinations of data, submits them, and verifies the expected outputs is a VERY worthwhile test.

Remember the key point is to ask yourself what benefit you gain from writing an automated test, and whether that benefit is worthwhile. For me, a simple gander at the UI and asking the customer to confirm it looks good is “good enough” and gives me time to focus on writing tests for and developing the domain layer more.

And the domain layer is the most important place in you application. Period.