4 ms·

> their estimate for a very minor change added up to several months... It sounds like they had an issue with technical debt (and that had led to a lack of trus

by flukus 10y ago

> their estimate for a very minor change added up to several months... It sounds like they had an issue with technical debt (and that had led to a lack of trust from the rest of the company) and thought they could fix it with a process, correct? I don't think you can help someone that won't recognise the root cause.

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 ago
  Add 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 ago
  I 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 ago
    Well 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.
afro88 10y ago
Don't be so sure. Layers of middle management, all with their own (often selfish) priorities between you and other teams working on systems you need to collaborate with will destroy any possibility of agility.

by flukus 10y ago

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 ago
Add 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 ago
I 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 ago
  Well 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.

afro88 10y ago

Don't be so sure. Layers of middle management, all with their own (often selfish) priorities between you and other teams working on systems you need to collaborate with will destroy any possibility of agility.