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

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.

> 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.

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.

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.

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.