Temporary Solutions: Technical Debt in Pictures

Software developers are constantly told that they should avoid Technical Debt. But very frequently it is difficult to resist the temptation. Why not implement a good-enough temporary solution that satisfies all the functional requirements? The main problem is that very often this solution ignores completely the non-functional requirements. It is not efficient, nor robust, nor maintainable, nor scalable. I think this problem may be very nicely illustrated with the pictures below.

Car Dashboard1) Functional requirement:

The dashboard must have a knob to control the air-conditioning.

 

 

 

car window cleaner2) Functional requirement:

The back-window must have a wiper.

 

 

 

lock3) Functional requirement:

The door must have a lock.

 

 

 

mirror4) Functional requirement:

The car must have a side-mirror.

 

 

 

 

tire5) Functional requirement:

The car must have four tires.

Unknown's avatar

About Hayim Makabee

Veteran software developer, enthusiastic programmer, author of a book on Object-Oriented Programming, co-founder and CEO at KashKlik, an innovative Influencer Marketing platform.
This entry was posted in Requirements Specification, Software Quality, Technical Debt and tagged , , . Bookmark the permalink.

1 Response to Temporary Solutions: Technical Debt in Pictures

  1. Ryan D.'s avatar BigWin says:

    I love the pictures… in this and your other post about emergent design. A good visual helps convey the meaning so much more effectively than words.

    One thing I think that needs to be balanced here is that you can quickly get burned if a development team over designs a feature and adds cost for things not being asked for which then creates some level of mistrust. It comes down to talking and educating PMs and dev teams on these topics and why short sighted decisions and adding tech debt is bad.

Leave a reply to BigWin Cancel reply