The US had it’s credit rating downgraded yesterday. For many people, it seems at first a little abstract and vaguely ominous—a chance for China to get it’s own back after being harangued by the US on its undervaluation of the Yuen. Maybe the outcome will be catastrophic, maybe not so much. Only time will tell. What Standard and Poor’s have basically said is that there is more chance than before that America will fail to pay its bills on time. But what does this have to do with quality software and how it gets built? Well here’s the thing—the way the US government are managing the economy and the debt ceiling are very similar to the way many software projects go slowly south; everyone recognizes that something needs to be done, but none can agree on what the right course of action actually is.
Don't overpromise and foreclose on your project
Performance as money
I first was introduced to the idea of performance as money through watching an MIT lecture series on algorithms. In the opening lecture, Charles Leiserson talks about performance as currency:
A good way I think about performance, and the reason it’s on the bottom of the heap, is sort of like performance is like money, it’s like currency. You say what good does a stack of hundred dollar bills do for you? Would you rather have food or water or shelter or whatever? And you’re willing to pay those hundred dollar bills, if you have hundred dollar bills, for that commodity.
when he talks about performance being on the bottom of the heap, what he’s talking about is how other things are more important than performance; features, security, ease of use and so on.
Performance constraints as the debt limit
I’ve posted before on non functional requirements every application should have, and first and foremost amongst those constraints is performance. The deal you need to make with yourself and your users is how much of that performance stack of bills are you willing or able to spend to get there? all of the decisions you make, from language choice to functionality to visual design are informed by this decision. Setting your performance constraint is just like setting your household budget (or the government’s debt ceiling).
And the credit rating?
To extend the metaphor a little bit further than is natural, the credit rating is akin to the likelihood that your project will fail overall. We don’t have a good measure for that in software development, but I do think drawing the parallel is interesting. If you read the S&P downgrade overview, you will see that the decision was in part due to the rising debt burden (technical debt?), but more significantly it is due of the infighting and lack of a clear plan forward:
More broadly, the downgrade reflects our view that the effectiveness, stability, and predictability of American policymaking and political institutions have weakened…
This sounds so much like entrenched behavior of stakeholders on a poorly managed software projects (and its effect) that I couldn’t pass on the opportunity to use it. Simply put, if you have a lack of alignment and clear plan about what is acceptable, what is important and how you are going to spend your resources (or generate income) things aren’t going to be plain sailing.
Performance—Avoid foreclosure
O.K. I really am stretching it here, but I wanted to finish up with how I think you best avoid getting mired in software rot or simply just building something that no-one wants to use. And it’s really similar to being financially prudent:
- Understand that almost everything you do bears some cost to performance
- Decide what is an acceptable level of performance…
- …and spend within your means
- Don’t go into debt(let performance drop below acceptable level)
- But sometimes it’s going to happen. If it does, get a plan in place quickly to address it.