3 ms·

>> Don't try to write software that will last 100 years. THIS. I've worked as a developer on huge, multi-year projects and I've worked on rip and tear six mon

>> Don't try to write software that will last 100 years. THIS. I've worked as a developer on huge, multi-year projects and I've worked on rip and tear six month projects and everything in between in the 10 years I've worked as a developer. None of the stuff I ever worked on was never maintained for more than 2-3 years after release before being nuked and built from scratch with some new fangled framework or database or data platform. When I first started as a developer, building your stuff to withstand the zombie apocalypse was something we all aspired to. We all wanted to be like the Y2K developers. You get called in 30 years after you retired to re-write your code because all these legacy systems are still running on the code you wrote when you were an angsty college graduate at your first development gig. The truth of the matter is companies don't need something that's bullet proof to last even 5 years any more. I've always felt in some regard, nuking products is done simply for upper management types to prove they're worth keeping around, more than these things need to be rebuilt.

cgrealy 4y ago
Your software probably won’t be running in 100 years, but in 10 years? 15? Absolutely possible. In fact, after 20 years writing software with various companies, the only ones that didn’t have code older than 10 years were the startups. But even then, that doesn’t matter. If you’re code is really complex, you’re going to struggle to come back to it in 6 months, never mind 6 years. Code should be as complex as it needs to be and no more. Write with maintainability in mind.
lowercased 4y ago
> None of the stuff I ever worked on was never maintained for more than 2-3 years after release before being nuked and built from scratch with some new fangled framework or database or data platform. OK... but... that's not universal. That's perhaps a symptom of resume-driven-development? I got a call in 2017 from someone asking about something I'd built in 2003. It was still in use. I worked with a team in 2015. Looked at their system 2 weeks ago - still using the same base foundation I'd laid out for them. I'm finishing up a project now rebuilding a system from 2005. There ended up being some IP and legal issues which ended up with "clean room rebuild" as the safest choice. But the system from 2005 was/is still running (for a little while longer). That you've worked places that rebuild/gut every 2-3 years... I don't know how 'normal' that actually is, save for JS front-end stuff, which seems to almost necessitate it.
- at-fates-hands 4y ago
  >> That you've worked places that rebuild/gut every 2-3 years... I don't know how 'normal' that actually is, save for JS front-end stuff, which seems to almost necessitate it. I lot of the places had huge portals, e-commerce sites, or multiple transactional application sites. Many of the places I worked transitioned into and out of various platforms. One place was a huge .Net place, had some run-ins with MS and then decided to move any and all of their stuff completely over to Salesforce. I heard three years later, MS lured them back and they went back to being a full blown .Net shop. One big motorsports company I worked at had 8 product lines all with an accompanying e-commerce site. They were literally in a 3 year "refresh" cycle. Every three years all the sites would be re-designed, rebuilt and re-released. The company was a huge .Net shop and they always used MS for their DB's and backend. Once libraries like Knockout and Angular got popular, it just became a three year run of JS frameworks/libraries battling it out to see which one we used next. The sites literally went from Knockout to Angular to ReactJS to Vue. By the time they had gotten around to ReactJS, I had already left the company, but the cycles they were on were just crazy and continue to this day. Another huge corporation I worked for had multiple portals. We literally re-built them all within a 3 year period from scratch, then it was in maintenance mode for a while until we got a new CIO who then decided he wanted to move to a different stack. Rinse, repeat. Less than 5 years, the cycle started all over again. A health care company I worked for wanted to build a Wellness app for their clients (this was a new thing back then). Their direct competitor had one and they figured they needed one too to keep up. We built that in the span of about 18 months. Gets released, gets rave reviews, we have another year of front-end and DB improvements, everything going smoothly. Apparently the competitor launched a mobile app for their Wellness app. This was about a year before responsive design really took off. They panic, nuke our Wellness app, and then had two teams (one Android, the other iOS) hastily build the app and release it. Just started working for a huge health care company. First project I was on was to take several different billing systems and create a transactional app for two teams so they could manage everything out of a single app instead of using multiple systems to log into and out of constantly every day. We built that over the course of three years. Then the initiative was to replace ALL the billing systems the team was using with a single system. Apparently the first meeting all the executive types wanted our entire team back on the project to give direction and come up with a dev plan. Again, just about the 5 year mark, all of our work got nuked. In hindsight, it was never always some new framework. There were consistent external or internal factors (good or bad) that was driving these decisions. Its kind of weird finding out this is by no means normal, but when you spend so many years and the same things keep happening, you just assume this is normal everywhere.
sumtechguy 4y ago
Most code does not last long. I have found that someone that is adding complexity is usually showing off, board, does not understand the requirement, is missing something. I usually curb my own natural tendency to do this by saying 'what is the bare min to do this one thing'. Then write what would need to be done in the comments if we wanted it to do those other 'cool 5 things'. Also if you are using scrum or kanban it is a good place to add a story to say 'lets do those 5 things'. Then see if it ever gets any traction. You can write amazing cool code. But most of the time 3 people will ever us it and they will only use it for that one thing they wanted in the first place. I have been writing code for 25+ years now. My exp is similar to yours. Very little code survives. One proj I worked on if you still wanted to write on it you would need to know watcom SQL (sybase), MFC 4.0, win98s version of win32, and the quirks of those 3 systems. NO one is going to want to work on that sort of project unless there are many zeros on the per hour cost. That was not a small project either with well over 500 modules and hundreds of screens. I have watched project after project either killed or re-written. Code in most cases does not last that long. Of course there are some exceptions. But that is rare, the common path is most code does not last long.
petsfed 4y ago
To everyone saying "your code doesn't have to last that long", did y'all miss that the OP is talking about embedded C? There is no nuke and pave with a new framework on an embedded system. At best, you'll see the infrastructure to deliver firmware updates rewritten, but mostly the customer expects the firmware/software to just run until such time as the hardware fails.

cgrealy 4y ago

Your software probably won’t be running in 100 years, but in 10 years? 15? Absolutely possible. In fact, after 20 years writing software with various companies, the only ones that didn’t have code older than 10 years were the startups. But even then, that doesn’t matter. If you’re code is really complex, you’re going to struggle to come back to it in 6 months, never mind 6 years. Code should be as complex as it needs to be and no more. Write with maintainability in mind.

lowercased 4y ago

> None of the stuff I ever worked on was never maintained for more than 2-3 years after release before being nuked and built from scratch with some new fangled framework or database or data platform. OK... but... that's not universal. That's perhaps a symptom of resume-driven-development? I got a call in 2017 from someone asking about something I'd built in 2003. It was still in use. I worked with a team in 2015. Looked at their system 2 weeks ago - still using the same base foundation I'd laid out for them. I'm finishing up a project now rebuilding a system from 2005. There ended up being some IP and legal issues which ended up with "clean room rebuild" as the safest choice. But the system from 2005 was/is still running (for a little while longer). That you've worked places that rebuild/gut every 2-3 years... I don't know how 'normal' that actually is, save for JS front-end stuff, which seems to almost necessitate it.

at-fates-hands 4y ago
>> That you've worked places that rebuild/gut every 2-3 years... I don't know how 'normal' that actually is, save for JS front-end stuff, which seems to almost necessitate it. I lot of the places had huge portals, e-commerce sites, or multiple transactional application sites. Many of the places I worked transitioned into and out of various platforms. One place was a huge .Net place, had some run-ins with MS and then decided to move any and all of their stuff completely over to Salesforce. I heard three years later, MS lured them back and they went back to being a full blown .Net shop. One big motorsports company I worked at had 8 product lines all with an accompanying e-commerce site. They were literally in a 3 year "refresh" cycle. Every three years all the sites would be re-designed, rebuilt and re-released. The company was a huge .Net shop and they always used MS for their DB's and backend. Once libraries like Knockout and Angular got popular, it just became a three year run of JS frameworks/libraries battling it out to see which one we used next. The sites literally went from Knockout to Angular to ReactJS to Vue. By the time they had gotten around to ReactJS, I had already left the company, but the cycles they were on were just crazy and continue to this day. Another huge corporation I worked for had multiple portals. We literally re-built them all within a 3 year period from scratch, then it was in maintenance mode for a while until we got a new CIO who then decided he wanted to move to a different stack. Rinse, repeat. Less than 5 years, the cycle started all over again. A health care company I worked for wanted to build a Wellness app for their clients (this was a new thing back then). Their direct competitor had one and they figured they needed one too to keep up. We built that in the span of about 18 months. Gets released, gets rave reviews, we have another year of front-end and DB improvements, everything going smoothly. Apparently the competitor launched a mobile app for their Wellness app. This was about a year before responsive design really took off. They panic, nuke our Wellness app, and then had two teams (one Android, the other iOS) hastily build the app and release it. Just started working for a huge health care company. First project I was on was to take several different billing systems and create a transactional app for two teams so they could manage everything out of a single app instead of using multiple systems to log into and out of constantly every day. We built that over the course of three years. Then the initiative was to replace ALL the billing systems the team was using with a single system. Apparently the first meeting all the executive types wanted our entire team back on the project to give direction and come up with a dev plan. Again, just about the 5 year mark, all of our work got nuked. In hindsight, it was never always some new framework. There were consistent external or internal factors (good or bad) that was driving these decisions. Its kind of weird finding out this is by no means normal, but when you spend so many years and the same things keep happening, you just assume this is normal everywhere.

sumtechguy 4y ago

Most code does not last long. I have found that someone that is adding complexity is usually showing off, board, does not understand the requirement, is missing something. I usually curb my own natural tendency to do this by saying 'what is the bare min to do this one thing'. Then write what would need to be done in the comments if we wanted it to do those other 'cool 5 things'. Also if you are using scrum or kanban it is a good place to add a story to say 'lets do those 5 things'. Then see if it ever gets any traction. You can write amazing cool code. But most of the time 3 people will ever us it and they will only use it for that one thing they wanted in the first place. I have been writing code for 25+ years now. My exp is similar to yours. Very little code survives. One proj I worked on if you still wanted to write on it you would need to know watcom SQL (sybase), MFC 4.0, win98s version of win32, and the quirks of those 3 systems. NO one is going to want to work on that sort of project unless there are many zeros on the per hour cost. That was not a small project either with well over 500 modules and hundreds of screens. I have watched project after project either killed or re-written. Code in most cases does not last that long. Of course there are some exceptions. But that is rare, the common path is most code does not last long.

petsfed 4y ago

To everyone saying "your code doesn't have to last that long", did y'all miss that the OP is talking about embedded C? There is no nuke and pave with a new framework on an embedded system. At best, you'll see the infrastructure to deliver firmware updates rewritten, but mostly the customer expects the firmware/software to just run until such time as the hardware fails.