Never Rewrite from Scratch

A

Aquarians

Two questions:

1) How many of you are old enough to have read "Things You Should Never Do, Part I" ( https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ ) by Joel, the guy who invented StackOverflow?

Although the article was written in 2000, I read it around 2006.

2) How many of you are old enough to have read "The Mythical Man Month"?

I never read it, heard bits and pieces and learned most of the stuff there the hard way (like "adding people late to a project makes it later").

My current employer made both #1 and #2 mistakes. Asked all my 30 years+ colleagues if they ever read or at least heard about Joel or the Mythical book, nothing. Well, no problemo, just my less than $1B capitalized employer will implode. (My 30 years- colleagues caused the problem in the first place so I'm not asking them, it's enough to see them. Stupid fucks covered in tattoos like some sort of fierce Chihuahuas. Stupid fucks who can't even speak my [national] language right but speak between them and to me in some vomit inducing least common denominator English scattered with least common denominator nationalisms when they reach the end of their short pipeline. Anyways, I'm not a hater just an observer).

I'm 40 by the way and gradually start to realize that my ability to read text (literacy) in addition to just numbers (engineering) might be an useful skill in this life.
 
Last edited:
"adding people late to a project makes it later"

I think the correct version is more like: "adding people to a late project makes it even later"

I agree with the jist of that article, although if you decide to rew write an old system from scratch i think you should still also be developing the old system at the same time as if it was the only system you have, not slowing down development on it or putting a freeze on it just because a new system is coming soon.
 
I have worked on legacy systems that were so old and poorly designed, had zero test coverage and were so costly to maintain that the best move was to replace them entirely. That being said, rewriting from scratch should not be taken lightly.
 
Spot on! I always told them never to rewrite those punchcards: It. All. Worked. Perfectly. Well. Already!

They managed to do the same mistake on all those snappy 3270 programs too!

Now we have all those "UX designers" hiding functionality from the lusers, hillarity ensues!!

'told ya (multiple times already!!)
 
Years ago a friend of mine and I were contracting with a firm to write a lot of code for their system. After about a year they went out and hired an engineer to replace us "expensive" contractors. 6 months later they called us back. It seems the new engineer thought a lot of our code superfluous and took it out. The whole platform crashed. We did NOT write superfluous code: the new engineer just did not understand why we wrote what we did. Yes, we documented the code, but had to work around a lot of legacy code the new guy didn't take time to read.
 
Don't big software projects are broken up into pieces? Each piece is updated when it's needed. Who write big software project in a single piece? Hunting down bug is a nightmare for one.
 
Peter8519 said:
Don't big software projects are broken up into pieces? Each piece is updated when it's needed. Who write big software project in a single piece? Hunting down bug is a nightmare for one.
More...

There are basically two major opposite strategies: Either split it up into many different "parts", whatever they may be. OR, put everything in the same "basket", effectively becoming "one part". Easy? Keep in mind any "part" may be anything and composed itself of "parts", ie. a procedure, function, method, class, ORB object, service, front-end, batch-job, queues, streams, etc.

There's no clear consensus what is preferable, and one would have to take into account the entire lifecycle of the software, not just development. So ideal solution will depend on many factors, most of them changing alot during the lifecycle and quite different between solutions.

Famous examples: Linux kernel (monolithic) vs HURD (microkernel), or more modern, SOA vs microservices (aka "real SOA")

The fact that circumstances, requirements and code will change, favour the agile mindset that whatever you make, make it easy to change later. Refactoring should always be an option, otherwise, building from scratch could be viable, especially for smaller components that would just take 1-2 weeks to complete.

Sounds ideal, but hard to have resources for alone and hard to accomplish in team(s).
 
Last edited:
It goes like this: albeit called programming "languages", in a comparison with real life languages they're more like alphabets. So the "C++ alphabet" resembles much the "Java alphabet" sort of like 26-letters Latin versus essentially the same with some às and ós and ßs.

But with the same alphabet (programming language) you can write a lot of different LANGUAGES (software applications). And the problem is not in the alphabet as 99.9% of the stupid interviews test for but in the APPLICATION. The reason you don't understand Hungarian is not that you're missing a few às and ós (like you know C++ but not templated variadic partial specialization mixins). New applications are constructs just as complex as natural languages AND THE ONLY WAY TO SPEAK THEM NATIVELY IS TO GROW INTO THEM. Otherwise learning them is a slow and painful process. Painful since stupid management starts pressuring you after a few weeks: what's taking you so long to learn Korean? Plus they don't give a fuck and can afford to not give a fuck since it's not them who have to learn ASAP. I love reading job ads (most of them actually) who state essentially: want a guy who thrives under overwork and tight deadlines and will hit the ground running on our 2 million lines of codes of KLINGONIAN crap he didn't have authority to write but will certainly have the responsibility to fix. I'm not saying you can't get to know a foreign application as you know a foreign language but it will take a lot of YEARS (YES, YEARS!) and most likely you'll just be fluent but still miss the parts of it you seldom encounter (but the native developer encountered at least once, I mean he freaking wrote the stuff).

So the real reason everyone wants to rewrite is as easy as that: they wanna grow native into it, everything else is a lie. Problem's the original developers will eventually leave so you'll end up where you started and at some point gotta have some poor souls learn the stupid app and try just maintain it not create another write-only crap.
 
Last edited:
Aquarians said:
It goes like this: albeit called programming "languages", in a comparison with real life languages they're more like alphabets. So the "C++ alphabet" resembles much the "Java alphabet" sort of like 26-letters Latin versus essentially the same with some às and ós and ßs.

But with the same alphabet (programming language) you can write a lot of different LANGUAGES (software applications). And the problem is not in the alphabet as 99.9% of the stupid interviews test for but in the APPLICATION. The reason you don't understand Hungarian is not that you're missing a few às and ós (like you know C++ but not templated variadic partial specialization mixins). New applications are constructs just as complex as natural languages AND THE ONLY WAY TO SPEAK THEM NATIVELY IS TO GROW INTO THEM. Otherwise learning them is a slow and painful process. Painful since stupid management starts pressuring you after a few weeks: what's taking you so long to learn Korean? Plus they don't give a fuck and can afford to not give a fuck since it's not them who have to learn ASAP. I love reading job ads (most of them actually) who state essentially: want a guy who thrives under overwork and tight deadlines and will hit the ground running on our 2 million lines of codes of KLINGONIAN crap he didn't have authority to write but will certainly have the responsibility to fix. I'm not saying you can't get to know a foreign application as you know a foreign language but it will take a lot of YEARS (YES, YEARS!) and most likely you'll just be fluent but still miss the parts of it you seldom encounter (but the native developer encountered at least once, I mean he freaking wrote the stuff).

So the real reason everyone wants to rewrite is as easy as that: they wanna grow native into it, everything else is a lie. Problem's the original developers will eventually leave so you'll end up where you started and at some point gotta have some poor souls learn the stupid app and try just maintain it not create another write-only crap.
More...

This is basically IT. People think writing code is hard, but inheriting code and having to maintain or refactor it, can be just as hard or harder. Especially since the projects, documentation, everything and everyone else is basically GONE at that point, so the mon^H^Hagic that was there originally is at that point missing.

Whenever code is written as COMMUNICATION though, there's a chance that elegant and easy-written code, can be easily inherited, provided stable language and libraries (deliberately not mentioning "frameworks" here!).

Golang is the closest match for me in this regard, as "The Go Way" is to just code what needs to be done without using too much fancy features and confusing self-inventions. This often means using just if and for and a bit more boilerplate and duplicate code, avoiding the dependency-spaghetti that borrowing, reusing and clever code often provide abundantly. Short and succinct naming makes for readable self-documenting code, comments reserved for explaining special cases and dependencies.
 
Last edited:
You must log in or register to reply here.
Back
Top