It is interesting to see the various organizational settings where software development takes place. Having a look at the different kinds of companies we have been working with in the last years reveals the many different settings: Completely internal development, internal development in a mix of internal and external developers, external development with internal project management/architects, completely outsourced development only providing a set of requirements to the supplier. Furthermore, throughout the lifecycle of a system, these settings are often changed: systems are handed over from an external initial development to internal maintenance or vice versa. Thus, a pure and stable development team developing and maintaining a system is rather an exception than the usual case.

It is not an obvious decision for a company which is the most suitable model to deal with their software development projects. In management discussions in companies (outside of the software business), software development is often rated as ‘not of their business’. I fully understand that people would like to get rid of the complexity and risks that software development involves. However, looking at the software portfolio of these companies reveals their huge dependence on software. Most of the systems used must be continuously updated in order to adapt them to new business processes, legal regulations and a moving technical environment. Their systems are business-critical and thus, ensuring their long-term maintenance, extension and evolution is a business-critical task as well.

Inhouse vs. outsourcing of software development is more than a simple make-or-buy decision because it is a matter of knowledge management. Program comprehension is known to be a key cost-driver in software development. Every line of code is read many times more often than it is written or modified. If a software system does not show excellent quality attributes concerning program comprehension and maintainability, a hand-over to a new development team easily becomes a nightmare. Developers and their companies become more and more irreplaceable the more implicit knowledge exists about a system - in business terms a typical case of rising supplier power.

A supplier usually does not have much interest in spending time on fixing quality issues because he gets paid for implementing features and fixing bugs. He does not care if the system he implements is in a future-prove condition because he will not be the one paying the price for expensive maintenance or an early replacement. In some cases he could even profit from such a situation. We even saw cases where software suppliers rate the complexity of change requests and charge more for complex ones. Thus, there is no incentive for a developer working in such a constellation to care about long-term maintainability and the reduction of complexity.

Missing or confusing comments are no problem for a developer if the colleague sitting at the next table wrote the code. You can name your identifiers a1 to a17 if you are the only person digging in that piece of code. If you only show architecture documents to your customer, nobody will notice that the system itself has nothing in common with the beautiful diagrams in this document. We see these kinds of issues that hamper maintainability and shorten the lifetime of a system every day. These are indicators of uncontrolled outsourcing that will lead to trouble in the end.

Hand-over scenarios are always difficult because lots of knowledge about the system is lost when the former developers leave. The only key to make hand-over situations work at least somehow, is enforcing quality and making the code and documentation readable, understandable, homogeneous and consistent.

Even if software development is not in the main scope of your business, every organization that depends on software must have regulations what level of software quality they need and what this really means for the development projects they run. Furhermore, people are needed to assess these quality aspects. Controlling the quality level reached is a continuous activity. Assessing the quality status shortly before a hand-over is usually no good idea. In this case the old supplier will not be available for clean-up activities or redocumentation anymore and the new supplier will raise the price for maintaining low-quality software. Quality control only makes sense as a flanking activity throughout the lifecycle of a system, with regular quality impovement tasks for the development team that can be resolved just like functional change requests in the usual development process. Regularly measuring and inspecting the artifacts created in development projects and an early feedback to quality issues arising will provide a fundament to save software systems from an early death by quality decay.