-
Technical debt is something that always creates an internal debate for me. In some cases, I believe that it is our responsibility as engineers to “fight” against it, through the use of well-known refactoring techniques and being efficient on time management to improve code even when adding new features. But sometimes (or most of the time) you always have the pressure to add new features to the system, and how you sell that the feature is going slow due to not being able to “just add the feature” but instead you have to move things around to accommodate the new feature?
-
This approach can be useful. http://blog.colinbreck.com/using-quality-views-to-communicate-software-quality-and-evolution/
-
I have learnt never to say “Technical debt”.
If you say “Technical debt” to the business end, you’ve lost already.
Because then you have to explain what the problem is exactly. And you run in to the Manager’s Syllogism.
You know the one, “Manager’s are Important People. They know and Understand Important Things, if XXX was Important, They would Know All About it.”
Ok, I’m exaggerating for humorous effect, but the point is compared to everything else on the list of things they want done, Technical Debt is really low on the list…. and most times falls of the list of things To Do This Cadence. Again.
Or worse, “So you’re saying this mess exists because your Managers are Bad and your colleagues are Worse? And now you expect me to trust you to go off on a long rewrite?”
I distrust rewrites.
They are never as Good as Hoped and always take way way longer than expected to get up to full functional equivalency. In fact, usually never do. In fact, I’d argue most of the benefits of a rewrite is in deleting cruft nobody really needs.
So start there.
Delete cruft as you go along every time you see it.
If someone yells and really wants it back… hey that’s what version control is for.
So merely say, “It will take X amount of time.” Why so Long? “Because that is the way the existing code is. (You can start explaining it to them until their eyes glaze over..)”
And then fix the existing code.
When you need to fix a bug, write a unit test that stimulates it. Then tidy up the code until it is so simple the bug is obvious. Fix the bug.
When you need to add a feature, brace exiting required functionality in unit tests, write a unit test to add the new feature, watch it fail, clean up the code until it’s trivial to add the new feature, add the new feature, watch it pass.
Technical Debt? What’s that? Heard of it once, not a useful concept in practice.
-
Thank you so much for this. Really really useful!
-
-
-
-
I found another similarity distance useful that is fast to compute. It is based on letter pairs present in the key and the search string. You can find it explained here: strsim.
This tool implements another algorithm that is relatively robust against swapped characters and small additions and deletions. The algorithm builds for each string a set of all adjacent characters (a set of pairs) and compares these:
Let x and y be strings and xs and ys the corresponding sets of adjacent pairs from these string and ss their intersection. The similarity s of x and y is computed as
s = (2*|ss|)/(|xs|+|ys|)where |xs| denotes the cardinality of set |xs|. Example:
x = hello y = hallo (German for hello) xs = {he,el,ll,lo} ys = {ha,al,ll,lo} ss = {ll,lo} s = (2*2)/(4+3) = 4/7 = 0.57-
Thank you very much @lindig . I’ll have a look at it!
-
-
This link is great. Amazing to see how known this issue was in the open-source community.
The click-bait title is not really backed up in any way in the content. The conclusion doesn’t even bring up company death. All-in-all, a rehash of the existing knowledge and statements around technical debt.
Moreover, the fact that almost all of the most successful, rich companies have a pile of technical debt… some maybe inescapable… refutes the title so thoroughly that it almost seems more natural to ask if technical debt is a positive sign of success.
Im not saying it is so much as looking only at correlations between companies that last and amount of technical debt would make it look positive by default.
I tend to view that as “Stagger onwards despite the mountain of technical debt, because the prime drivers in our current economy are not efficiency or competence of engineering”.
I’m sorry if the content of my post wasn’t explicit enough. The 4 areas of technical debt I analyse give my idea of how they lead to the corrosion of the engineering organization and the company:
My bad if the above points haven’t been clear enough from my post. Thanks for your feedback, really appreciated!
No, I got those points out of it, but you didn’t link that to company death in anyway. I’ve not done a study but of the successful companies I’ve worked at, tech debt is pervasive, depending on the area.
Also, and this point as more to do with me than you so I don’t hold it against you, I’m sick of these articles that of the form:
Observation -> Logical Assumptions Based On Observation -> Conclusion
There is no empiricism in there at all. So does tech debt make it harder to scale your engineering team? Maybe! But you’ve just presented some nice sounding arguments rather than any concrete evidence. It’s easy to say “here’s a a bad thing and here are the bad things I would assume happen because of it” but that’s a long ways away from “here’s a bad thing and here is the concrete evidence of outputs because of it”.