|
|
|
|
|
|
by ejk314
3811 days ago
|
|
|
I feel like this post misses the point of the whole "technical debt" analogy. They way the author talks, it seams like their org. uses it as a catch-all term for complaining about the code base. But that's never been the point of the term. "Technical debt" is the justification for process and development decisions that require more time up-front but will save time in the long run (especially as a term to communicate this to non-technical management). It only comes into play when you're talking relatively about two or more different choices. Just as an example: when deciding to move ahead with less testing or to move more slowly and write unit tests for every function, you should consider the first to come with more technical debt. That doesn't mean it's the wrong decision, it just means that it should be a factor in your thought process. |
|
|
If you look at a practice like Unit testing, you tend to find some organizations are having success with it and others not. Some of them see it as a "waste of time" and others see it as a "timesaver". How the practices are implemented are as important as the practices you decide to use. If the unit tests for your project take 3 minutes to run you may have a problem. If you are writing a large number of hard to maintain mock objects you may have a problem. If the program is not divided into units that are easy to test that is a different problem.
Another good example is the use of Vagrant. It is very possible to have Vagrant spinning like a top, but in a lot of places you hear software management grumbling that a team of 3 people wasted 2 weeks screwing around with it.
I see it so common for developer discussions to center around "cargo cult" positions (i.e. "singletons are evil") and not around a real dialog about the work to be done and how to do it.