The Right to Freedom of Conscience: No developer shall have their bozo bit set due to their contrarian view about proper process or construction. No one knows how to best build software. No one. Facebook was built on PHP, Apollo went to the Moon with what was essentially waterfall, and some people value diagrams and some people value unit tests. No one can guarantee that their preferred practices are the right fit for you and your team.
Admittedly, I don’t really expect anyone to come out and say they think iterative development is a bad idea, but at this point in my career, I wouldn’t be shocked. I’ve heard “not in our situation” exceptions to every process, and valid (if not compelling) arguments for and against every piece of syntax and semantics. And listening to those dissenting voices is inevitably more valuable than reading someone dismiss the issue (even in those cases when I happen to agree that the dissent is misguided).
The Pursuit of Quality: The developer’s judgment of the stability and fragility of their code shall not be gainsaid. Here’s a secret that your management might be keeping from you: When the software crashes or doesn’t work in the manner that the customer wants, the customer blames you. They don’t blame the manager who approved the technical-debt-incurring shortcut, they don’t blame themselves for not trying that use case during the beta period, and they don’t blame the shifting foundations of hardware and software on which you deliver. Nope. They blame you: Bad programmer.
Since this is the case, it is your responsibility to write code that you can stand behind. It is your responsibility to craft tests that touch the corner cases, and to refuse to close the task until you’ve got those corner cases working logically. While incurring technical debt is a valid strategy, “technical debt” is not an excuse for mediocrity. Quality takes time and all developers are under time pressure, but there’s no worse programmer than the one who rapidly produces defect-ridden modules. Don’t be that guy. (And just to add to the unfairness of it all, management is more likely to forgive 20 defects produced by the “heroic” Mr. All-Nighter-of-Crap than the corner-case defect that you “spent all that time on and still didn’t get right.”)
The Definition of Estimate: An “estimate” provided by a developer shall never be considered a commitment. Coding is largely an exercise in recursive problem solving. To solve the main problem, you first must solve a hopefully less-complex inner problem, and to solve that you first must solve its inner problems. In the physical world, inner problems are almost always less complex: nested dolls can only get smaller, and most turns you make bring you closer to your destination. In the digital world, one is always skating on ice above a vast ocean of complexity.
Even if you don’t break through an abstraction layer and find yourself needing to implement an entire pillar of support, any kind of interesting application will have some number of user requirements that turn out to be much more complex than they appeared initially. The difference between a library solving a problem and you implementing it yourself can be the difference between five seconds and five weeks. A user’s domain rule can be implemented in two minutes or can unfold into two months of clarifications, meetings, and prototypes.
If your estimates are taken as commitments, you cannot afford to miss these inevitable recursive traps. But the only way to avoid such mistakes is to pre-solve the problem, which can only be done by taking just about as much time as it would take you to write the code in the first place. Or you can do what many developers do and substitute an estimate for a commitment and give a hugely padded estimate, which fills up the calendar with guarantees of mediocrity.
The Right of Clarification: It is the developer’s job to set bits to 1 or 0 correctly. The developer shall be allowed to ask questions, in as many variations as he or she sees fit, until the specification of those bits has reached a level of specificity that the developer estimates necessary.
Users think that the normal case is the hard part. The normal case is never the hard part. The user has thought through the normal case and can clearly explain how it should work. The data’s all there in its simplest form. The domain rules are unambiguous and may even be written down in clear, employee-training language. It’s the non-normal cases, whether they occur 10% of the time or one time in a thousand, that are hard. And when a user shrugs and says “That could happen, I guess,” the developer must hear an emphatic, “Yes! That can happen!” Sometimes this difference in perceptions can lead to user frustration and the feeling that the developer is making things harder than they need be. Sometimes this difference in perceptions can threaten the user’s self-image as they realize that they haven’t mastered all the subtleties of their domain.
But the developer has to flesh out all the code paths. Perhaps some of them will result in error messages, but an error message is often a perfectly valid domain result and is generally vastly preferable to a quietly incorrect result. Working through all this must be a collaboration between developer and user, and just as the developer is expected to concentrate deeply, work diligently and follow things through to their logical end, so too must the user when answering the developer’s questions.
The Right of Recharge: The developer shall be the final arbiter of their long-term working pace, and shall not be asked to work more than 150% of this pace in a week nor 125% in a month. This is a tough one to quantify, since long hours and occasional marathons are an enduring part of software culture. But ultimately I’ve come to believe that 32 hours of on-task best-of-ability coding per week is 90% or more of the value to be had from 48 fatigued and distracted hours. (Allowing eight hours per week for overhead might seem excessive, but it’s closer to the truth than pretending that e-mails, meetings and phone calls don’t exist.)
Larry O’Brien is a technology consultant, analyst and writer. Read his blog at www.knowing.net.