3 ms·

Especially in big companies it's really hard to keep your code concise. I have often started with a very clean design that totally feel apart when new requireme

Especially in big companies it's really hard to keep your code concise. I have often started with a very clean design that totally feel apart when new requirements came in. If you give managers the choice to hack it into the code in 1x time or redesign the code in 2x time most of them will vote for the first option. Go through that cycle a few times and your code will be a big mess

jeffwass 8y ago
This 100%. I’ve worked on several codebases over the years where a mgr said “here’s a special case, inputs of (foo, bar) should give baz2 not baz1. Coder whips up a hacky workaround to that very specific ask in the simplest place possible, not the right place. A few dozen requests come in like this over the months. Overrides and exceptions are now scattered all over the code base, without any semblance of order, functions no longer do what they advertise because data is modified downstream, etc. Sometimes the time to redo it right is worth the investment in terms of future maintenance. Other times it’s too foregone and you have to bite the bullet and stick with the mess.
- jehlakj 8y ago
  It's hard to blame them. I've been in similar situations multiple times where a requirement seems simple enough on the surface that you only get a few hours to work on it. But it's actually not that easy to write it cleanly. That hacky workaround you're talking about? Well, my task depends on it. The workaround too depends on another hack. With the amount of time I have to work on it, it's a no brainer. Earlier in my career, I tried to fix them, but they started to break other "hacks" and down the rabbit hole I go. Sometimes it's just not worth it.
j1elo 8y ago
If you don't act over-pessimist with that "1x vs 2x" comparison, management only sees that you offer two valid options and the second one takes double time for no reason. So obvious, take option 1. Maybe you can propose to hack the code in an accumulative +1x time from the previous hacks (thus making it clear that next hacks will take more and more time), or design it into the system with a nice and constant 2x. That could be a strong indication for management that the hackish way does have a long term cost.

jeffwass 8y ago

This 100%. I’ve worked on several codebases over the years where a mgr said “here’s a special case, inputs of (foo, bar) should give baz2 not baz1. Coder whips up a hacky workaround to that very specific ask in the simplest place possible, not the right place. A few dozen requests come in like this over the months. Overrides and exceptions are now scattered all over the code base, without any semblance of order, functions no longer do what they advertise because data is modified downstream, etc. Sometimes the time to redo it right is worth the investment in terms of future maintenance. Other times it’s too foregone and you have to bite the bullet and stick with the mess.

jehlakj 8y ago
It's hard to blame them. I've been in similar situations multiple times where a requirement seems simple enough on the surface that you only get a few hours to work on it. But it's actually not that easy to write it cleanly. That hacky workaround you're talking about? Well, my task depends on it. The workaround too depends on another hack. With the amount of time I have to work on it, it's a no brainer. Earlier in my career, I tried to fix them, but they started to break other "hacks" and down the rabbit hole I go. Sometimes it's just not worth it.

j1elo 8y ago

If you don't act over-pessimist with that "1x vs 2x" comparison, management only sees that you offer two valid options and the second one takes double time for no reason. So obvious, take option 1. Maybe you can propose to hack the code in an accumulative +1x time from the previous hacks (thus making it clear that next hacks will take more and more time), or design it into the system with a nice and constant 2x. That could be a strong indication for management that the hackish way does have a long term cost.