Embrace Technical Debt
Technical debt is a concept in software development which has been associated with problems generated by the code in software components. Most of the architects are seeing the technical debt as a result of code quality.
Everyone is concern about the code quality and when we are talking about it we need to see the overall aspect of the development environment from the up-front definition, business pressure, lack of processes or understanding, to last-minute specification changes.
In the following article, I will talk about all the elements we need to consider when we develop code to meet the required quality and therefore not to generate technical debt but business growth.
Initial analysis or up-front definition
Many of us have already adopted agile in a form or the other. Still before starting anything some kind of analysis should be completed.
If not just “spike” it! – in an agile way.
However, an understanding of the requirements and some pre-analysis of the solution should be in place. Pre-analysis or analysis should not be completed by bloated documentation or extended description of the requirements, but layout as formal rules to follow by the developer. Most of the time the direction is descriptively done by a solution architect or a senior member of the team which has a high level of understanding of the system.
Still, some consideration of the overall architecture and principle should be considered. In case, where are in place any architecture principle definition like for example SOA or Integration Principles then the solution should follow the guidelines since otherwise will break the overall architecture of the system.
Business owners always will pressure the product or feature to be released. Risks should be described and presented as feedback back to the business or product owners. When we are talking about the risks always we should be presented as a factor for technical debt. If the code is not tested enough or we started with the presumption that we’ll review the code – functionality, software component- at a later date after the production release that is misleading.
The business will always presume: if works than is done.
In some cases – like the ones pushed by the time-to-market factor – of course will force you to take corners. At this stage, any corners cut should be considered as a strategic decision rather than feature removal. When strategic decisions are in place then you are forced to revisit the product or feature later on and still at the time of development some extra efforts it is invested into the code to cover failovers or unpredictable errors. Is not recommended to let any strategic code too long in production since will became in time technical dept.
Lack of business process
“Great power comes with great responsibilities” and probably that is why technical debt is generated and accumulated blindly in many ways. Business owners are not considering implications of making decisions without considering :
- Current status of the software and infrastructure system. Like for example full development stack tools and environments.
- Operational business processes.
- Possible workarounds and if they exist how the new development will make them functional complete.
- In place architectural design principles and development policies.
Success businesses are backed up by strong software architectural decisions which empower and leverage innovation, scalability, availability, consistency and other attributes for business growth. Software development is hand-in-hand process with the business processes as it a general belief that software infrastructure is the nervous system of a company. Lack of business process inevitably will generate technical debt and if does exist then it will increase it. When technical debt is present company bleeds money.
Tightly coupled components
In many companies are still present components which are strongly coupled and this is the case – most of the time – for monolithic applications. A monolithic application is a heavyweight participant to the technical debt. If there are defined architecture principles or already existing strategy for decoupling then the case is solved. A monolithic application can be always broken down into small decoupled components and with courage and business owner support the monolithic de-structure can generate: innovation, scalability, quality and availability.
A monolithic application should be transformed in small application consumers. This means that the monolith block once is split into small block components they need to be refactored to meet the distributed system requirements and with that, the migration of data or functionality. Once the monolith is broken also the technical debt is isolated and can be tackled for each component or business pillar.
When to start the action?
It should not be a dedicate project, only if there is a business case for it. Otherwise when new features are required to be implemented then the code affected should be refactored – if is the case – or adapt/include the new feature as smaller software functional block.
Lack of documentation, collaboration and communication
Documentation is always a problem and this is because nobody likes to create it. We like to point fingers to missing documentation or undocumented features. Generating documentation as consistent as possible is hard and cumbersome and we need to think about all parties involved in a development when it comes to understanding it. Despite our best efforts documentation once created became deprecated with the new features added or changes made to the existing software infrastructure. Probably the best way is to have a balance between complex description and diagrams.
Collaboration between the team members is essential in delivering expected quality of the code. Pair programming, code review from other colleagues, a “second pair of eyes” are collaboration instruments which strengthen the knowledge and delivery potential of the team which impacts the quality of the final product.
Communication is also essential. Core details can be omitted without noticing and the development can be tangential to the context and the purpose intended. Communication should be addressed clearly between parties and within the context of the source and receivers. We cannot push technical details to the business process owners. However, the communication details and the context should be put in the understanding context of the target.
Sometimes it is required to refactor the code because we know is not at the expected quality level, but because no priority is set in changing the code, nothing happens. In this case, every delay to refactor the dependent code will increase technical debt. Inefficiency and difficulty to add new feature will make development harder. Refactoring time and resources will increase since dependencies are increased with every new block of code added. The code evolves and in most cases, we evolve faster or slower with the technical debt too.
Lack of standardization
Every programming language has defined best practices for writing code, implementing patterns and architectural component definition. Everyone wants to be standardized which means we need to be aligned with a common set of rules followed by everyone from the development team to software architects. If there is a discontinue understanding of the rules than implementations are done differently, results are not the same so implicit the code quality is broken. In many cases, there are industry features which should be defined by the system to allow everyone to communicate in a common language to allow a fast, reliable and secure mechanism for data transfer. One example is the WSDLs file for web services or SOAP standards. Using frameworks and standardization will decrease implementation time and will save money and also aligned the code to a common denominator.
Lack of knowledge – training
Successful functionality deployed in production for a new feature, a new integration is partly because in the team is a strong base knowledge of the business functionality and processes but also understanding of the tools which makes it deliverable. Team members are most often specialize in different technologies however this is not always the case. A business needs to have the freedom to generate growth not based on the “standard” level of the business type but based on the knowledge, tools and means that leverage innovation.
Lack of knowledge will generate technical debt and mostly because developers and senior member of staff, architects or/and analysts will stick to what they know and they have considered successful in previous projects. Lack of training is also a decisive factor in “sticking” with what we know. Training should be allocated clearly and generally to the entire team since is a part of the base knowledge and it is improving the quality of the deliverable product. Being up-to-date is not necessary a request to adopt everything but to know where everything is for later reference or use.
Lack of ownership
Ownership should be embraced by all the team members otherwise gaps of functionality and innovation are growing within the team, business and finally will impact any chance to business growth. A lean – agile team is always rotating tasks and therefore knowledge. By rotating tasks and share the associated knowledge, the ownership can be easily transferred. In some cases, due business diligence the software efforts are outsourced from in-premises teams and in all cases, the integration of the solution requires rework, refactor and re-engineering when the application is brought back or deployed in production.
Fundamentally is required in this cases a clear ownership policy if not at the technical level at least at the requirements level. This way everything that is developed by outsourced resources should feasible and aligned to the in-house software development strategies, concept and policies in place.
Poor technological leadership
Technical leadership is probably one of the factors which will pinpoint the success of a business. In a company which includes IT functions are “a must” to have a driven technological leadership among the higher senior member of staff. Supporting initiatives and being in strong position when comes to a fundamental technical decision is paramount. Any wrong decision – picking the right technology or software components – can impact the technical debt.
Therefore is very important to take decisions which are both strategically and cost-effective for the business and for the future developments. A clear view has to be present, assessing risks – probably the best is to have a framework to manage risks – and benefits when a decision is handed down the hierarchical chain. Any poor management assessment of the situation or lack of clarity will increase the technical debt for any company.
Last minute specification changes
The changes which will increase exponentially the technical debt if not properly assessed, clearly defined and understood. If this is the case then any last minute change should be avoided and postpone the delivery date. Primarily those changes should be initially prioritized. If are critical this means someone has not been taken the right investigating approach or the business has oversight the case.
There is a valid point not to include such a change into an early release without a strong depth analysis of the problem, assessment of the risks – including risks management. Even in the case of “no time” or “no budget” the changes should not be let easily let into the released code. The impact can be disastrous for the business and for the overall processes.
Embracing technical debt is a team quality which reflects maturity and power to deliver successful products. We cannot remove completely the technical debt, also is quite hard – in some cases – to control it, but can be minimized.
WEX Photo Video software infrastructure evolved constantly over the years and because most of the projects have built with the “evolutionary” architecture in mind, the company had successfully delivered a graceful customer experience. Agile methods have been adopted due to the nature of the business and associated practices have challenged the status quo, creating disruption and start acting as “best in class” company. Once embracing the change in an agile manner we have also diminished the technical debt by identifying the causes and work toward removing them. It is a constant effort which has, is and will always pay off.
At any stage and any conditions, we need to be alert in identifying factors which are generating technical debt. All the causes – as described above – are to be considered when we want to reduce as much as possible the technical debt.
How to create RESTful API
Restful APIs services and Microservices with Mule E.S.B Community EditionThe PDF file contains hand on tutorial alongside with technical details related to flow components. Standard screen shoots have been made however some of them have low quality. There are34 pages in landscape mode. What is in this chapter?
- Why MULE ESB RESTfull APIs?
- Bounded Context
- The Project
- Products API URI
- Customer API URI
- Order API URI
Introductory Chapter 01
Create a New Project using Anypoint StudioThe PDF file contains step-by-step tutorial. Standard screen shoots have been made however some of them have low quality. There are 15 pages in landscape mode.
- New Project.
- Run the First Flow.
- Export for deploy.
Introductory Chapter 01
Create a New Project using Anypoint StudioThe MDA file contains the source code for the Introductory Chapter 01. The source code has been generated using Anypoint Studio - Tooling for Mule ESB version 6.3.0 on Mac OS Sierra. The code compiled and is not a guarantee that will work on Windows machine when imported. Has not been tested on other OS than Mac OS Sierra.
- New Project.
- Run the First Flow.
- Export for deploy.
Comments are closed