Source: medium.com
Legacy of the Technical Debt!Category: Business, containerization, automation
Lending Club is one of my diversification strategies to both risk out my stock market investments and set off the low returns of the fixed income instruments. Our ability to exponentially increase the technical debt churning more and more code into production without careful consideration of the holistic design principles — especially those of increased cohesion and reduced coupling of the code.
It is sad to note that many of the service companies’ portfolios are either limping across on the Agile Release Trains (or the XP iterations) or have successfully rolled back into the classic “Agile”Fall model — where we continue to work on 2-week sprints or iterations but push things into production only once in 3 months (if not 6 months). The reasons are so spread across that it becomes difficult to identify the root cause to fix it — while business blames it on IT as a whole, developers continue to blame it on availability of groomed user stories on time (product owners lacking the seriousness or not sure about how to control and prioritize the features and changes); environment is not a good word anymore — what with Cloud, DevOps, CI-CD etc.
For example, the first block of ideating needs to focus on customer experience and customer outcomes leveraging design thinking principles to ensure what we used to call “Building the Right Product” — the key to this block is user-driven focus and this is where product owner plays a very important role; followed by the design and code block where we need to ensure we not only drive the architecture with the larger goal in mind — we talked about increased cohesion and reduced coupling just as one key concept — but it is important we choose the right frameworks (in line with the overall organization boundaries for technology stack selection, we understand and implement the concept of domain-driven bounded contexts and apply them with great care and finally, drive the DevOps model aggressively; be it the way we perform continuous integration or the way we initiate the continuous testing or deployment.
It is sad to note that many of the service companies’ portfolios are either limping across on the Agile Release Trains (or the XP iterations) or have successfully rolled back into the classic “Agile”Fall model — where we continue to work on 2-week sprints or iterations but push things into production only once in 3 months (if not 6 months). The reasons are so spread across that it becomes difficult to identify the root cause to fix it — while business blames it on IT as a whole, developers continue to blame it on availability of groomed user stories on time (product owners lacking the seriousness or not sure about how to control and prioritize the features and changes); environment is not a good word anymore — what with Cloud, DevOps, CI-CD etc.
For example, the first block of ideating needs to focus on customer experience and customer outcomes leveraging design thinking principles to ensure what we used to call “Building the Right Product” — the key to this block is user-driven focus and this is where product owner plays a very important role; followed by the design and code block where we need to ensure we not only drive the architecture with the larger goal in mind — we talked about increased cohesion and reduced coupling just as one key concept — but it is important we choose the right frameworks (in line with the overall organization boundaries for technology stack selection, we understand and implement the concept of domain-driven bounded contexts and apply them with great care and finally, drive the DevOps model aggressively; be it the way we perform continuous integration or the way we initiate the continuous testing or deployment.
Related Articles
Community Partners
DevOps Careers