Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
In the end, throwing away is the same as performing a full refactoring. But you can refactor while it is running while you would have to maintain the old version while building the new one. So the refactoring path may be less costly in the end.
Only thing is: You have to actually do the refactoring. If you don't, the tech dept will cost more than both variants combined. -
@Oktokolo I guess that depends on the task at hand and the architecture you have
in the project I mentioned you'd have to refactor the core system and at that point I'd go "let's see what we can reuse" instead of "lets try to change 70% of our code" -
@LotsOfCaffeine Even if you have to rewrite it 100% twice, doing so might be be more feasible than trying to maintain the old beast as is while also creating a new version from scratch.
Prototypes end up on production servers because management doesn't want to wait until the "real" version is done. Out there a distinction between prototypes and the actual product just doesn't exist. Keep that in mind the next time you are asked to build a prototype - it will go live with >99% certainty and you will not be given the chance to rewrite it from scratch. -
@Oktokolo absolutely and thats why we need to educate our managers
-
@LotsOfCaffeine Or you know: Just assume you will have to maintain it until the end of your life and build it so it wouldn't make you kill yourself if that would actually be the case.
You can't educate managers. Most of them are immutable. -
@Oktokolo I would love to write higher quality code but we don't really get much time
deadlines are set cause someone signed a contract -
@LotsOfCaffeine If you don't have the balls to bust deadlines and are at the same time morally flexible enough to knowingly deliver a botched product, doing incremental refactorings whenever you have to touch the code again (and you will have to touch it a lot) really is the only thing you can do to lessen the pain...
Or you could just deliver the botched product and then change company to prepare hell for the next poor bastards who will have to maintain what you leave behind. -
@Oktokolo here's the best part: it won't be maintained much, we're already planning the successor. The new hardware is fairly far in development and the firmware (which uses a completely different architecture) is already being worked on.
But the current thing still has to be delivered, no matter how botched it is. We're considering some redesigns for next year but all that effort will be gone once we do the final delivery and the successor project gets going. -
@LotsOfCaffeine It almost never is that way outside the dreams of overly naive devs - but if you actually will have the time to not botch the actual product, creating an actual prototype first is fine.
Honestly idk but that one chapter from mythical man month, "Plan to Throw One Away", stuck with me:
"Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time."
In my current project I've seen this play out, initial development was very prototype-ish and just not well designed but when we got a somewhat decent state we had to continue with it instead of starting again and doing it properly. And now the consequences of that are hitting, progress for new features is incredibly slow, the software is very error prone, a bunch of dead code all around, ...
rant
wk340