Wednesday, 9 October 2013

Technical Debt

Technical debt is very similar to financial debt. When a person takes a loan (or uses his credit card heavily), he incurs debt. If he is paying the installment (or the credit card bill) then the created debt is fine and does not create further problems. However, if the person does not pay his installment (or bill), a penalty in the form of interest is applicable and it mounts every time he misses the payment. In case the person is not able to pay his installment (or bill) for a long time, then accrued interest makes it even difficult to make him pay. In an extreme case, the person has to declare himself as bankrupt.

What is Technical Debt?

Technical Debt is a metaphor coined by Ward Cunningham in a 1992 report. In his report he says – “Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise.”

Classic cause of Technical Debt

What does this mean in layman terms? Let’s take the case of a medium-sized organization that develops software products. In order to be able to compete with other organizations in the market, this organization obviously wants newer products out in the market faster and at reduced costs. But how does this impact the software development process? As one can imagine, software developers are expected to implement features faster without having the opportunity or time to reason about the impact of their decisions on the current design. As a result, over time, such a collection of individual localized design decisions starts to degrade the structural quality of the software and structural quality of a software system is one of the vital contributors of technical debt. During future enhancements to the product, the poor structural quality of the software will adversely affect the development tasks. For instance, the software will be much more difficult to understand and analyze or much more difficult to extend. This, in turn, would lead to increased development/maintenance time and costs which would eventually hurt the organization’s interests.

What Constitutes Technical Debt
There are multiple sources of technical debt. On a broader scale, we can categorize the types of technical debt in following categories:

  • Code debt: Examples- code duplication, static tool rules violations, and code smells.
  • Design and architecture debt: Example - Design smells, design rules violations, and architectural rules violations.
  • Test debt: Examples – Lack of tests, inadequate test coverage, and improper test design.
  • Documentation debt: Examples – No documentation for important concerns, poor documentation, outdated documentation.
  • Defect debt: Examples – Unfixed list of known defects.

How Technical Debt Occurs?
The software engineering community has identified several common causes that lead to technical debt. These include - 
  • Schedule pressure 
  • Lack of good/skilled designers 
  • Lack of awareness of technical debt 
  • Lack of applying design principles 
  • Lack of awareness of design smells and refactoring
Often, given the different cost and schedule constraints of a project, it may be okay to incur technical debt temporarily. But what is important is that this debt should be paid off as early as possible.

Monday, 19 August 2013

A Principle-based Classification of Structural Design Smells

We would like to share a presentation that describes our principle-based classification of structural design smell. We believe that all structural design smells can be classified using famous four principles of object-orientation i.e. Abstraction, Encapsulation, Modularization, and Hierarchy.

Design smells poster for quick reference

This poster provides a quick overview of the design smells. The smells are classified as the violation of fundamental OO principles - abstraction, encapsulation, modularization, and hierarchy. 

Take a printout and paste it in your cubicle for your quick reference!

Monday, 12 August 2013

Design Smells: Overview, Classification, and Examples

Here is a presentation on design smells that talks about the need for understanding design smells in OO software systems, offers a classification based on our paper, and presents a few design smell examples. The presentation cites examples from well-known classes of JDK so that reader can relate to the provided description with much more ease. 

Have a comment, feedback, or suggestions? Please do feel free to write us. Also you are welcome to post your own examples for these design smells :-)

Monday, 24 June 2013

Our paper on Design Smells published in JOT (June 2013 issue)

Title: Towards a Principle-based Classification of Structural Design Smells

Abstract: Fred Brooks in his book "The Mythical Man Month" describes how the inherent properties of software (i.e. complexity, conformity, changeability, and invisibility) make its design an "essential" difficulty. Good design practices are fundamental requisites to address this difficulty. One such good practice is that a software designer should be aware of and address "design smells" that can manifest as a result of his design decisions. However, our study of the vast literature on object-oriented design smells reveals the lack of an effective organization of smells that could better guide a designer in understanding and addressing potential issues in his design. In order to address this gap, we have adopted a novel approach to classify and catalog a number of recurring structural design smells based on how they violate key object oriented (OO) design principles. To evaluate the usefulness of our design smell catalog, we first asked Siemens CT DC AA architects to use it to identify design smells in their projects, and later elicited feedback from them about their experience. The feedback received indicates that these architects found the catalog to be very useful. In this paper, we present our catalog, classification, and naming scheme for design smells and also highlight several interesting observations and insights that result from our work.

Cite as: S.G. Ganesh, Tushar Sharma, Girish Suryanarayana, “Towards a Principle-based Classification of Structural Design Smells”, Journal of Object Technology, Volume 12, no. 2 (June 2013), pp. 1:1-29, doi:10.5381/jot.2013.12.2.a1.

If you are interested to see the information discussed in the above paper in the form of a presentation, it could be downloaded from here.

A nice poster on design smell classification can be downloaded from here.