2 ms·
> breaks the known contracts with other units. which either forces you to fix those contracts - implying you have to go understand those contracts too. Or, you
by chii 4y ago
> breaks the known contracts with other units.
which either forces you to fix those contracts - implying you have to go understand those contracts too. Or, you un-abstractify the function by keeping the original, and add a copy with the modifications you needed for the new feature/fix. This keeps the original contracts intact, but you add "bloat" to code - a form of tech-debt.
- Supermancho 4y agoIndeed on both counts. This is a demonstration of why a code change may seem simple in theory, but when you actually do it, you can see all the side effects that you didn't consider when estimating. This is one of the many ways that estimation without looking at existing code, can be completely off...not to say it will be right-on when estimating and looking at code. I have worked a company with 8 hour planning, where every single change is by committee while looking at existing code. Mercifully, this methodology didn't last more than a few months.