10 ms·

The Messy Page Or: why I don't like greenfield projects

83 points by tim_sw 3y ago

lloydatkinson 3y ago
Sounds like the author is majorly suffering with analysis paralysis, something that’s quite relatable. Still, I can’t say I’ve suffered it to the extent I’d rather be stuck debugging spaghetti projects.
- catchnear4321 3y ago
  ever completed a project to find out 6+ months later that it was never used, for reasons? working on an existing mess with outstanding complaints at least better guarantees that it is a valued mess. some environments, that’s not about comfort, it is about survival.
  - oweiler 3y ago
    There are enough devs who don't give a shit if the project is actually used... Or useful
    - catchnear4321 3y ago
      yes, but not always on the project.
  - mastax 3y ago
    My dad spent the first 12 years of his career working on the Advanced Gun System for the DDG1000 destroyer program. Never got used. I can understand why he has such a disdain for government waste.
    - jkhdigital 3y ago
      The entire DDG1000 program was a boondoggle. An active-duty friend of mine who is well-connected in naval strategy circles keeps repeating that the Navy won’t pull its head out of its ass until a few large hulls end up at the bottom of the South China Sea.
  - sanitycheck 3y ago
    Most of what we do is pretty useless anyway. Does the world really need another online shop, another way to watch movies online, another social network? I think projects which get cancelled or never released are great. I get to do the fun parts - the design/architecture and solving the hard implementation problems - but not the endless of hours of tweaking, bug fixing, dealing with the inevitable pre-release business pivot which turns the software from a beautiful solution to Problem A into a horrible kludge for Problem B. And I still get paid!
    - ipaddr 3y ago
      These are best projects. You get to do the fun part and don't need to support the product. And you get paid.
  - electroly 3y ago
    Sure, I had a project canceled after I completed it. Not a single user ever saw it. I still got paid the same and I never had to maintain that code or fix any bugs, and I got to keep the knowledge I learned. Probably not great for career development to have this happen repeatedly but it was pretty great the one time it happened to me.
  - throwaway173738 3y ago
    A quarter of my output over the last 12 years has ended up this way. But most of those projects were built as MVPs to prove a concept by installing a demo system in situ and we learned a ton from it. And some of those projects I finished for 1/100 the cost of our competitors POC systems in the same market. A lot of what makes my job enjoyable or not is in whether there’s a business case for what I’m doing. If some VP is asking me to fiddle around with something that’s never going anywhere I’ll be miserable. But if I’m fiddling around to build something that drives more revenue or makes people happy with our product then I’m there.
  - Nursie 3y ago
    One of the more fun projects of the last ten years was a project designed to fail. We had an in-house data centre, and we needed more capacity at certain times of the year. Justification was needed for more dedicated capacity in the face of cloud infrastructure. So we built a system to use spot pricing to spin up extra instances, securely, on AWS, google cloud or azure. This could meet bursts of demand at busy times. At the end of the exercise we had a working system and managed to prove it was better value and more resilient for the organisation to increase on-premises capacity. Fun project though!
- esafak 3y ago
  This is a problem that afflicts perfectionists; they want to consider all the options so they can pick the best one, and a blank canvas has nothing but options.
catchnear4321 3y ago
there’s nothing wrong with this opinion, attitude, what have you. it is useful. important. not every project gets a clean start. not everyone that starts a project sees it through. my preference is making my own mess and iterating it out of one. decreases the hunt for bodies. but preference doesn’t always equate to reality. also depends on the project. if there’s a delightfully boring industry standard for most needs, starting from nothing results in a cleaner product. starting with an existing, misguided implementation is just greenfield with extra steps.
- opmelogy 3y ago
  > there’s nothing wrong with this opinion, attitude, what have you. it is useful. important. This is dead on. There's a lot of value in knowing where one fits and thrives in the dev process. We need people that thrive building the v1's and we need people that thrive extending the v1's into v2's and beyond. They are both really valuable.
chefandy 3y ago
I get that but I couldn't be more different: I love greenfield projects. I find designing a robust, performant and reliable architecture to be the most interesting part of the process.
- wouldbecouldbe 3y ago
  Yeah same here. Much more fun than patching other people (or your own) work. But different personalities, gross of the proffesional pro work is not greendfield sadly!
  - chefandy 3y ago
    Yeah. I do love a good bug hunt or an adrenaline spiking incident response (though I've never been traumatized with any real disasters) but I get "fresh SimCity map" feels starting something new.
    - chefandy 3y ago
      (Though I suppose people who don't like greenfield projects probably don't like fresh SimCity maps, either!)
- marklubi 3y ago
  I too love greenfield projects. It's so satisfying to build something amazing from scratch.
- sph 3y ago
  I have to port an app I've written in Rust to Elixir. [1] It is Sunday and I have to force myself not to open Emacs today. That's the best of both worlds: a reimplementation of an existing project. You have all the freedom of a greenfield project, and you don't suffer from the "blank page syndrome" or writer's block the author talks about. Port the tests over, then rewrite everything, this time with a better architecture. [2] -- 1: Since someone is bound to ask, I am incorporating a Rust standalone app into a larger Elixir monolith. Because while static typing is nice, turning a Rust app into a highly-concurrent and highly resilient with native OS primitive (threads & co.) or, yikes, async, is masochistic when I have the power of the BEAM at my disposal. 2: Tongue-in-cheek here, I am well aware of https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect
baremetal 3y ago
Not everyone wants to architect software. The same way not everyone wants to run a business. Me personally, I love designing a system from scratch. That is a big part of the fun of writing software for me.
mpetrovich 3y ago
My goodness, this describes me perfectly as well. The countless choices of a blank slate brings anxiety to a recovering perfectionist like me. Do I choose A or B or Z? I prefer improving things rather than creating them from nothing. I’ve come to a similar conclusion as the author as far as how to get out of the fog of greenfield: Satisfice instead of optimize. In this context, optimizing refers to choosing the best among N options. In contrast, satisficing means choosing the first option that’s good enough. Often, the opportunity cost saved from satisficing is greater than the marginal value gained from optimizing.
- linuxdude314 3y ago
  Unfortunately not very much engineering goes into software these days. What you describe is a very common pitfall that is completely avoidable using well established frameworks. In systems engineering one of the key principles is that you build a system to meet requirements. This means that prior to making architecture diagrams or picking your database, you instead meet with all of the stakeholders and enumerate a list of what is required of the system or service you are building. Once you have requirements, you simply look at the normal trade offs (operational ease of use, cost, license model, performance, etc…) and make decisions accordingly. There is still some room for decision making, but if you apply a tried and true framework it’s helps cut down on the decision making a lot.
TheGoodBarn 3y ago
It’s kinda like a Marie Kondo vs a carpenter type situation and I get both sides.
bob1029 3y ago
I like being right in the middle of this spectrum. I used to be really far into "rewrite", but now I've seen what can be done with proper discipline. We've been able to roll with the same monolith for about 5 years now. The biggest perceived benefit for me is the common ground it provides for the business & our customers. Everyone has been speaking the same language for a really long time now and the benefits of that have accumulated. I've been allowed to forget about code & processes that I helped develop because they became so stable that someone else assumed complete ownership. The last time I personally built our software from source (with intent to publish/deliver to a customer) was circa 2020. If we were to rewrite this thing from zero with reckless abandon, all of that confidence & trust that built up over half a decade would be lost. We are in the process of investigating alternative architectures, but we are doing it in a way where we minimize how much we have to involve our customers and other team members. Things like "backwards compatible configuration" and "don't change the UI if it works" are headline in our greenfield.
- anoncow 3y ago
  > If we were to rewrite this thing from zero with reckless abandon… Your response made me think about this - https://randsinrepose.com/archives/stables-and-volatiles/ https://randsinrepose.com/archives/stables-and-volatiles/
JoeAltmaier 3y ago
I've worked with a business partner for 20 years. I prototype rapidly; he perfects and makes a sparkling gem of a product. Everybody we know, knows this, hires us because of this. We've hired others in the past for special skills - building data schemas, graphic designers, problem solvers, debugging and testing. Because there are many skill sets. I understand the OP very well. We'd all do better by understanding this!
beebeepka 3y ago
Greenfield projects are the best. Second best part is scaling them up or down, changing, improving. It's like having a kid except I don't get even mildly attached to the code itself. I guess I like the responsibility and dislike conformity.
incrudible 3y ago
You should be uncomfortable. If you are comfortable, you are not growing, as a developer and as a person. Odds are, life is gonna throw some heavy curveballs at you. Build resilience while you are still on tutorial island.
CM30 3y ago
Yeah, I feel like this as well, at least to a degree. With a new blank project, you have to design, structure and setup everything from scratch, which can feel extremely overwhelming. It's one of the reasons I haven't finished an entire game, or CMS, or other such project on my own despite being a programmer for decades. I end up stuck in the weeds of how to structure the feeling, and go down a bunch of random computer science and best practices rabbit holes in the process. But hey, I guess it's a spectrum that all programmers fall somewhere on. You might be good at starting things from scratch, you might be good at polishing up and improving existing projects, or you might be somewhere in between.
desireco42 3y ago
I am complete opposite. Not that I mind messy pages or projects, I love to refactor and clean up. Just new projects always give you a chance to do really well and clean.
vrglvrglvrgl 3y ago
[dead]
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.
- 3y ago
wpietri 3y ago
Honestly, I think this kind of discomfort with a blank page is an excellent thing to have on the team with a greenfield project. One of the ways greenfields go wrong is confident people bringing too much to them. They're sure that features X, Y, and Z are vital. They're sure that the best technical approach means architecture A with framework B and library C. So they jump in and build things, ignoring the lack of product-market fit and the broken feedback loop with users. The people really being served are not the eventual customers, but the team itself. But being uncomfortable with the wide-open sweep of a greenfield project can be put to use to keep the building constrained to what we really know. For a startup I did a while back, we spent the first few months only building disposable prototypes. We wrote only garbage code, and then we put it in the garbage. It wasn't until user testing showed promise that we wrote the first lines of production code. Even then we were very cautious about our technological commitments, because we knew how much we still had to learn about our market and their needs.
- Brian_K_White 3y ago
  This. I was thinking that they had the right idea themselves when they talked about basic research. In basic research, there really is no such thing as failed or wasted work unless you constructed a faulty experiment. Whatever happens, it's all added to human knowledge. Finding out that something is not possible, or not possible this particular way, is still finding out something. If you're thinking that way, then you never worry about wasting work. You're plugging away at a methodical process and none of it is a waste. But you have to be thinking that the job is to perform these steps and record the result, not the job is to discover a miracle. Getting back to software, as for the blank page, just how blank is blank? Are we talking don't even know what industry we want service or what? Because if the page is blank, there are many tools and methods, but they are not all the same. So the first job is not necessarily to vomit any code but to characterize the job and narrow the tool selection to those which optimize whatever you're going to need to do the most. Maybe you have to vomit some code to figure that out, but then that was the job of that code was to find something out, not to be a product.
- jahewson 3y ago
  100% agree. I’ve found that one way to make sure that disposable prototypes are disposed of is to build them someplace like CodeSandbox, where nobody can mistake them for the real thing.
protojacked 3y ago
i don’t like greenfield projects cuz they’re hard
mkl95 3y ago
My pet peeve with so-called greenfield projects is that actual greenfield projects are extremely rare. As soon as your shiny new service has to interact with other services, you will run into their stakeholders expectations, and your project will inevitably build up tech debt until you go full circle. You may blame essential complexity, but often it's just the unstable nature of the industry.
phkahler 3y ago
I appreciate the authors position, but I like Greenfield projects. It's best to have a goal, but the blank page offers an opportunity to search for an optimal or satisfying solution. The author mentions having early work thrown away, but that's part of the search. Of course this needs some freedom to fail and change course, so environment matters. Easier to do on personal projects than under a deadline.
neilv 3y ago
> Maybe that’s why I like debugging so much. I hate debugging. Two big programming barriers I noticed as a kid were: (1) walls of complexity, and (2) debugging interruptions that took lots of time and ruined momentum. I learned how and when to avert both barriers. And I love greenfield, partly because I can apply what I've learned about both. (And partly because I like working creatively, and with a holistic understanding of the problem domain and approach.) It's great that there are people who dislike greenfield and love well-defined debugging tasks. I can trade them my brussels sprouts, for their chocolate cake.
moonshinefe 3y ago
I had the opposite experience. I worked at companies in the past that had legacy codebases that were strung together by inexperienced programmers years ago. This meant: - The code was basically just spaghetti with differing standards and architectures depending what area you were in. Making even the most simple changes or basic features would often break something else in unexpected ways. - There were never any tests, and in one company's case, they even had a no comments policy "because the code changed often and they didn't want to maintain the comments' accuracy". - Said companies did not have the money (or want to spend it) in rewriting any significant portion of the apps, despite them being on years ago abandoned frameworks. - In one case, this meant we had to patch a web framework and maintain it ourselves because of security vulnerabilities. I realize maybe the author worked on established but not-so-bad projects, but working on a greenfield is imo the far better experience. You can actually push for standards, create impactful features in a timely manner, and do refactors without fear that 20 other things are going to break because the architecture is fresh in your mind, documented and you have up-to-date regression tests. The author also seems to primarily be afraid they'll do something sub-optimally and have to delete code. I actually love deleting code. Some of the most satisfying refactors I've done involve cutting down on complexity and removing portions of code. I get that you don't want to waste effort, but I don't think it's a healthy attitude to have toward your code if you get negative emotions over finding better solutions.
- Kamq 3y ago
  > Making even the most simple changes or basic features would often break something else in unexpected ways. As I get older I find myself valuing locality of behavior over most other concerns. I can deal with some pretty spaghetti-ish code that's bad along many traditional metrics as long as I know what my changes are going to impact.
  - moonshinefe 3y ago
    > As I get older I find myself valuing locality of behavior over most other concerns. I absolutely agree, that's a big one for me as well and when I'm designing new features it's always a high priority.
ChrisMarshallNY 3y ago
I dunno. I've been doing greenfield projects for almost my entire career. I'm fairly good at going into an existing codebase, and fixing/improving, but I prefer to do my own architecture. To each, their own, I guess.
robertlagrant 3y ago
This is one of the reasons why I like the agile approach. Make anything that barely runs, and start changing it.
Scubabear68 3y ago
It depends on your personality. Some people are “serial starters”. They have enormous creative fire, feel a burning need to create something new, and once it starts taking form and people start using it, they get bored and move on. Others are better finishers. They will patiently build out the core until all the required bells and whistles and niceties are there. It’s very rare to someone good at both, such as Linus Torvalds. Maybe that is a third category, someone who starts a few great things and sticks with them for life?
- mdgrech23 3y ago
  I feel like these people make for terrible for coworkers. You'll build out a nice class or something that is being widely used and providing tons of value only to discover for a new key component they didn't use your class, built their own to no real advantage. It's obnoxious. Another example. I did a proof of concept, demoed it to the big bosses. Got approval for it to be built. I'm not so much at the individual contributor level anymore though. Anyhow come to find the dev team didn't build off of what I started. Built from scratch and spent the first month reimplementing what I had already built. So dumb. Why do we keep doing this in our industry.
  - DJBunnies 3y ago
    Did you ask why
angarg12 3y ago
> There are too many options. Too many tools to chose and decisions to be made. All of the code has to be written, including the boilerplate and the boring stuff. I disagree a bit here. Sure, there are hundreds (thousands?) of databases out there. However, once you add your business requirements, and second+ order considerations (e.g. is this database battle tested in production? is it supported? is it supported in our company specifically?) the choices narrow down dramatically. In fact I dare say that in most greenfield projects you can probably narrow most tech choices to less than a handful.
yieldcrv 3y ago
analysis paralysis is a newb issue
waynesonfire 3y ago
> I wouldn’t say I hate the blank page, but I also don’t like it. In fact, I try to get rid of it as fast and as soon as I can. What a weird impulse. Getting rid of a blank page ASAP!! I stopped reading here. Author prefers looking at a page of ads.
bombcar 3y ago
Every pile of spaghetti crap started out as a greenfield project at some point - so the question is why they all end up spaghetti crap piles?
mcv 3y ago
> I really, really don’t like greenfield projects. There are too many options. Too many tools to chose and decisions to be made. All of the code has to be written, including the boilerplate and the boring stuff. Thanks but no thanks. Give me a messy project instead. You know you can make your greenfield project messy, right? Over the past few years, I discovered I really enjoy projects that are uncertain, where nobody knows yet how it's all supposed to work and what the end result is going to look like. Projects where you try stuff only to throw it away. I've done projects like that, and they were my favourite projects ever. I love to experiment, crank our a quick proof of concept, only to rewrite it in a different framework and refactor it several times over the first year.
sublinear 3y ago
> I’d rather have a messy bit of code that has a bug in it than an empty file. There's at least a third scenario that busts this dichotomy and also isn't the overconfident junior dev nonsense in some of the other comments. I've seen enough of those messy bugs and worked on similar enough projects that are far better put together. I just want to replicate their success. I'll be shamelessly stealing ideas under the guise of "best practices" and I won't worry about the outcome because I already know. The code from me will be easy to read and well documented and nobody will notice apart from the suspicious lack of drama, as it should be.
heavyset_go 3y ago
> I really, really don’t like greenfield projects. There are too many options. Too many tools to chose and decisions to be made. All of the code has to be written, including the boilerplate and the boring stuff. Thanks but no thanks. Give me a messy project instead. I have a hard time relating. Some of my favorite gigs were where I got to come in and design projects from the ground up. It's where you get to exercise an engineering mindset, where you're adhering to constraints while trying to meet requirements and setting the groundwork for potentially years of contribution, change and adaption.
- intelVISA 3y ago
  Greenfield projects are the Elysian fields for makers. It definitely seperates the builders from the importers. No shade on the latter, a job's a job to most.
  - marssaxman 3y ago
    This particular maker-builder loves clean-up work. Yes, it's great when you have a free hand to design something beautiful and new, but it can be even more satisfying to begin with a mess, dig through the crud, find the heart of the machine, and polish it to a gleam. If you start with a perfectly clear vision, it is easy to feel disappointed by the rough edges and unpleasant quirks which inevitably creep into the finished product - but when you start with something ugly, which your work then uplifts, the result might be more than you hoped for.
- emodendroket 3y ago
  Well, you’re still doing that in an existing project. You’re just dealing with constraints that are in the current context frustrating or nonsensical.
olvy0 3y ago
I'm the same, as I keep telling to my coworkers and internal customers. Just give me a long list of bugs to fix and I'll be happy. But given a completely new project I get into analysis paralysis for several hours/days, researching alternatives etc. I am much better at adding new features to existing code. The constraints are much better defined. I also always strive for perfect backwards compatibility if possible, which is both great for the users (since they have to do nothing, upgrading just works) and also great for me, since it's another set of interesting and challenging constraints to work against. I got slightly better in getting out of analysis paralysis by doing Advent of Code in real time. This forced me to start writing code, fast. I think the effect has worn off by now though.
acuozzo 3y ago
The beginning part is the work I truly enjoy doing. Is there a specific name for it? I enjoy designing architecture and protocols, especially when doing so requires me to get down to the bits and even more when doing so requires me to work under tight constraints.

83 points by tim_sw 3y ago

Sounds like the author is majorly suffering with analysis paralysis, something that’s quite relatable. Still, I can’t say I’ve suffered it to the extent I’d rather be stuck debugging spaghetti projects.

catchnear4321 3y ago
ever completed a project to find out 6+ months later that it was never used, for reasons? working on an existing mess with outstanding complaints at least better guarantees that it is a valued mess. some environments, that’s not about comfort, it is about survival.
- oweiler 3y ago
  There are enough devs who don't give a shit if the project is actually used... Or useful
  - catchnear4321 3y ago
    yes, but not always on the project.
- mastax 3y ago
  My dad spent the first 12 years of his career working on the Advanced Gun System for the DDG1000 destroyer program. Never got used. I can understand why he has such a disdain for government waste.
  - jkhdigital 3y ago
    The entire DDG1000 program was a boondoggle. An active-duty friend of mine who is well-connected in naval strategy circles keeps repeating that the Navy won’t pull its head out of its ass until a few large hulls end up at the bottom of the South China Sea.
- sanitycheck 3y ago
  Most of what we do is pretty useless anyway. Does the world really need another online shop, another way to watch movies online, another social network? I think projects which get cancelled or never released are great. I get to do the fun parts - the design/architecture and solving the hard implementation problems - but not the endless of hours of tweaking, bug fixing, dealing with the inevitable pre-release business pivot which turns the software from a beautiful solution to Problem A into a horrible kludge for Problem B. And I still get paid!
  - ipaddr 3y ago
    These are best projects. You get to do the fun part and don't need to support the product. And you get paid.
- electroly 3y ago
  Sure, I had a project canceled after I completed it. Not a single user ever saw it. I still got paid the same and I never had to maintain that code or fix any bugs, and I got to keep the knowledge I learned. Probably not great for career development to have this happen repeatedly but it was pretty great the one time it happened to me.
- throwaway173738 3y ago
  A quarter of my output over the last 12 years has ended up this way. But most of those projects were built as MVPs to prove a concept by installing a demo system in situ and we learned a ton from it. And some of those projects I finished for 1/100 the cost of our competitors POC systems in the same market. A lot of what makes my job enjoyable or not is in whether there’s a business case for what I’m doing. If some VP is asking me to fiddle around with something that’s never going anywhere I’ll be miserable. But if I’m fiddling around to build something that drives more revenue or makes people happy with our product then I’m there.
- Nursie 3y ago
  One of the more fun projects of the last ten years was a project designed to fail. We had an in-house data centre, and we needed more capacity at certain times of the year. Justification was needed for more dedicated capacity in the face of cloud infrastructure. So we built a system to use spot pricing to spin up extra instances, securely, on AWS, google cloud or azure. This could meet bursts of demand at busy times. At the end of the exercise we had a working system and managed to prove it was better value and more resilient for the organisation to increase on-premises capacity. Fun project though!
esafak 3y ago
This is a problem that afflicts perfectionists; they want to consider all the options so they can pick the best one, and a blank canvas has nothing but options.

catchnear4321 3y ago

there’s nothing wrong with this opinion, attitude, what have you. it is useful. important. not every project gets a clean start. not everyone that starts a project sees it through. my preference is making my own mess and iterating it out of one. decreases the hunt for bodies. but preference doesn’t always equate to reality. also depends on the project. if there’s a delightfully boring industry standard for most needs, starting from nothing results in a cleaner product. starting with an existing, misguided implementation is just greenfield with extra steps.

opmelogy 3y ago
> there’s nothing wrong with this opinion, attitude, what have you. it is useful. important. This is dead on. There's a lot of value in knowing where one fits and thrives in the dev process. We need people that thrive building the v1's and we need people that thrive extending the v1's into v2's and beyond. They are both really valuable.

chefandy 3y ago

I get that but I couldn't be more different: I love greenfield projects. I find designing a robust, performant and reliable architecture to be the most interesting part of the process.

wouldbecouldbe 3y ago
Yeah same here. Much more fun than patching other people (or your own) work. But different personalities, gross of the proffesional pro work is not greendfield sadly!
- chefandy 3y ago
  Yeah. I do love a good bug hunt or an adrenaline spiking incident response (though I've never been traumatized with any real disasters) but I get "fresh SimCity map" feels starting something new.
  - chefandy 3y ago
    (Though I suppose people who don't like greenfield projects probably don't like fresh SimCity maps, either!)
marklubi 3y ago
I too love greenfield projects. It's so satisfying to build something amazing from scratch.
sph 3y ago
I have to port an app I've written in Rust to Elixir. [1] It is Sunday and I have to force myself not to open Emacs today. That's the best of both worlds: a reimplementation of an existing project. You have all the freedom of a greenfield project, and you don't suffer from the "blank page syndrome" or writer's block the author talks about. Port the tests over, then rewrite everything, this time with a better architecture. [2] -- 1: Since someone is bound to ask, I am incorporating a Rust standalone app into a larger Elixir monolith. Because while static typing is nice, turning a Rust app into a highly-concurrent and highly resilient with native OS primitive (threads & co.) or, yikes, async, is masochistic when I have the power of the BEAM at my disposal. 2: Tongue-in-cheek here, I am well aware of https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect

baremetal 3y ago

Not everyone wants to architect software. The same way not everyone wants to run a business. Me personally, I love designing a system from scratch. That is a big part of the fun of writing software for me.

mpetrovich 3y ago

My goodness, this describes me perfectly as well. The countless choices of a blank slate brings anxiety to a recovering perfectionist like me. Do I choose A or B or Z? I prefer improving things rather than creating them from nothing. I’ve come to a similar conclusion as the author as far as how to get out of the fog of greenfield: Satisfice instead of optimize. In this context, optimizing refers to choosing the best among N options. In contrast, satisficing means choosing the first option that’s good enough. Often, the opportunity cost saved from satisficing is greater than the marginal value gained from optimizing.

linuxdude314 3y ago
Unfortunately not very much engineering goes into software these days. What you describe is a very common pitfall that is completely avoidable using well established frameworks. In systems engineering one of the key principles is that you build a system to meet requirements. This means that prior to making architecture diagrams or picking your database, you instead meet with all of the stakeholders and enumerate a list of what is required of the system or service you are building. Once you have requirements, you simply look at the normal trade offs (operational ease of use, cost, license model, performance, etc…) and make decisions accordingly. There is still some room for decision making, but if you apply a tried and true framework it’s helps cut down on the decision making a lot.

TheGoodBarn 3y ago

It’s kinda like a Marie Kondo vs a carpenter type situation and I get both sides.

bob1029 3y ago

I like being right in the middle of this spectrum. I used to be really far into "rewrite", but now I've seen what can be done with proper discipline. We've been able to roll with the same monolith for about 5 years now. The biggest perceived benefit for me is the common ground it provides for the business & our customers. Everyone has been speaking the same language for a really long time now and the benefits of that have accumulated. I've been allowed to forget about code & processes that I helped develop because they became so stable that someone else assumed complete ownership. The last time I personally built our software from source (with intent to publish/deliver to a customer) was circa 2020. If we were to rewrite this thing from zero with reckless abandon, all of that confidence & trust that built up over half a decade would be lost. We are in the process of investigating alternative architectures, but we are doing it in a way where we minimize how much we have to involve our customers and other team members. Things like "backwards compatible configuration" and "don't change the UI if it works" are headline in our greenfield.

anoncow 3y ago
> If we were to rewrite this thing from zero with reckless abandon… Your response made me think about this - https://randsinrepose.com/archives/stables-and-volatiles/ https://randsinrepose.com/archives/stables-and-volatiles/

JoeAltmaier 3y ago

I've worked with a business partner for 20 years. I prototype rapidly; he perfects and makes a sparkling gem of a product. Everybody we know, knows this, hires us because of this. We've hired others in the past for special skills - building data schemas, graphic designers, problem solvers, debugging and testing. Because there are many skill sets. I understand the OP very well. We'd all do better by understanding this!

beebeepka 3y ago

Greenfield projects are the best. Second best part is scaling them up or down, changing, improving. It's like having a kid except I don't get even mildly attached to the code itself. I guess I like the responsibility and dislike conformity.

incrudible 3y ago

You should be uncomfortable. If you are comfortable, you are not growing, as a developer and as a person. Odds are, life is gonna throw some heavy curveballs at you. Build resilience while you are still on tutorial island.

CM30 3y ago

Yeah, I feel like this as well, at least to a degree. With a new blank project, you have to design, structure and setup everything from scratch, which can feel extremely overwhelming. It's one of the reasons I haven't finished an entire game, or CMS, or other such project on my own despite being a programmer for decades. I end up stuck in the weeds of how to structure the feeling, and go down a bunch of random computer science and best practices rabbit holes in the process. But hey, I guess it's a spectrum that all programmers fall somewhere on. You might be good at starting things from scratch, you might be good at polishing up and improving existing projects, or you might be somewhere in between.

desireco42 3y ago

I am complete opposite. Not that I mind messy pages or projects, I love to refactor and clean up. Just new projects always give you a chance to do really well and clean.

vrglvrglvrgl 3y ago

[dead]

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.
3y ago

wpietri 3y ago

Honestly, I think this kind of discomfort with a blank page is an excellent thing to have on the team with a greenfield project. One of the ways greenfields go wrong is confident people bringing too much to them. They're sure that features X, Y, and Z are vital. They're sure that the best technical approach means architecture A with framework B and library C. So they jump in and build things, ignoring the lack of product-market fit and the broken feedback loop with users. The people really being served are not the eventual customers, but the team itself. But being uncomfortable with the wide-open sweep of a greenfield project can be put to use to keep the building constrained to what we really know. For a startup I did a while back, we spent the first few months only building disposable prototypes. We wrote only garbage code, and then we put it in the garbage. It wasn't until user testing showed promise that we wrote the first lines of production code. Even then we were very cautious about our technological commitments, because we knew how much we still had to learn about our market and their needs.

Brian_K_White 3y ago
This. I was thinking that they had the right idea themselves when they talked about basic research. In basic research, there really is no such thing as failed or wasted work unless you constructed a faulty experiment. Whatever happens, it's all added to human knowledge. Finding out that something is not possible, or not possible this particular way, is still finding out something. If you're thinking that way, then you never worry about wasting work. You're plugging away at a methodical process and none of it is a waste. But you have to be thinking that the job is to perform these steps and record the result, not the job is to discover a miracle. Getting back to software, as for the blank page, just how blank is blank? Are we talking don't even know what industry we want service or what? Because if the page is blank, there are many tools and methods, but they are not all the same. So the first job is not necessarily to vomit any code but to characterize the job and narrow the tool selection to those which optimize whatever you're going to need to do the most. Maybe you have to vomit some code to figure that out, but then that was the job of that code was to find something out, not to be a product.
jahewson 3y ago
100% agree. I’ve found that one way to make sure that disposable prototypes are disposed of is to build them someplace like CodeSandbox, where nobody can mistake them for the real thing.

protojacked 3y ago

i don’t like greenfield projects cuz they’re hard

mkl95 3y ago

My pet peeve with so-called greenfield projects is that actual greenfield projects are extremely rare. As soon as your shiny new service has to interact with other services, you will run into their stakeholders expectations, and your project will inevitably build up tech debt until you go full circle. You may blame essential complexity, but often it's just the unstable nature of the industry.

phkahler 3y ago

I appreciate the authors position, but I like Greenfield projects. It's best to have a goal, but the blank page offers an opportunity to search for an optimal or satisfying solution. The author mentions having early work thrown away, but that's part of the search. Of course this needs some freedom to fail and change course, so environment matters. Easier to do on personal projects than under a deadline.

neilv 3y ago

> Maybe that’s why I like debugging so much. I hate debugging. Two big programming barriers I noticed as a kid were: (1) walls of complexity, and (2) debugging interruptions that took lots of time and ruined momentum. I learned how and when to avert both barriers. And I love greenfield, partly because I can apply what I've learned about both. (And partly because I like working creatively, and with a holistic understanding of the problem domain and approach.) It's great that there are people who dislike greenfield and love well-defined debugging tasks. I can trade them my brussels sprouts, for their chocolate cake.

moonshinefe 3y ago

I had the opposite experience. I worked at companies in the past that had legacy codebases that were strung together by inexperienced programmers years ago. This meant: - The code was basically just spaghetti with differing standards and architectures depending what area you were in. Making even the most simple changes or basic features would often break something else in unexpected ways. - There were never any tests, and in one company's case, they even had a no comments policy "because the code changed often and they didn't want to maintain the comments' accuracy". - Said companies did not have the money (or want to spend it) in rewriting any significant portion of the apps, despite them being on years ago abandoned frameworks. - In one case, this meant we had to patch a web framework and maintain it ourselves because of security vulnerabilities. I realize maybe the author worked on established but not-so-bad projects, but working on a greenfield is imo the far better experience. You can actually push for standards, create impactful features in a timely manner, and do refactors without fear that 20 other things are going to break because the architecture is fresh in your mind, documented and you have up-to-date regression tests. The author also seems to primarily be afraid they'll do something sub-optimally and have to delete code. I actually love deleting code. Some of the most satisfying refactors I've done involve cutting down on complexity and removing portions of code. I get that you don't want to waste effort, but I don't think it's a healthy attitude to have toward your code if you get negative emotions over finding better solutions.

Kamq 3y ago
> Making even the most simple changes or basic features would often break something else in unexpected ways. As I get older I find myself valuing locality of behavior over most other concerns. I can deal with some pretty spaghetti-ish code that's bad along many traditional metrics as long as I know what my changes are going to impact.
- moonshinefe 3y ago
  > As I get older I find myself valuing locality of behavior over most other concerns. I absolutely agree, that's a big one for me as well and when I'm designing new features it's always a high priority.

ChrisMarshallNY 3y ago

I dunno. I've been doing greenfield projects for almost my entire career. I'm fairly good at going into an existing codebase, and fixing/improving, but I prefer to do my own architecture. To each, their own, I guess.

robertlagrant 3y ago

This is one of the reasons why I like the agile approach. Make anything that barely runs, and start changing it.

Scubabear68 3y ago

It depends on your personality. Some people are “serial starters”. They have enormous creative fire, feel a burning need to create something new, and once it starts taking form and people start using it, they get bored and move on. Others are better finishers. They will patiently build out the core until all the required bells and whistles and niceties are there. It’s very rare to someone good at both, such as Linus Torvalds. Maybe that is a third category, someone who starts a few great things and sticks with them for life?

mdgrech23 3y ago
I feel like these people make for terrible for coworkers. You'll build out a nice class or something that is being widely used and providing tons of value only to discover for a new key component they didn't use your class, built their own to no real advantage. It's obnoxious. Another example. I did a proof of concept, demoed it to the big bosses. Got approval for it to be built. I'm not so much at the individual contributor level anymore though. Anyhow come to find the dev team didn't build off of what I started. Built from scratch and spent the first month reimplementing what I had already built. So dumb. Why do we keep doing this in our industry.
- DJBunnies 3y ago
  Did you ask why

angarg12 3y ago

> There are too many options. Too many tools to chose and decisions to be made. All of the code has to be written, including the boilerplate and the boring stuff. I disagree a bit here. Sure, there are hundreds (thousands?) of databases out there. However, once you add your business requirements, and second+ order considerations (e.g. is this database battle tested in production? is it supported? is it supported in our company specifically?) the choices narrow down dramatically. In fact I dare say that in most greenfield projects you can probably narrow most tech choices to less than a handful.

yieldcrv 3y ago

analysis paralysis is a newb issue

waynesonfire 3y ago

> I wouldn’t say I hate the blank page, but I also don’t like it. In fact, I try to get rid of it as fast and as soon as I can. What a weird impulse. Getting rid of a blank page ASAP!! I stopped reading here. Author prefers looking at a page of ads.

bombcar 3y ago

Every pile of spaghetti crap started out as a greenfield project at some point - so the question is why they all end up spaghetti crap piles?

mcv 3y ago

> I really, really don’t like greenfield projects. There are too many options. Too many tools to chose and decisions to be made. All of the code has to be written, including the boilerplate and the boring stuff. Thanks but no thanks. Give me a messy project instead. You know you can make your greenfield project messy, right? Over the past few years, I discovered I really enjoy projects that are uncertain, where nobody knows yet how it's all supposed to work and what the end result is going to look like. Projects where you try stuff only to throw it away. I've done projects like that, and they were my favourite projects ever. I love to experiment, crank our a quick proof of concept, only to rewrite it in a different framework and refactor it several times over the first year.

sublinear 3y ago

> I’d rather have a messy bit of code that has a bug in it than an empty file. There's at least a third scenario that busts this dichotomy and also isn't the overconfident junior dev nonsense in some of the other comments. I've seen enough of those messy bugs and worked on similar enough projects that are far better put together. I just want to replicate their success. I'll be shamelessly stealing ideas under the guise of "best practices" and I won't worry about the outcome because I already know. The code from me will be easy to read and well documented and nobody will notice apart from the suspicious lack of drama, as it should be.

heavyset_go 3y ago

> I really, really don’t like greenfield projects. There are too many options. Too many tools to chose and decisions to be made. All of the code has to be written, including the boilerplate and the boring stuff. Thanks but no thanks. Give me a messy project instead. I have a hard time relating. Some of my favorite gigs were where I got to come in and design projects from the ground up. It's where you get to exercise an engineering mindset, where you're adhering to constraints while trying to meet requirements and setting the groundwork for potentially years of contribution, change and adaption.

intelVISA 3y ago
Greenfield projects are the Elysian fields for makers. It definitely seperates the builders from the importers. No shade on the latter, a job's a job to most.
- marssaxman 3y ago
  This particular maker-builder loves clean-up work. Yes, it's great when you have a free hand to design something beautiful and new, but it can be even more satisfying to begin with a mess, dig through the crud, find the heart of the machine, and polish it to a gleam. If you start with a perfectly clear vision, it is easy to feel disappointed by the rough edges and unpleasant quirks which inevitably creep into the finished product - but when you start with something ugly, which your work then uplifts, the result might be more than you hoped for.
emodendroket 3y ago
Well, you’re still doing that in an existing project. You’re just dealing with constraints that are in the current context frustrating or nonsensical.

olvy0 3y ago

I'm the same, as I keep telling to my coworkers and internal customers. Just give me a long list of bugs to fix and I'll be happy. But given a completely new project I get into analysis paralysis for several hours/days, researching alternatives etc. I am much better at adding new features to existing code. The constraints are much better defined. I also always strive for perfect backwards compatibility if possible, which is both great for the users (since they have to do nothing, upgrading just works) and also great for me, since it's another set of interesting and challenging constraints to work against. I got slightly better in getting out of analysis paralysis by doing Advent of Code in real time. This forced me to start writing code, fast. I think the effect has worn off by now though.

acuozzo 3y ago

The beginning part is the work I truly enjoy doing. Is there a specific name for it? I enjoy designing architecture and protocols, especially when doing so requires me to get down to the bits and even more when doing so requires me to work under tight constraints.