I have lots of ideas about how software should be written but I’m not particularly adept at expressing them. Jeffrey Snover’s writing, OTOH, is very eloquent and persuasive. His latest blog post here  discusses a topic that is near and dear to my heart. He uses the term technical debt. I don’t know if he is the originator of the term, but it succinctly captures the issue. In a nutshell the problem is product managers who favor investing in shiny, new features at the expense of basic functionality. This has been a problem for as long as I’ve been involved in the computer software industry (25 years). The marketeers want to have impressive bullet lists of features for a new product release. They give lip service to customer satisfaction but would much rather sell something first and worry about how well it works afterwards. This is a big problem for desktop software but becomes critical for customers who pay for online services.

Paid-for online services give a service level agreement (SLA) guarantee as to the availability and reliability of the service. It is a major problem (and a breach of contract) if the service is unavailable for any extended period of time. There is a more insidious problem that can occur when transient loads cause service resources to be momentarily unavailable. In the aggregate it appears that everything is fine, but individual users could see disconnections or other service failures. The only way to detect these situations is with very fine-grained performance monitoring of all of the service components. This is a difficult problem to solve but it can be solved with sufficient development resources. Unfortunately it is not very sexy. Will management have the wisdom to make this investment or will it be just more technical debt. Time will tell.