Are Trendy Developers Ignoring Tradeoffs and Over-Engineering Workplaces?
-
Periodic rewrites may alleviate the symptoms in your case, but what about solving the root cause? Why is there a high turnover? Is it really the code quality (and in that case, a single rewrite would solve everything) or something else? Speaking from experience here, I've inherited a project that's been worked on by several people, some of them less sane than others (replaced 2 nested loops for string processing with 2 function calls, just as an example). I swear that this thing has been paid for by the line in some past, at least, that's the only sensible explanation I have for some of the mess I've cleaned up. Now I've been a couple years over that thing and despite some issues yet to fix (speaking of less sane, packing binary data into strings is so stupid, I wish stupidity hurt more than it does, namely apparently not at all), the thing is looking better than ever before. Treat the cause, not the symptoms. If a high turnover causes the project to be a mess, rewrite it once and then get one programmer, well-paid & otherwise motivated, to maintain it. That's not the only sensible action here. Ever-changing VCS is another symptom of deeper issues. Is it, maybe, the exactly one we're talking here namely the wish to always stay up-to-date, the angst to remain stale, that causes bad decisions? What about the multiple grid objects? Why not picking a language with a proper standard library that already has a grid object? One doesn't need to be a bad craftsman to blame their tools if the tools are rightful to blame (although I suppose that JS is pretty much bare of any alternatives in your case, I'm a desktop app developer). Why not refactoring/rewriting the thing ONCE and establish useful coding practices? Let's suppose there's a good reason for high turnover (there can't be, but let's just roll with it), factor out often needed parts, such as said grid object, in a common library, easy to find, so everybody new will pretty much stumble upon it themselves (assuming they're not utter newbies not having touched anything but a student project before, but that's another solvable issue). Cleaning up years of technical debt and/or sloppy code ain't easy and to be honest, I remember myself doing something similar, namely small changes, not disturbing the big picture too much in the moment but severely hampering the design in the long-term. Well, I was a noob back then and we had a senior engineer supervising me preventing issues like you described in the long run. Rewrite it ONCE and then keep it clean. Anyway, y
Member 9167057 wrote:
Why is there a high turnover?
DoD contract. Every 2-3 years, a new company under-bids the encumbent, and because they underbid, they can't afford to keep the people already doing the work, and have to hire new, less-experienced (to meet the pay scale) people. Eventually, the code base gets so screwed up, the project is simply killed off, a new company is brought on to do the same thing all over again, and the cycle repeats itself.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
Member 9167057 wrote:
Why is there a high turnover?
DoD contract. Every 2-3 years, a new company under-bids the encumbent, and because they underbid, they can't afford to keep the people already doing the work, and have to hire new, less-experienced (to meet the pay scale) people. Eventually, the code base gets so screwed up, the project is simply killed off, a new company is brought on to do the same thing all over again, and the cycle repeats itself.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013There's no remedy for that situation. A customer looking at costs above all else (i.e. quality) surely won't accept a rewrite for the sake of code quality because a rewrite is a year or so (estimate from my own work, yours may vary) with bills to pay but no new features or bugfixes (granted, a rewrite may remove some old bugs, but may just as well introduce new).
-
There's no remedy for that situation. A customer looking at costs above all else (i.e. quality) surely won't accept a rewrite for the sake of code quality because a rewrite is a year or so (estimate from my own work, yours may vary) with bills to pay but no new features or bugfixes (granted, a rewrite may remove some old bugs, but may just as well introduce new).
Member 9167057 wrote:
a rewrite is a year or so (estimate from my own work, yours may vary) with bills to pay but no new features or bugfixes (granted, a rewrite may remove some old bugs, but may just as well introduce new).
We have 20 ASP.Net WebForm apps :wtf: that we maintain right now. With regards to login/registration/environment/layout, they all work the same. At that point, they diverge into their specific domains. Beginning in February (and on my own time at home), I started writing a new MVC5 template that we can use as a jumping off point for rewrites. All of the shared functionality has been implemented, saving months of dev time. At least the various devs can concentrate ion their apps' content instead of also having to deal with the tedium of common infrastucture stuff. Some of the apps are small enough that they can be re-written in a matter of a few weeks. In order to pull off a re-write, the team has to be deep enough to be able to withstand carving one/two people off to do the the new stuff, while having enough sufficiently skilled devs maintaining the soon-to-be-legacy code.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
