Software development is tough. Really, is tough.
It is a mix of craftsmanship and automation and process industrialization.
It’s a place where you must be creative enough to invent new ways of doing things or new forms of presenting and accessing data or executing workflows. You must propose and create new fascinating user interfaces or think of new brilliant features in order to attract more customers, enhancing the user experience and reducing the passages to obtain any result.
Yet, you should maintain an open mind to solve problems and find any alternative in obtaining the same result in less time and using less resources.
But, at the same time, you should be always ready to put your creativity, inspiration, genius or talent, right into the drawer when it’s time to be disciplined.
Do you remember what you have always been told when you was a newbie?!
“It is mandatory to follow the rules of the object oriented programming discipline!”
“Did you stick to our naming convention?”
“Hey, don’t you see?! Right over there, yes there! Please, absolutely use the Abstract Factory design pattern!”
“How many rows counts this method? Twenty-five?! No, no, no, please refactor it and shorten at most to fifteen.”
Yes, definitely, software development is tough.
But, looking deepen and better at the problem, I think the two approaches are not in conflict. Creativity and discipline are two sides of the same coin, as well as craftmanship and process industrialization.
We should save time and space for creativity when it is really necessary, using any help derived from rules, disciplines, design patterns, automation, when it is time to approach to known problems or to execute silly and repetitive tasks.
Furthermore, we usually forget that even when it’s time to get out from that drawer our genius to solve compelling problems, we are not justified to write crappy code. Yes, of course I know, when the genius is working under the urgent pressure of creativity not always we are shiny enough to write high quality code.
But, in the end, does refactoring was not invented for this?
The more disciplined we are in applying the golden rules when programming every day, the easier it will be to adjust any crappy code that eventually arises. Yes, it is mainly a question of our own discipline.
Because, for sure, it will happen a time that the customer asks for new features of the product, to be delivered shortly. This situation, most of the times, pushes the developer in lowering the quality standards, maybe even not writing any unit tests.
The tester, on her side, tests the new features manually and not implementing any automation and perhaps forget to perform the usual regression tests.
This pressure in concomitance to such a lack of discipline of the workers, lead to the creation of technical debt.
Technical debt, as the latter word says, is a real debt.
You borrow a credit, that for a developer means to write crappy code and not to refactor it. From that moment on, the credit, for the developer, become a debit and every debit has arate of interest that insists on it.
As you probably know, a software application is written incrementally and, as the time passes and the technical debt is not payed back, more functionalities are added and the underlying crappy code badly influence the whole application, decreasing the overall quality and, indeed, increasing the technical debt and the time necessary to clean it up.
Most of the time the first signal of an accumulation of technical debt is the decrease in the team performance, which for a scrum team means that the velocity is dropping inexorably down.
But, it’s not only and always a fault of the team.
It happens that the business becomes very demanding in developing new functionalities or modifying existing ones, and is always business that decides and asks to lower the level of quality. This is actually the worst thing that could happen, because the developers are no more worried about it and crappy code is the rule!
Should we pursue systematically any challenge of the market?
If you choose to pursue the market regardless of the technical excellence and high quality of your products, you could win the first race due to your initial velocity or creativity.
But, as long as the time passes and you not pay your debt back, you will loss shares and positions in the market. New requests and challenges will arrive and you won’t be able to be responsive because of the burden of you technical debt, which influence you in technical choices, poor quality of your products and scarce responsiveness in products delivery.
In these cases it is necessary that the business works closely to the team in order to really understand what does it mean technical debt.
And yet, the business necessarily must be involved since the first sprints in tesing and executing user acceptance testing. This let the business to be aware of the status of the application and its overall quality.
Then, a little bit of homework for the team as well.
- Refactor, refactor, refactor and….refactor
- A good rule of thumb, for the entire team, is to spend 5/10 percent of the iteration on technical debt.
- Each team member must avoid constantly the technical Debt
- Perform constant pair programming in order to help each other to be disciplined, correcting other’s error
- Install a tool of software quality inspection and work on technical debt according on its results
- Establish and perform sessions of code review
- Implement TDD and continuous integration
- Implement automation testing
