4 ms·
Yes, most of it. Most (all?) code in a pressurised business environment eventually ends up in a bit of a bad state because technical perfection and maintainabil
by osrec 8y ago
Yes, most of it. Most (all?) code in a pressurised business environment eventually ends up in a bit of a bad state because technical perfection and maintainability are rarely what the devs are going for. They're just trying to "get it working, and now". How I've seen devs deal with it successfully:
1) Complain early and loudly about past mistakes from other devs, so that management know delays are not your fault. Once you've made enough noise, attempt step 2.
2) Reduce the scope of changes significantly. Management want X, but you explain only 10% of X can be done in the available time given the current code base. If they accept, great - you're touching less existing code, but may have to dig around a bit. If you can convince management that the reduced scope offers little business value, try step 3.
3) Push for a rewrite. Get budget, get resources and eventually deliver. If you're a good dev/dev manager, you may even get to be the hero that delivered something that works amazingly (aside: a lot of devs take on too much in this phase and often burn out). If you do deliver, you'll be worshipped as the authority on the system for months/years to come! Happy days!
Eventually, however, even your beautiful rewrite will decay into festering spaghetti, as random requirements get incorporated. You may even, deliberately, introduce complexity into your code to justify/protect your own job. At some point, the very thought of diving into your own code may fill you with dread, and you'll start searching job boards.
The cycle then repeats.
- zem 8y ago"After me cometh a Builder. Tell him, I too have known." http://www.kiplingsociety.co.uk/poems_palace.htm http://www.kiplingsociety.co.uk/poems_palace.htm
- osrec 8y agoIn a nutshell: people who make stuff are critical of other people who make similar stuff :P
- rzzzt 8y agoPeople who repair stuff (or people) are even more critical of the repair work done by their peers.
- tpaschalis 8y agoI've never particularly cared or been much knowledgeable about poetry, but thanks for introducing me to this beautiful one. :)
- jehlakj 8y agoThat was my mistake when I first started. The manager didn't think it would take too long to finish a task. Well, the naive me, without even looking closely at the code, didn't think it would either. But I realized the more I understood, the more dependencies needed to be changed. While it's still doable, things started to break and I ended up learning way more about the project than what was required to finish the task. In the end, it took me longer to finish it. The fact that most of my coworkers would write a hacky solution in a short time, it made me feel incompetent. Managers without a technical background don't look at code, they look at results. So how do you even do #1 when the "other devs" still work there and can get stuff done much quicker?
- lostctown 8y agoThe sad truth is that in order to bear the cost of a long time horizon in the pursuit of elegance you need one of two things: extreme trust or total control. Even then the pursuit may lead you astray and ultimately result in failure. Until there are ways to transfer experiences from one mind to another in an efficient manner, few manager/higher ups will sympathize with a desire to take on more long range, highly technical code improvements (assuming we're not talking about a FAANG).