Regaining Your Development Team’s Confidence
Another pep talk or a new process is not going to cut it. Refactoring Design may…
Note: What I am about to describe is mostly applicable to medium-to-large applications maintained by 5 or more team members.
The need to nurture and grow your application
Creating large enterprise software application is hard. Defining the requirement, making sure that it’s what business wanted, identifying and selecting right tools & processes, planning, architecting, designing, executing, testing and finally rolling out to production — its HARD.
That’s why many projects fail.
For the ones that do succeed,when you consider total life of the product, cost to create is only 30%. Remaining 70% is spent on growing the product — maintenance and enhancement. Business evolves; requirements changes. Change is the norm.
If a product is expected to be continually useful, this growth or change is not only desired but expected and is inevitable.
Managing change is not rocket science
Change happens faster than you anticipated. Business pivots harder than what architecture assumed. These things happen all the time and chnages are pushed to the maintenance team.
In order to manage this barrage, teams generally emply one or other form of Change Management — monthly sprints, quarterly release cycles, patch release frequency etc. This is a well-established Project Management practice.
But no matter what facilities you employ to manage change, the change is implemented by development team and this is where the crux of the problem lies.
How development team implements change
The dance starts once the development accepts a change or enhancement. Teams prepare some form of impact analysis document, low level implementation document and many such artifacts to create the impression that they know what they are doing.
Coding gets completed, test scripts are updated, QA teams verifies it and the changeset is finally promoted to production.
Let this repeat for few times and then go back to your code base. I can bet on my bottom dollar that what you will find is Big Ball of Mud.
How do you know if you have Big Ball of Mud?
Simplest way to find out is the judge the confidence level of the team in accepting challenging business changes.
If you want to be systematic, you may look for these pointers as well —
- Development team spends more than 50% of their time in understanding existing code.
- You go through multiple rounds of code/test/fix before a change to accepted
- Class names are too generic and hence responsibility of them are wide and complex.
- Util, Manager and Helper classes carry most of your application’s business logic.
- Business rules are spread across multiple architectural layers.
- Implementations will have too many if/else, switch/case blocks.
How did you get to this place?
If this did happen to you, you must be putting the blame on lot of different people and situations. I am sure they are valid for your case. But, I am going to give you two reasons that are almost always there.
Technical Debt
Technical Debt is a wonderful metaphor developed by Ward Cunningham… In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice.
Design Rot
There are four primary symptoms that tell us that our designs are rotting. They are not orthogonal, but are related to each other in ways that will become obvious. they are: rigidity, fragility, immobility, and viscosity.
How do you tame this beast?
What I am desicribng is nothing new. Various teams have done research studies and provided recommendations from 1970s onwards.
Technology keeps evolving and therefore recommendations changes with them as well. But some things remain timeless —
Lehman’s Law
Therefore in order to make them viable we need to maintain them continually. But what sort of maintenance should we do now?
Apply SOLID design principles
This is an age old set of principles coined by Uncle Bob. We will have to constantly maintain the cohisiveness of the Class. The good things is that for most of the enterprise developers, this has become second nature, or at least I hope so.
But only recently, the focus on managing large applications has shifted from designing classes and functions to modules and rightly so.
Refactor to Modularity
This is the secret sauce that will help you regain the confidence of your development team.
If you are a Javascript developer, you should check out excellent works done by Addy Osmani and Nikolas Zakas.
If you are Java developer, you should check out this good but mislabeled book by Kirk Knoernschild. Don’t worry. There is very little about OSGi and even less about Architecture. But this will be one of the most important book you would have read on Modularity.
But what about Application Frameworks and Design Patterns?
For some reason, new developers have a mindset that if they choose a Application Framework, say Spring and Hibernate and create entities that play nicely in this sandbox, they somehow have done proper design.
Design and Design Refactoring has nothing to do with Framework and everything to do with your business and context. A new tool, framework or technology is not going to address your Design Rot.
Design Patterns, particulatly, GoF patterns are fundamental building blocks for a OOP design. But they have tow issues — First, you should use an OOP language to begin with. Second, they limit themselves to designing implementation needs, not necessarily to manage large applications.Design Patterns may make specific code snippet look pretty but will not address your Architecture Decay.
How do you know if you have tamed this beast?
Simple. Just check the vibe of your developers when you are discussing new and challenging enhancement or change that the business wants. They will be happy, confident, willing and most of all creative.
Your work is done.
