Software Lessons: The Long Tail

One of the top misconceptions I've witnessed in IT work is that many view a software project as a discrete component. They assume that the costs are static and once a piece of software is in place, the costs end or are minimal. They will look at the cost to build and implement on Day 1 as the only cost.

This is so wrong that it befuddles me how often this mistake is made. The "long tail" of a system's life, comprising the care and maintenance of the application, is likely to be far more expensive than the cost of the initial implementation (assuming the software is useful enough to live for more than a few years).

This is especially true if the quality of the application is poor due to corner-cutting in the creation process (and given the common emphasis of deadline over quality, it happens a lot). This is why developers and project managers are often at odds. The project manager is working to a milestone and then moving to the next project, but the developer likely has to live with the completed product for a longer duration, suffering with that application's deficiencies. I've discussed this before, where such scenarios create soul-sucking and inspiration-sapping work that is menial and tactical in nature rather than strategic. Many of the people at the high end of these mistakes are not held accountable for these problems, due to the way the typical reward system's metrics work.

Change will require a major shift in metrics, and it must come from the top.

The Decision-Consequence Gap

Last time, I posted about an empowerment ratio, which can be an indicator of how much a company trusts its people to effect improvements in an organization's products and processes. Another concept I see that leads to difficulties for people is the decision-consequence gap. This term refers to the distance between a decision-maker and the consequences of his or her decisions.

Narrow Gap

When the gap is narrow, the decision-maker is cognizant of how his or her strategy is working; he knows whether unforeseen factors have made executing the plan more challenging and is aware of how subordinates are carrying out the tactics in meeting a plan's goals.

Wide Gap

When the gap is wide, the decision-maker lives in a vacuum and tends to take credit for success and pass blame for failures often without understanding how results are achieved or missed.

Gap Effects

This gap is a big factor in leadership, and most leaders seem to misunderstand or not care about it. It's not just in IT either, and dysfunction is visible within this concept across top leadership in all industries. And wide decision-consequence gaps often lead to poor empowerment ratios.

It's a harsh recipe especially in software development too, when functional owners and project managers are given strategic and tactical control over non-functional elements. Although not all will make mistakes here, under the duress of time constraints there is often a push to favor speed over quality. Non-functional concerns will be given little priority despite the advice of the developers presiding over the construction.

If you've ever supported poorly designed and poorly implemented software, then you are quite familiar with this already. The people that decide a team will cut corners to make a date are not the same people who have to support it and work the production support load.

The project manager's common refrain here is that if developers are left to their own devices, the product will never ship. I agree that developers who care and are perfectionists may draw the development cycle longer than is comfortable for the business. And it is often true too that developers, in the interest of pleasing management, will comply in promoting a shoddy release to make a date.

Cheap Fix for a Cheap Methodology

But what I hope for in a better and more mature IT world is not necessarily perfection. It is that we collectively strive for something better than the C-minus level software most corporations deal with now. Can we maybe compromise and get to a B grade? The difference between a C-minus and a B would be perhaps that:

• Some routines feature hard-coding, but that routine is properly isolated in a method that can be easily tested and refactored.
• We put more eyeballs on our database structure so that common pitfalls don't make it into production and compromise future enhancement and refactoring efforts.
• We not short the concepts of testing and training, so that fewer "diaper change" type of requests get turned into weekly flurries of productivity-and-morale-sapping help requests.
• User interfaces aren't so awful as to make our users cringe when they have to work with our systems, or so confounding and unintuitive that it leads to more support calls or worse, bad data getting into the system, which leads to more data fixes.

None of the above suggestions are terribly expensive and a lot of it is good preventative maintenance and best practice. Yes, there will be a time cost somewhere. But you can't read a magazine article about agile and then decree your teams will start using it and expect immediate benefits if you haven't empowered them to write software that is properly objectified and can be tested or maintained without massive effort. And you won't understand any of these concerns if you suffer from a sizable decision-consequence gap.

Are You Managing a Project for You or for Your Company?

Let me ask you managers out there a question. Would you tell a developer, "Oh, just do it sloppy so we can make the date?" Actually, don't answer that question, I already have experience showing the answer is Yes. Let me ask a different question instead. Would you allow the contractor building your home to cut corners to finish faster? I'm betting the answer is No, and do you know why? Because YOU have to live in that house. YOU will be the one dealing with the leaks or creaks or breakage. When it comes to YOUR home, you pay heed to the decision-consequence gap. I guess I missed the part in the PMBOK calling selfishness a PM trait.