....and continuous employment maybe?
IMHO, the reason developers want to redo EVERYTHING from scratch, is simple.....EGO!
Err... no. And I sincerely doubt your "16 years" of experience in software development. You're probably just the boss, not the actual work-horse.
So let me shed some light onto this:
Companies don't want to spend money on I.T. At all. Even when the company's primary function is an e-commerce site... their bread & butter (South Africa... *shrug*). So they try to get the cheapest deal they can. They hire a developer with little-to-no experience (or one that claims he has experience, but since they're oblivious to the fact and can easily have the wool pulled over their eyes when it comes to I.T, hires him). This is usually to take-over already-written code to add functionality to/maintain, or to actually write code from scratch. Most of the time it's taking over already-written code and USUALLY it's done by an outsourced party which has become too expensive for the company to maintain and deciding to hire an in-house programmer.
Since the developer has little-to-no experience, the mistakes they make (which I have seen time and time again and attribute to inexperience) add's up into one big ball of maintenance nightmare. It then takes so long to make a simple change to the website that work that was scheduled to happen (nb, NEW work) can't until the maintenance/functionality change happens first. In the end it's just bug after bug after bug. Fix one thing, introduce a new bug etc. These guys wait until the workload has built up to such an extent that they quit and move on to a different company. This usually takes +- 1 to 2 years. Depending on the size of the company and how involved other developers might be with the same project.
Enter, new programmer. Usually more experienced than the previous guy since the pay grade went up a bit in the 1-2 years the other one worked there (if he had 1 year of claimed experience, they need a 3 year experienced programmer according to their logic). Since the new programmer is more experienced than the previous one, and then takes over the existing work of maintaining the system and fixing any bugs AS WELL AS building in new functionality, he soon realizes what a nightmare JUST maintaining/fixing the code is.
This is where the "rewrite" comes in. Because 90% of the time the database is also such a mess that any kind of functionality being added to it would be like adding a new wing to beach-house built on the sand without a proper foundation. So you sit there, with your hands in your hair trying to bite your tongue and not go postal on everyone at the company for being dumb-asses. Since they'd much rather pay for a "manager" than a proper developer to get things fixed.
And this grows and grows and grows till it just gets to the tipping point and everything HAS to be rewritten.
HOWEVER I have to agree with you that rewriting software constantly to be on the latest frameworks is just insane. In a perfect world (my world, when I code usually) I write the code once with the future in mind. That is what software architects do. Such thinking, unfortunately, only comes with experience. Hence why I attribute those mistakes in the beginning as inexperience.
80% of your time has to go into writing *new* code (read, new functionality). 20% maintenance. If this is swapped around, then it's the quality of code forcing you backward and you have to consider re-doing it. BUT. Only redo it if you have someone that's experienced enough not to go paint the room's floor and find themselves in the corner opposite the door when they're almost finished...
For the people who says "business wants it asap so they have to do it asap" and "they pay so do it have no clue what they're talking about. 1 month to do an application in MIGHT be feasible IF time allows for all the other bull**** the programmers have to deal with (especially the lovely "open ended" specification where "something simple" changes where, in fact, it ****ing changes fundamental aspects of the application)
Doing it properly doesn't necessarily spending a long time on a project. This is why you have project managers who knows WTF they're doing and why you have a functional specification of what the client wants. However, you have to ****ing do it properly from the start otherwise you'll spend years (LITERALLY) on maintaining/fixing bugs and trying to make things work as functional changes/additions to the application are added.
That's how I felt in the interview I had today. I know that in the field I am adequately prepared to get the job done, but I didn't feel that way in the interview...
20 posts in the next week qualifies you. Check the announcements.
