Author: Hüseyin KUTLUCA, Principal SW Architect

Many times when you talk with software engineers about possible reuse of their product you would hear a phrase like: “I would rewrite this project if we want to reuse it.”, because they think that their system cannot be maintained for future projects. What would be your reaction if you hear even worse phrase “We should rewrite the project with new technology and programming language if we want less complain from our customer.”?

Similar to such case, Lead Software Engineer of a project stated that they did know little about project domain when they started the project. They had made some decisions which, they later realized, were not perfect for their purpose. They have just concentrated to functional capabilities and stability issues, which created lots of problems during the final phase of the project and they had to extend the acceptance of the project. So one should rewrite the same code if they want to reuse it.

When I teach the “Software Architecture” course, I hold a special session where I ask people about their experiences gained from their past projects. The complaints are similar to the story I told you above. We are never happy with the project we are developing. Many projects get delayed not because of functional requirements but due to performance and reliability shortcomings of the systems.  Some projects even fail due to such problems. Software architects describe this situation as “technical bankruptcy”. That is, the current system architecture is bad enough that no one can rescue it from failing.

Ideally, a project should be started with software architects and software teams with some experience in technical and business domain of the project. Team should have enough time to extract architectural drivers of the project, then define quality attribute scenarios. At the same time, they should look for alternative architectural approaches, evaluate different technologies and select the best among these options using technical analysis such as Architecture Tradeoff Analysis Method. Before starting to code, the team should have established reference architecture as a backbone of the system and have supporting architectural patterns and tactics for handling any remaining concerns. Similarly, it is expected that sensitivity points, risks and tradeoffs of the decisions are all identified and documented. Once the project is started, software engineers should have well documented guidelines and code snippets for developing software modules compliant to the software architecture. Software architect performs periodic reviews to prevent architectural erosions during the development process. All these ideal cases define a perfect world while software architecture trainings and books are focusing on teaching this approach to engineers.

On the other hand, software architecture research is working on models that elaborate approaches and solutions for real life situations where not all quality attributes and technical constraints may be handled at the beginning of the project. The reasons can be listed as schedule pressure, lack of technical knowledge, poor processes or non-systematic verification of quality.  Delayed technical work is defined with a “technical debt” metaphor, because it creates extra costs in the future in the form of rework and maintenance. [1,2]. – A non-optimal code, design or architecture, shortcut or workaround creates a technical debt to your project. And it is not always easy to detect these non-optimal designs. Technical debts that are due to non-optimal architecture generally greatest much bigger impact in latter part of the project. Wrong technology selections, inconsistent design approaches, poor choices of component decomposition, incoherent designs or more complexity in designs than absolutely needed, design choices that turn out to be wrong are reasons for such technical debts.

Technical debts are manageable if you pay them in acceptable time and you do not take more debt than you can pay.  One such approach that we have also adopted extends agile processes for pay off the technical debts. As seen in Figure below, project backlog items are color classified as “New features”, “Defects”, “Architectural, structural features” and “Technical debt”. Architectural, structural features and/or technical debts are taken into sprint plans together with new feature development and bug fixes [3].  Thus, technical debts may be paid off with limited interest (rework done due to architectural decision).  Increased number of defects in a sprint, slowing rate of sprint velocity, are just a few indicators that are used to detect an approaching bankruptcy.

         What colour is your backlog?

[1] Ward Cunningham. “The WyCash Portfolio Management System.” Addendum to the Proceedings of OOPSLA 1992. ACM, 1992.
[2] P. Kruchten, R.L. Nord, I. Ozkaya, Technical debt: from metaphor to theory and practice., IEEE Software., 29 (6) (2012), pp. 18-21.
[3] Kruchten, P. 2009. What colour is your backlog? Agile Vancouver Conference

Picture from Mestia, Svaneti Region, Georgia