Software Product Delivery – 20 Rules?

Rishikesh Tembe shared twenty rules for software product delivery last month. His rules are from the perspective of a former software developer. Some we like. Some, not so much.

We Like

Rishikesh has a short post with 20 rules. Among those rules are some concepts that we feel like expanding upon:

8. Do the riskiest part of the project first.

This is a great idea (for developers and project managers) for a couple reasons. Risk may be a function of technical feasibility or customer accceptance/value. Risk may even be an artifact of how we go about developing our product – for example, offshoring introduces risks. Risk is generally a nebulous, but bad thing to have in a project. If a problem is known, a solution can be identified, addressed, and implemented.

Risks represent the unknown unknowns, or those problems that we don’t understand well enough to address them. Big risks can be very scary – they jeopardize the ROI of our project. Lack of user adoption can affect the expected value to our customers, which will directly or indirectly affect our bottom line.

Note: This is not meant to imply that prioritization of requirements by release should be subservient to risk-mitigation. The most important stuff should always be done first. Within a particular release, address the riskiest issues first. Prioritize first. Mitigate second.

10. Make sure you’re in total control of your toolset and improve it systematically

This alludes to the general benefits of operating at a higher CMMI level. As a CMMI level five organization, we would quantitatively measure and improve not only our tools but our processes.

16. Build regression testing into the build process.

We’ve talked about continuous integration in the past. In our opinion, no other approach should be used to develop software.

Not So Much

11. Do not take the clients’ deadlines literally – first accept the project, then renegotiate the deadline.

Clients have deadlines for reasons. They may be market-driven, or driven by internal politics or budget cycles. While it is possible that a deadline is arbitrary, it is usually associated with a compelling event of some sort. Any discussion of deadlines should be approached in the same way we manage scope creep as a relationship-building exercise.

Project constraints, such as budgets and deadlines, are things that should be addressed collaboratively. Our clients are our partners, not our opposition.

13. Document the interfaces perfectly, but don’t document code (see next point).
14. Be fanatical about the readability of code.

Absolutes are rarely rational end-points, although presenting goals as absolutes can be effective in motivating directional change in an organization (with no expectation of actually achieving the goal). More on that some other time.

Broken Windows, as Gladwell describes them, are absolutely detractors from any environment, and serve to degrade the performance of those who operate in the environment. Code readability, micro kitchens, flexible schedules. There are many soft ROI elements that make up the environment of a software developer. Readability of code, like readability of requirements, is important. A friend of mine used to joke that perl is a “write-only” language. Notwithstanding his joke, code needs to be readable. Even in perl.

Perl serves as a great example – elegance of code does not always coincide with syntactic simplicity. Avoiding commenting of the code is just a bad idea. People read code. Make it readable.

There are times when incurring a temporary code-debt is pragmatically more useful than delaying a release or a feature in order to polish the code.

Conclusion

There are some good ideas and some bad ones in the list. Most of them are thought provoking, regardless. We may eventually find a list of absolute rules we should all follow, and it would overlap with this list somewhat. But for now, we’re still looking.