Software Product Delivery – 20 Rules?

comedy and tragedy

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.


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.

4 thoughts on “Software Product Delivery – 20 Rules?

  1. Great post! I just wanted to clarify a few points:

    Regarding point #11, I’m not suggesting that clients’ deadlines and constraints are not important. On the other hand, I’ve seen too many engineering teams perform heroics to meet the project deadlines, often when it would have been OK from the client’s perspective if the deadline had slipped by a week or a month.
    In retrospect, I’m going to clarify in my post that one should always keep the lines of communication open with the customers.

    About #13 and #14, I agree that absolutes are not always feasible especially in the software industry. However, if we try to build these absolutes (documentation, code readibility etc.) into our processes, then most times they should not impact release dates or other potentially higher priority factors. Its more of a long term goal that we should try to achieve without impacting our short term commitments.

  2. I am a little more inclined to agree with Rishikesh on the part about software code documentation. The one thing that always frustrated me as a product manager was the extra time those added to our delivery schedules. I am sure there is a happy medium between too much documentation and the “code is documentation” camps.

    I completely agree on #8. Best way to minimize risk.

  3. Hey Deepak, I would definitely have issues with measurable “extra time” to go back and document code. Documenting as you go, however, doesn’t really add time – or at least did not in my experiences as a developer, or when I was managing other developers.

    Rishikesh, thanks for the original article, and for the comments here – hope you’ll stick around. Your clarification on #11 helps a lot, thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.