3 ms·

Greenfield projects are 1% of a SE job. 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 is

by shocks 3y ago

Greenfield projects are 1% of a SE job. 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.

zabzonk 3y ago
> 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” understood. but sometimes the code really is crap, and possibly a danger to the business.
- jt2190 3y ago
  I think it’s more helpful to try and quantify that though, rather that just leave a vague “sometimes” response. 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.
- shocks 3y ago
  Most of the time it’s better to adapt existing code than light a match and start again. 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.
emerongi 3y ago
> Greenfield projects are 1% of a SE job. 99% is dealing with the after-effects of the decisions made during the 1% ;).
Nursie 3y ago
That’s brown-field at best. Green field (to me) is a new product entirely. A blank slate, a wonderful opportunity.
- shocks 3y ago
  Agreed. Opportunities like that are super rare though. Within the confines of an existing company it’s usually better to reuse established tech, for the sanity of your colleagues. :D
angarg12 3y ago
In 14 years I've got to work in greenfield projects exactly once. You are far more likely to end up working in a huge mess of legacy code...
- devnullbrain 3y ago
  I've worked on 2 just this calendar year
devnullbrain 3y ago
> Greenfield projects are 1% of a SE job. That very much depends on the person, industry and company.

by shocks 3y ago

zabzonk 3y ago

> 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” understood. but sometimes the code really is crap, and possibly a danger to the business.

jt2190 3y ago
I think it’s more helpful to try and quantify that though, rather that just leave a vague “sometimes” response. 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.
shocks 3y ago
Most of the time it’s better to adapt existing code than light a match and start again. 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.

emerongi 3y ago

> Greenfield projects are 1% of a SE job. 99% is dealing with the after-effects of the decisions made during the 1% ;).

Nursie 3y ago

That’s brown-field at best. Green field (to me) is a new product entirely. A blank slate, a wonderful opportunity.

shocks 3y ago
Agreed. Opportunities like that are super rare though. Within the confines of an existing company it’s usually better to reuse established tech, for the sanity of your colleagues. :D

angarg12 3y ago

In 14 years I've got to work in greenfield projects exactly once. You are far more likely to end up working in a huge mess of legacy code...

devnullbrain 3y ago
I've worked on 2 just this calendar year

devnullbrain 3y ago

> Greenfield projects are 1% of a SE job. That very much depends on the person, industry and company.