Many developers feel that product management and executive leadership don't "get it" when we talk about technical debt. At the same time, if you as...
For further actions, you may consider blocking this person and/or reporting abuse
Couldn't agree more. Sloppiness - like laziness - is contagious. Like in the broken windows theory. Luckily even the opposite is true, high quality code, highly motivated, driven and positive developers can become the major growth and speed boost for the entire team ( but it is harder. )
the analogy with Farming and rotating the crops is AMAZING.
thanx for the article
No problem! I almost mentioned broken window theory by name, but held off due to length. In the follow-on on paying down technical debt, I'll go into it more.
My approach as weird as it might be is... just dont make technical debt.
Why would business care about giving you paid work on something they cannot see and which might not be necessary in the long run (at least in their eyes)? They at most wont understand why do you want this.
Or worse, they will see you as trying to make free work for yourself. Its just easier not to mention fixing technical debt and just not to make it at all.
Need a to fix something quickly and it will bite you in the long run? Don't fix it quickly, just say that it needs a lot of time and fix it properly and poof, no more technical debt.
Don't ask to refactor later, refactor now and make it proper. We would never allow people who make houses skip few steps since we need it now, so why is it something allowed for us to do?
Business expects you to do your job professionally so they must also acknowledge that development takes time and that there cannot be skipped steps.
If you have a relationship with the business where this works, that's amazing and go for it ... I spent five years in a Junior position where I was pushed into a "got to get it done now" mentality. There was no time for tests, no time for refactoring.
Later in my career, as a Senior developer, I was at another company with a completely different culture where I was able to propose things like major refactoring (3+ months, including heavy test coverage) and was able to "(not) make technical debt."
Your premise could work in some cases, but not many within the companies I've worked with over the years.
A company can be moved toward the mentality you are presenting, but most are not there and that's where the approaches Matt and I are proposing in our articles are so important.
The other factor to remember from technical debt is that it's not necessarily developer mistakes or cutting corners. Sometimes it's pursuing a business strategy that changes, or using version 4.2 of a library but version 5.5 was just release which patches security vulnerabilities in your version. Additionally, almost nobody starts with a blank slate. No matter how good you are, you're eventually going to inherit other people's code so it's important to have communication, detection, and mitigation strategies once technical debt is present in a system.
My co-workers just pointed that out as well ...
Quite a long article, did not have to read in depth atm.
But i find the subject interesting, so will come back. :)
My learnings have been that when i started translating technical debts to business goals impedance and money, then' my managers started listening more.
Yeah, maybe I should have chopped this one in half, but there wasn't as clean of a break in this one's contents. It's easier to break out data presentation with management (a future article) and strategies for paying down technical debt (a near future article), but this one defied splitting and I felt particularly passionate about it so... yep, holy word count, Batman.
A very good article on the subject! On point.
Thank you! I'm giving my first conference talk in January and will be talking on the subject, so it's a bit of a rehearsal on content for the presentation as I start prepping my slides and outline.
This article is really awesome I like the part of the analogy of farming to allow the business stakeholders to understand what does it mean for software development.
Thank you. That means a lot.