Greenfield, Brownfield... Blackfield?

—Andy Hunt

07/24/2024

So much is written about projects and software assuming a fresh start, a smooth “greenfield” project.

Friends, the field has always been brown.

Sometimes black. Usually chunky. Filled with the wreckage of previous projects, orphaned code and aimless practices that shouldn’t even be there in the first place. Ya know; a mess.

One of the things that we always forget is that software development is a completely human endeavor. The programming languages, the container orchestration, the tech stack—all that is secondary. It’s all about us, as people. And people have both history and future.

A “project” does not stand alone, isolated. It’s not a mythical, unspoiled green field just waiting for your imprimatur. A project is an integral piece woven into the overall sociotechnological fabric.

That means a project isn’t just a “thing” by itself: every project has a before, and every project has an after. Every person on the project also has had a before the project and an after the project.

So not only are we building on the ruins of a previous civilization, but each one of us is bringing our own baggage to the party as well. That “agile practice” that was shoved down our throat at a previous dysfunctional project? Yeah never want to do that again. That awesome “agile practice” that was so successful on the last project when it was just a few of us? Surely we can scale that to this new larger team.

Both views are wrong—it’s all baggage. The only thing you can safely say from a previous project is that a particular approach or tech worked well or didn’t work well on that project. Maybe this project will have a similar experience, or maybe it won’t. You can’t know yet.

This project is different from any other you or anyone else has every worked on. Maybe only slightly so, maybe massively. But always different. Even if you have the same team members, even if it’s a similar task from a previous project, you are different now. You’re older, more experienced. You learned something from previous projects, for better or worse.

One of the key takeaways from the agile movement is the idea of responding quickly to changes, to the point where you can embrace change, not just grit your teeth and get through it. Let’s face it, everything changes all the time. The tech stack shifts under our feet. Market, consumer, and regulatory forces may drive feature changes and huge pivots to your product. Change is omnipresent, and we have to deal with it promptly and effectively in order to succeed.

So here you are, on a new “greenfield” project that ain’t so green after all. How much chunky brownfield have you inherited? Do you really need Kubernates and containers? Would a static site generator and Nginx be enough? Do you really need Redis, Mongo or Couch and a relational DB as well? You could just use Postgres for all of that.

Those stand-up meetings that last several acrimonious hours—does it make sense to continue to do those badly in this environment? What about pull requests, which are great for a large, distributed development team, but which make no sense at all for a stable development team?

How many of the practices you’re team is doing are designed to slow down the work, to introduce chokepoints or single points of failure? Any sort of handoff or gate is highly suspect and maybe, just maybe, not needed at all.

We’re coming into this new project a mess. We’re a mess. The project is already a mess (bonus points if you have over a thousand Jira tickets logged to this project before it even starts). Our teammates are a mess. Our users are a mess. Our sponsors, corporate leadership… we’re lucky if they are only a mess, and not actively subverting our development efforts, preventing us from learning or growing or even being effective.

So what can be done? We don’t get the chance to start with a clean slate, but we can make some changes. Successful modern software development requires at least four things:

Impeccable, reliable, automated build and deployment system
Effective, low-friction collaboration
Constant learning and skills improvement
Focus on designing replaceable, disposable software

You can read about these four in detail in this article, but the key is to get started making improvements in each area, in the order presented.

That is, the first order of business is to get your automated build fast, reliable, and rock solid. No excuses. If your architecture makes that difficult or impossible, change out your architecture.

Next up, improve collaboration on the team and between the team and users, other parts of the organization, etc. If you have team members that are making this difficult, change out those team members.

Software development is, at its core, all about learning and communication.. You need to schedule time, right along with backlog items and other tasks, to learn and grow your skills. If you don’t schedule it, you won’t do it. So you need to change your schedule to add these activities. This is your opportunity to examine the baggage you’ve carried into this project and update it as needed.

Finally, stop trying to predict the future. As a species, we suck at fortune telling. Yet that doesn’t stop up us from trying to predict a project due months or years in the future, or trying to predict what users will want or need, or trying to predict how software might change in the future. Bottom line, we just don’t know. So rather than trying to build software that will adapt to a situation you know nothing about, aim for the worst case and most likely scenario where the software will simply be replaced. Disposable. Serves the conditions we know about today, and if things change radically, we can just swap it out.

Notice that if you are having trouble with any one of these points, the solution requires you to change something. And therein lies our problem: