Showing posts with label design smells. Show all posts
Showing posts with label design smells. Show all posts

Friday, 4 July 2014

Refactoring for Software Design Smells: Managing Technical Debt


"Refactoring for Software Design Smells: Managing Technical Debt" presents 25 structural design smells, their role in identifying design issues, and potential refactoring solutions. Organized across common areas of software design, each smell is presented with diagrams and examples illustrating the poor design practices and the problems that result, creating a catalog of nuggets of readily usable information that developers or engineers can apply in their projects. The authors distill their research and experience as consultants and trainers, providing insights that have been used to improve refactoring and reduce the time and costs of managing software projects. Along the way they recount anecdotes from actual projects on which the relevant smell helped address a design issue.

Salient features:
  • A comprehensive catalogue of structural design smells and their refactoring solutions to solve problems occurring in design
  • Explains the importance of smells in managing technical debt, an area of increased concern at software engineering conferences
  • Each smell includes examples, source code, and visualization diagrams to facilitate understanding
  • Describes solutions across common software design concepts and smells that cross multiple domains

Tuesday, 3 June 2014

Tuesday, 4 February 2014

Our Tutorial in ICSE2014 - "Refactoring for Design Smells"



Tutorial title: Software Design Quality in Practice: Refactoring for Design Smells
To be presented in ICSE 2014 (Hyderabad, India) on 3rd June 2014

We will be presenting the tutorial in ICSE (International Conference on Software Engineering) 2014 - the most prestigious software engineering conference on the planet. 
 The details of the tutorial are provided below:

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 design practice is identifying and addressing ‘smells’. Most practitioners know about identifying and refactoring code smells. However, there is a lack of awareness on refactoring design smells and architecture smells, which are also equally important for creating high quality software. In this tutorial, we introduce a comprehensive catalog, classification, and naming scheme for design smells to the participants. We discuss important structural design smells based on how they violate the four key object oriented design principles (abstraction, encapsulation, modularization, and hierarchy). Each of these smells are illustrated through design smells found in OpenJDK  (Open source Java Development Kit) code base, with detailed discussions on refactoring strategies for addressing them. By attending this session, the participants will get a good understanding on design smells and how to refactor them in real-world projects.

Tutorial structure
The tutorial is structured as follows:
1.       Introduction
1.1.    Fundamental principles of software construction
1.2.    What are ‘design smells’?
1.3.    Why care about smells?
1.4.    Common causes of smells
1.5.    The scope of smells
1.6.    The effect of smells
2.       A Classification of Design Smells
2.1.    A design principle based classification of smells
2.2.    A naming scheme for smells
2.3.    A template for documenting smells
3.       Refactoring Design Smells
3.1.    Refactoring for abstraction smells
3.2.    Refactoring for encapsulation smells
3.3.    Refactoring for modularization smells
3.4.    Refactoring for hierarchy smells
4.       Conclusion and Key Takeaways
4.1.    Tools for detecting design smells
4.2.    Refactoring considerations in industrial projects
4.3.    Relationship between smells
4.4.    Relationship between design smells and design patterns
4.5.    Research directions for the community

Key takeaways
The tutorial provides many insights on design smells and the refactoring strategies for addressing the smells in real-world software. The key takeaways of this tutorial are:
a.  The comprehensive catalog presented in this tutorial will help practitioners understand the kind of problems that could be occurring in their design.
b.  The detailed description of smells included in the tutorial will help the practitioner understand via suitable examples how those smells manifest, how they are caused, their impact on quality attributes, and the potential refactoring that can address those smells.
c.  The tutorial provides a simple and intuitive naming scheme for smells which will be easy for practitioners to remember.
d.  The catalog of is a readily-usable guide for use in design reviews or for identifying refactoring opportunities.


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.