3 ms·
The reason for technical debt is the process. If you have a very waterfall like process like at a lot of large companies, everything has to go through change co
by UK-AL 10y ago
The reason for technical debt is the process. If you have a very waterfall like process like at a lot of large companies, everything has to go through change control.
Every change has to have business case, and becomes very bureaucratic. As a result no one proposes any changes to fix technical debt.
You can do it under the radar by attaching it to existing tasks, but these companies tend to be so project manager driven that any slippage in your delivery dates means you will get pressure applied to you. So you just do the bare minimum.
Result: Technical debt never gets fixed. Refactoring and trying to write good code is career limiting. Company wonders why they are so shit software, blames developers.
The elephant in the room is that companies follow the fixed scope, fixed budget model which basically fails every time.
- eru 10y agoAdd to that putting projects into 'maintenance' mode once they are 'delivered'. Ie no manpower to do any improvements, and even barely an bugfixes---even though lots of new downstream projects depend on it.
- flukus 10y agoI really don't think the process is responsible for technical debt. If anything waterfall is better because you can do larger scale refactorings. But at the end of the day, time needs to be assigned to address that debt and no process will give you that time.
- UK-AL 10y agoWell agile techniques recommend you don't fix scope, and budget at the same time. Allowing you to go back fix your code that has turned out to be wrong. You're allowed to learn and to adjust your plan as you go a long. Waterfall people have to meet a deadline and a defined scope, so when being told that you have to refactor some code, the response is to ignore it to meet the deadline. In order to meet deadlines and a defined scope the plan MUST NOT change, otherwise the deadline or scope has to be changed as well. That is until you reach the deadline and find it doesn't work the way the customer wanted anyway because you refused to change the plan. For agile techniques the measure of progress is working software, not meeting set deadline and scope.