My hovercraft is full of eels

A developer friend of mine asked me recently what he should do when he discovers that a feature he is working on looks like it's going to take longer than expected. Of course I recommended alerting the team lead, project manager, etc. "Well that's fine, but then they just tell me to do it in less time and I can't!" was his response, to which I replied "Of course you can, just take some short-cuts." My friend retorted "but I don't want to compromise the quality of the code!"

The problem here is that as a Developer he wants to write the best quality code he possibly can - irrespective of whether he is capable of doing so or not. His Project Director on the other hand has a deadline to meet. Unfortunately no one has made it explicit which one of these values is more important.

We all live our lives by certain values. When we do stuff, we make value judgements. We decide whether one thing is more important to us than another. Some people are aware of this others are not. Some people are acutely aware of their own values while others aren't. For some people these values are explicit while as for others they are implicit.

Projects are no different. In fact I'd say it is critically important that the values for the project be not only explicitely enumerated but also prioritised. If this isn't done, there exists too much opportunity for ambiguity. Ambiguity leads to conflict and conflict leads to the dark-side.

When we start any project - or restart as we have just done - one of the first things we do is to get the stakeholders in a room and prioritise the core values. Things like (honestly in no particular order):

• Time-To-Market;
• Within Budget;
• Customer Satisfaction;
• Adding Value;
• Functioning Software;
• Software Quality;
• Team Satsifaction;
• Stakeholder Satisfaction;
• ...

It can be tough to do and some people may be a little shocked by what they find out. In my experience for example, Team Satisfaction is almost always at-or-near the bottom with Software Quality hovering around the middle and Time-to-Markert and Within Budget right at the top. When developers see this they initially freak out. "What!? They don't care about us?"

No, they do care, it's just that if there's a choice to be made between you staying back to meet a deadlne and you going home to <insert favourite TV show and-or-computer game here>, then guess which one wins out?

Of course priorities can change and there are no hard and fast rules but if decisions are being made that would appear to contradict the agreed priorities then alarm bells should be ringing as clearly, more communication is needed to work out why.

I dare say companies ought do the same thing. When an organisation says that it considers employee satisfaction to be the highest priority, why not make it explicit? I don't know about you but rating employee satisfaction above say having everyone billable or customer satisfaction, is highly unlikely but hey, some organisations do tout themselves in this way. I'm sure some employees would be shocked to see the order of values that their managers have in their minds.

The fact is that it doesn't really matter what the priorities are so much as they are made explicit. Once everyone knows, then decisions can be made and, importantly, made with the full understanding of why and how the decision was reached. The alternative leaves people assuming and expecting things based on their own set of values. Allow people to make informed decisions.

So the next time you're asked to comprise, realise that it's probably because the decision is not being made based on your values. Instead, find out what values are being used. If it's on a project then put the responsibility back on to the person holding the purse strings to make that choice. It's not a choice you should be making nor one you should even be allowed to make. Then, get over it and do your job :)

Posted by Simon Harris at 04:55 PM | Permalink | Comments (5)

I'm more than a little amused at the current Rails versus Hibernate versus EJB3 versus whataver, debate that is raging at the moment. It's not that I don't mind a bit of argy-bargy. I think this kind of discussion is very healthy. I am a geek after all. I just find it all a little, well, tiresome sometimes. I probably wouldn't mind so much if the arguments didn't center around what is supposedly "best".

Mac users would argue that OS X is better than windows, though windows sales surely outstrip OS X sales by a few orders of magnitude I'm sure. BMW drivers would argue that even the bottom of the range BMW is better than say, a top of the range Toyota, though again, I'm sure that's not reflected in actual sales numbers. And then there is of course the oft-cited BetaMax versus VHS, IBM's MCA versus Intel's ISA. Motorcycles with Mick Doohan's name on them sell for much more than those without. The guy in the motorcyle shop will thus try and convince me they're better because they are "popular". Just because a piece of software (or anything for that matter) is popular, doesn't make it good. That is of course unless your definition of good is popularity.

Natural selection - and that's how I see this - doesn't necessarily choose the "best", it merely chooses the fittest and, unfortunately, the fittest may well come down to things like, documentation, sales & marketing, how many other people seem to be using it and, *gasp*, how many books there are on the subject.

Most of the time I hear the argument for using Struts (for lack of a better example), it's more about the fact that most people "know" struts and very little about whether it is good or not. In fact, my experience is that, while it is pretty easy to get going using Struts, it's also very easy to shoot yourself in the foot. To the point that I've rarely, if ever, seen it used well. That's not to say that it can't be used well, just that it usually isn't.

There are far too many factors that affect the software development process that go waaaaaaay beyond the technology and tools you use. I'll put my nuts on the line and say that most if not all project failures have little if anything to do with the technology (except as a consequence) and are more to do with the the failings of the people, the skills and the communication.

No, what I want to see is some empirical evidence that says, hey, we built a large scale app in whatever tool it is and look it performs well, the customer is happy, our defect rates are very low, we delivered on time, on budget, and the quality of our code is excellent. And I want you to prove to me that it worked BECAUSE of the technology and not JUST because it had some really good developers on it. then, perhaps then, I'll go recommending to a customer that they shell out a gazillion dollars to fund my latest passing interest in a tool I read about on the internet and became interested in because I was so bored with whatever tool I used on my last project.

And it's not even that I don't like the look of all these tools. It's not that I'm not interested. In fact I am bored with the stuff that I write most of the time. I've been hangin gout for ages to find a project where someone will give me money to play with Ruby. But that's not the problem I'm being paid to solve nor likely even the problem that I have - the two may well be different!

So rather than tell me why it's so good, instead explain to me Why I Should Care™. (Because there are 5 books on it is not a valid answer.) Tell me how it solves a problem that I do have rather than how I can do the same things I'm already doing, differently. As far as I can tell, a lot of it comes down to personal preference and pissing competitions.

Posted by Simon Harris at 01:17 PM | Permalink | Comments (7)