IME “the code is crap, we need to start again” really means “I don’t want to (or worse, can’t) read source code that isn’t mine”.
Reading and understanding someone else’s code then making and executing a plan to improve it is a much more valuable skill.
If you’re always working on greenfield projects, you’ll never understand what it means to build software with longevity.
understood. but sometimes the code really is crap, and possibly a danger to the business.
For example, one thing I look for is when the model can not explicitly express all of the states that we now need, and as a result the code has developed various “hacks” that try and simulate the additional states. This code tends to look like “guesses” or “assumptions”. For example, “if not red than blue” or “if no records than user is still on step one”. I tend to see developers spending hours in that kind of code, trying to confirm that the assumption is still always the correct one to make, or trying to shoehorn in another state, and it’s just a horrible time-suck. Improving the model at this point generally pays off in time saved puzzling.
For example, I’ve seen and participated in the transition of a completely undocumented custom web framework (with an entirely Redis based ORM) to an industry standard web framework with a MySQL backed ORM.
All of this happened without any customers noticing, no feature development pause, no huge “rewrite” branch requiring regular rebasing, and without the original development team responsible for the mess.
That was truly a work of art.
99% is dealing with the after-effects of the decisions made during the 1% ;).
Green field (to me) is a new product entirely. A blank slate, a wonderful opportunity.
Within the confines of an existing company it’s usually better to reuse established tech, for the sanity of your colleagues. :D
That very much depends on the person, industry and company.