Do. Reflect. Learn. Repeat!

A recent Weinberg blog (there is a part 2 too) reminded me that I meant to write about the antipattern of programmers making business decisions for some time - so here it goes!

The linked example of a programmer purposefully implementing something other than what (s)he was asked to do - I hope - is not common, but there are other, more subtle situations where we make the same mistake of making decisions instead of our clients (which can be a customer, business analyst, product owner, etc.).

Not Specific Specifications

Project failure (or rework at best) happens when we don't deliver what we the customer wanted. One reason for that can be traced back to misunderstandings of requirements. I often say that our job as developers is to put on our detective hats and help our customers discover & formalize their processes - which they know, do every day, but usually never had to articulate it precisely. Despite the best efforts, specifications/acceptance tests leave space for interpretation, which we, as programmers with a special attention to detail, will discover.

And here comes the problem - another trait of us programmers is that we love solving difficult problems/puzzles. Thus we will first think of a solution that we would like to implement and we often stick with the first idea that makes sense to us as the logical one. Now we are doing exactly what the programmer in the linked article did. There is a reason we are developers and our customers are lawyers/traders/salesmen/etc. - they know their problem domain better. And their perspective (ROI, time to market, cost vs. benefit, etc.) likely differs from ours (such a great puzzle to solve!).
While it's hard to accept it as a programmer, it is a valid business decision to say we don't care about that or we are willing to take the risk - which to us would look bad, for being an imperfect system, an unhandled scenario. However, we might not actually be able to show an occurrence of the problem in the past 5 years' data... And it probably saved a week's worth of programmer work that was spent on some other feature important for the business.

The Road to Hell is Paved with Good Intentions

Has it ever occurred to you how the usability of the site could be improved, or how much better would be if there was a shortcut, or... It certainly has happened to me (and I hope will happen in the future). But again, even if we are right, and it would be a great improvement, that might not be needed, or not now. For instance, if you have a wizard form, where the first step is so beautiful it should be shown in the Louvre, and is super easy to use - almost reads the user's mind! - ... but it crashes as soon as you press the next button, have we really made a good decision? As the saying goes: shipping (functionality) is a feature too.

I have yet to meet a client who didn't appreciate programmers taking initiatives and making suggestions for improvement in the application, but I have met ones that were furious when they learned that only 10% has been delivered due to having too many bells and whistles (though of course, there are counterexamples to everything - but in my experience they are the exception, not the rule).

Let them decide!

If you find yourself in any of the cases above, I suggest you stop, and consult with the person who should make that decision instead of coding away one that makes sense to you - even if eventually it turns out that the customer's decision is the same as the one you had come up with.

Caveat: I am not saying you should stall work, waiting on a decision from customers. You might not have instant access to your customer, they may be on holiday, etc. If so, talk with the most senior person you have available (tech lead, team lead, etc.) and have her/him make a decision. If you are the most senior person, make a decision, but keep it minimal (even if you see myriad of other issues this might lead to), and make it easily undoable if needed.

To give a concrete example: recently while implementing a certain form, and the related business logic behind it, I realized that this action has different implications depending on the type of user that requests it - but it was not specified yet. The combinations I came up with were pretty big. But for my given feature, I just needed one of those combinations. I ended up using a single request handler class, but implemented the logic for each role as a separate mixin class, so when it comes to dealing with this issue, we don't have to spend the time excavating the code relating to each role from one class. Based on my prior experiences, I wouldn't be surprised if our customer will decide to simplify this feature, and say we only handle the two most common combinations, and don't make the feature available for the other users. If it'll turn out that is the case, it's rather a good thing that I haven't forged ahead and spent days writing a complex, composed object hierarchy to handle all possibilities.

1. sn0wcat on 2011/12/01 11:15:49: In my opinion there is also an another side of that medal. You say as well that you shouldn’t stall work, yet this is the most common outcome if we as programmers take a stance not to make decisions at all if something is unclear, which in my opinion is the most convenient way for a lot of people.
   
   I have seen quite often an attitude of delegating decisions further up in the food chain, in such a way that the loss of time and additional cost spent of clarifications exceeds by a multitude the eventual saving of programmers work time for refactoring / redesigning a feature.
   
   There is another thing that we as programmers often value our time spent on coding the most and don’t see the economic value of it.
   
   As unflattering as it may seem, but a week of software developers work for a feature solution proposal and a week of redesigning/improving it that it fits the need may still cost less from a pure cost perspective than using up the sparse, more costly resources for additional specifications, not even counting the time loss.
   
   I always tell to people to be software engineers and not code monkeys.
   
   I don’t say don’t delegate the decisions to the customers / most senior people around, but I do say don’t do it without providing a solution suggestion.
2. Peter Zsoldos on 2011/12/02 09:01:15: @sn0wcat: thanks for bringing more emphasis to escalation - it deserves its own blog post (or more!).
   
   I agree that my advice can be skewed to be used as an excuse for not doing work, but for Wally (from Dilbert) I could have said it's a nice day and he would be able to justify not working - so common sense is still needed.
   
   Also, you are right we should consider costs vs. benefits when delegating decisions up - if it's just a phone call or walking over to the other room, its cheaper than if the Product Steering Committee needs to schedule a meeting to decide on it. That - in some respects - falls under my advice for leads: make a decision that is reversible/reworkable if needed. And to clarify: I didn't intend for the junior programmer to go all the way to the cusomter's CEO :)
   
   One thing I should have emphasized more, and I'm glad you reminded me about this omission, is what to do after making a decision on such a gray are - you must communicate that decision to your stakeholders. That was the graver mistake of the programmer in the referenced articles.
   
   The economics of proposals is an interesting aspect too - as long as writing a proposal doesn't actually take longer than implementing the proposed solution, makes sense. The danger of suggestions is that we often only provide one, which isn't a choice - and I have seen only a few developers who would propose only partially implementing something.
   
   I personally actually prefer the term developer to software engineer, but that might be off topic here.