Chris Holmes Online

Ayende poses the question: How do you sell maintainability? Evan adds his $.02 to the discussion.

I’m going to open by saying you don’t sell maintainability. Selling is about getting people to buy what they already want, and Stakeholders don’t want maintainability. What they want is a finished product. And therein lies the rub.

Stakeholders don’t understand maintainability because to them, software is like buying a car. They expect a finished product. They expect a finite amount of work and a finished good. But that sort of mentality doesn’t mesh with the reality of software development.

It is unfortunate that software came into the industrial age so late in the game. People have been conditioned to expect a finished product. But software is soft: it can be changed, updated, improved and fixed. Unlike a child car seat, for instance, which has to be recalled when a flaw is discovered, a software program can be patched with code that fixes the problem. Unlike a Barcalounger, which cannot be upgraded with cup holders, a software program can be improved with new features without you having to replace the old version.

Software that is worth keeping and using is worth maintaining. But how do you convince a stakeholder to invest in maintainability? I don’t think you do. I think you have to start somewhere else. You have to start with something they already want.

Stakeholders want software that does exactly what they wish of it. They also want software that can adapt to changing requirements. These are things that you can sell. Maintainability then becomes a requirement to make the other things reality; it becomes something you don’t have to sell.

To get them sold on the things they already want, I think the first thing you have to do is convince them to invest in the concept of software as a living entity, like a garden. You have to engage them in a paradigm shift. You have to get them to understand that software that does what they want will never be “finished”; it will continue to grow and mature; it will never be “done”. Sure, it will have an initial period of development that looks an awful lot like landscape construction, but that is just one phase of a much longer lifespan; a lifespan that can go on for as long as the software is deemed useful.

Software has the advantage of being soft. This becomes part of the selling strategy. If the stakeholder wants the software to (a) do what they wish and (b) be adaptable to changes, then the malleability of software becomes a key feature. It is this malleability that you must use to force the paradigm shift; to get them to understand that software is not like building a bridge, or skyscraper, or car. Software is not like purchasing a yacht, it is like growing (and maintaining) a beautiful garden.

Once the stakeholders understand that software development is not finite, but a long term commitment, then they will understand what it takes to make it successful: people. People are necessary to grow the garden, and people are necessary to maintain it. And that is when you can enforce maintainability. Because by then you should have sold them on the things they already wanted. Maintainability then becomes a requirement, not an option. And you don’t have to sell requirements; those things are mandatory.

As for .NET and RAD-like tools: I don’t think stakeholders can understand or appreciate the differences until the paradigm shift happens. Until they see software as a living entity that requires maintenance, they will never appreciate the difference between maintainable code and flashy RAD prototypes. As long as software is like buying a car to them, then the RAD applications will continue to impress. So from my point of view, this is about educating the stakeholders.