Software Development is not a Commodity
If you could get the (client) boss(es) to understand JUST ONE THING about computer consulting and contracting, what would it be?
It would be that software development is not a commodity. The cost-value equation is not just enhanced by cutting costs, but more effectively, by enhancing value. It’s not just a matter that software is produced, but what software is produced. Does that software clearly express the nature of the business? Is it an asset that can be extended and adapted as the business grows and changes? All too often, the only measure applied seems to be the hourly cost of the software production (neglecting even the number of hours required). Too often I get the feeling that I, the consultant, pay more attention to the long-term value to the company than do the employees and executives of the company.
I can sympathize that the value of software can be very hard to measure. This value has two components. The external component is the costs saved, or the income received, by having the software rather than not having it. These sorts of measures are dependent on estimates and assumptions, and therefore imprecise. They are the sorts of estimates and assumptions that the marketing and accounting departments are accustomed to make. The CIO can simply ask for these, assuming there is sufficient trust in the organization. Asking for an explanation of the rationale behind the estimates can strengthen your sense of trust if it’s weak.
The internal component is the foundation which this software provides for building the next software you need. This component falls naturally into the IT realm, but how do you measure it? From an executive office, the internal quality of the code is invisible. You could ask the opinion of a trusted technical person in your organization–but you may be worried that they, having a hand in guiding the creation of the software, will take a less-than-critical look. You could ask an external consultant for an assessment–but you may be worried that they will merely tell you what they think you want to hear. Or that they may tell you what they think will fuel your fears and provide them with future work.
If asking others for an opinion is an unreliable means of ascertaining the internal quality of your software, what might you observe to infer it yourself? As I mentioned above, one characteristic that “good” software has is that it’s more easily extended and adapted. You might look at how your organization reacts when asked to extend or adapt an existing program. Do they groan and suggest a ground-up rewrite? Or do they smoothly provide the modifications as if they were expecting them to come? Do such modifications seem harder over time (a sign of increasing “technical debt”) or do things seem more stable? You’ll find it easier to monitor the ease and success of such modifications if you have lots of smaller projects rather than a few big ones.
Now that you’ve started monitoring (albeit indirectly) the quality of your code, how do you go about improving it? Outsourcing may reduce your costs, but is unlikely to increase the value. A contracting company, particularly one in the outsourcing business, is most likely to do the minimum work necessary in order to cut costs and ensure winning the bid. The sort of quality that enables long-term success requires just a bit more than the rock-bottom minimum effort. Even if the outsourcing company does an excellent job, the knowledge of the software internals and how it maps to the business of your company will not be known by your own employees. When next you want modifications made, you’ll find you’re even more likely to go with that outsourcing company, as they know the business better than your own IT department.
Long-term success is more likely to result from investing in your own capabilities. Train your own employees to produce the kind of quality that can support the company through the inevitable coming storms. Build a culture of excellence and knowledge. That culture will remain, even as employees come and go. Make it possible, no, make it easy for your employees to share their knowledge and learn from each other. By all means, bring in outside contractors and consultants to help where needed, but bring them into your organization in a fashion such that your employees learn from them–increasing your internal capabilities. Those you bring in should not only increase your capacity while they’re there, but leave behind an increased capacity after they’ve gone.
There is an old saying in organic gardening,
Feed the soil, and the soil will feed the plant.
I’ve seen this attributed variously to Dr. William A. Albrecht, a former chairman of the University of Missouri’s Department of Soils, and to Robert Rodale, son of J. I. Rodale who founded Rodale Press and Organic Gardening magazine. Whoever coined the phrase, it illustrates the greater value of creating an environment for success, rather than focusing solely on the immediately desired success. Similarly, as Franklin D. Roosevelt noted that
The Nation that destroys its Soil, destroys itself,
so does the Company that destroys its IT Capability, destroys itself. The dependence of business on IT isn’t going away any time soon. Any business that must depend on others for core development functions will be left begging when times are hard.