Let me get this straight…

All too often, in too many companies I’ve been at, and many more companies that I’ve not, people spend a lot of time working on the wrong stuff. Oh no, these people will say – my work is important. The other day, I made a change to our platform that made it ten times as fast. Great. Congratulations – well done. Now, how are we going to pay your salary? What’s that? No customers were complaining about the speed? The speed will not sell any more product? So tell me again why I care?

Every time you start something, what’s the first thing you think? Or say? Is it “this is going to be fun!” or is it “this is a stupid idea” or is it “almost five o’clock… I’ll just get this finished”. My money’s on that it’s sometimes each of those. Sorry to burst your bubble (ok, I’m not actually sorry – I’m just that kind of guy), but you’re saying the wrong thing. You’re thinking the wrong thing. And I’d put odds on the fact that you’re asking the wrong thing. Actually, you’re probably asking the right thing. But you’re not really asking it – you’re phrasing your complaint in the form of a question. All too often, people ask “why do I have to do this?” but they don’t really mean it. my advice to you is simple – mean it.

What, exactly does “mean it” mean? It means don’t just ask why. Understand why. Understand the real underlying business value of what you’re doing. And make sure the person you’re asking understands it too. This will very quickly identify the true value of what you’re working on, and will lead to one of three things – 1) the person who requested it is dead on right – they have a solid business reason for asking for it, and they’ll convince you of it. 2) they don’t have a good reason for asking for it, and you’ll convince them that it’s a stupid idea, and that you should be working on something more valuable. Or, by far the most likely, 3) you’ll get to the bottom of what they’re really after, and be able to give them what they really need, rather than whatever it was that they asked for.

In software (indeed any engineering discipline), these are known as requirements. But once again, the vast majority of requirements are wrong. I once reviewed an RFP for an outsourced web application that had several hundred requirements. Two of the “requirements”, that, by the format of the document were clearly considered equal, were “The last name field must support 150 characters” and “a complete hot backup system must be in place on our premises”. Really? First of all, to consider these two of equal weight is astonishingly naïve to me. One of them represents 3 seconds of developer time, the other potentially hundreds of thousands of dollars in hardware and ongoing maintenance. Clearly, neither of these actually represented the problem these people were facing, but rather, the way they thought they should fix the problem.

I advised against responding to the RFP – the requestors clearly weren’t looking for someone to solve their problem – they were looking for someone to put the design they had already decided on into code. Working on that project without getting to the real root of the problem would have been a waste of time – no real value would have been added. I honestly don’t know what problem they were trying to solve with their requirements. I can (as I’m sure you can) pretty easily surmise that they had run into two problems in the past – one is that they had a system that didn’t allow for the last names they encountered to be entered into the system, and the other is that they were concerned about the viability of a company providing services over the internet (clearly security wasn’t their primary concern, or else they would have wanted the entire system onsite, not merely a “hot backup”). Addressing the first issue – you, as a software developer, meet their want – they asked you for 150 character last name, and that’s what you gave them. But oops – you missed the boat – as soon as it went live, they tried to put in a first name. But there was no “requirement” for the first name, so you, with a name of say, Mark or Jack, made it 4 characters – very reasonable in your universe, and all of a sudden their system is broken again.

But what if you asked “why”? Well (let’s assume my guess is correct) they’d respond with “we previously had a problem where we tried to enter someone’s name and it failed”. This just starts a whole line of questions – what about other fields? Where did the data come from (for all you know, the failure could have been from an external source that padded with blanks)? What SHOULD happen when they blow past the field length limit? Do you want a field length limit at all? And on and on.

If you want to make sure you’re working on the right thing – ask why, and really mean it.

Don’t worry – you’ll hear me talk a lot more about asking why – there’s a reason Challenge Everything is S3’s motto – because it’s what makes it so we’re always working on the most valuable thing – in other words, we work on the right thing.