Code Watch: A software developer's Bill of Rights
September 19, 2012 —
(Page 1 of 2)
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.
Share this link: http://sdt.bz/36959