Tech Debt is overhead not escape…
be careful & mindful about planning, backlog refinement & estimating your sprints…
Thank god I’m not too alone who has talked more about clean code, good quality of the code, pure testable code etc?
When I searched on google about “Tech Debt” then I found uncountable memes on tech debt, please see the following some of these:
Tech debt is not a good term for any great agile team and surely it is also not most of the time the developer’s fault.
Being an enterprise architect I have recently experienced very high-tech debt with one of the highest numbers of experienced team members.
There are the following factors which lead to introduce tech debts and increasing them like a hell:
Process Leak
The process leak is one of the main factors in the introduction of the initial phase of the tech debt as there is no sincere code review, no defined best practices for good code quality, and no strictness with developers to adhere to these best practices of code quality for sake of delivery pressure.
Delivery Leak
Missing or imbalance of POSDCORB (Planning, Organising, Staffing, Directing, Co-ordinating, Reporting & Budgeting), basically 7 rules defined by Henry Fayol’s that I have learned during my graduation’s 2nd semester for management. (That’s what I’ve learned about that each and every subject that you‘re studying definitely adds value to your experience somehow, that’s what I have never understood while pursuing graduation as to why I was learning about financial accounts, marketing strategies, statistic mathematics, operation research & management)
This is a very important concern that I bring into the knowledge of my readers if you plan for deliveries of an MVP then make this mindset all the features should be tested before production roll-out, and all the infrastructure should be ready with mocked integration environments before code should take-off from the respective prior environment to the next. Capabilities should understand the risk of dealing with new managers or over-smart managers who commit a lot in the beginning without having any functional domain knowledge, resource capabilities and availabilities, public holidays, and resource planned/unplanned vacation consideration.
There should be a fair, transparent & honest segment should be added while MVP agreement that if we’re not stable in spring 0 then we should not kick start sprint 1 or further because if your resources are not available or hired then there is no sense of proceeding further to avoid unnecessary delivery overlapping or delivery debts.
Technical Leak
Oh!! dear developer, technical debt is not a good word and please feel shame before communicating proudly about that likewise not a bug or error or wrong code it’s a tech debt and I will fix this in the next sprint or another PR.
Generally, if you don’t hire or allocate the right skilful resource for the subjective project then I believe this may not a big issue (for the short term only) but you need to check how good or smart enough the resource is for quick learning and not only feel just an experienced but the resource feels valuable of a so-called experienced developer or tech-lead. If you’ve experienced a particular technology then you’re an SME or just an expert in tools. I don’t think you’re an architect (FYI, the architect should not be a position or designation, this is a practice of architecture patterns, design patterns, technologies, integrations, data science, automation, design thinking, and machine learning)
Good code quality and test automation of the application must be a tolerant policy since the beginning of the project.
DevOps or Infrastructure Leak
This segment is very interesting for me as it is like that how much your budget you will get served accordingly and seems most innocent culprits or victims.
As DevOps totally depend on the client’s budget, the client’s guidelines & governance so somehow client must understand and should be very honest to support their vendors. Because they can’t afford a Rolls Royce then don’t push vendors or play with vendors by negotiation while having multi-vendor approaches and expecting a custom Nissan juke to convert that must feel like Rolls Roys or in short don’t pretend complete solution like Netflix, Amazon Prime, Spotify, Uber, Twitter, Meta & Just Eat type application experience as you know they do innovation and there is not that much budget squeeze like I have seen in recent past.
Testing Leak
This layer is very honest in their work & profession, unfortunately, look like often culprits or there on millions of memes of developers & QA or testers relations but they're true friends and honest reviewers of your application or any feature that you built ever.
But sometimes lack ness of agility with a variety of automation approaches over estimating testing time leads to testing leaks for any deliveries.
At the top of the above test, pyramid practice should be taken care of by the QA teams and must prefer automation rest of most of the levels can be automated and should be taken care of by the development team along with automation execution of each of these by DevOps pipeline before building a container package.
Follow me on Linkedin | GitHub | YouTube | StackOverflow
