|
|
|
|
|
by mvdtnz
716 days ago
|
|
This is bearishly hard to measure. For example (this is a real, recent scenario, left intentionally vague): a new government regulation gives you 12 months to expose certain data conforming to a provided API schema. The system under development is a big ball of mud. Re-shaping the data to conform to this schema turns out to be extremely difficult but failing to produce the APIs on time will result in company-endangering penalties from a government regulator with no sense of humour. So you put a team on the APIs and issues keep cropping up again and again because every time one thing is changed it has knock-on effects causing other company-endangering incidents because you're making changes to to way billing and invoicing data is presented, or to how incoming metering data is stored. So you put some additional teams on the project and work everyone to the bone. Some senior developers burn out and leave the organisation. Likewise some project managers. Your best QA staff have their morale drop to rock bottom. The project delivers on time but how do you measure these costs? How are you going to put a dollar figure on the burnout and lost staff? How much of the senior developers' decisions to leave can be attributed to the project and the big ball of mud? How do you measure the impact of your best tester losing his will to work and going dark? Many of us have worked in organisations where things have gone down like this. We all know that impact is huge. But yeah you're right, I can't put together a business case that says it in clear numbers. On paper we had a one-year project, it probably went a bit over budget but it ultimately delivered so what's the big deal about the big ball of mud? Except that our competitors were able to produce the same APIs for a fraction of the cost without burning out half their staff. |
|