Chapter 8: Bootstrap a Greenfield System

Working on a brand new application can be a lot of fun. There’s no “baggage” from legacy code, no technical debt, and there’s a wonderful feeling of freshness when starting an app from scratch.

(p. 101)

The decisions you make […] can have a lasting impact

(p. 101)

8.1 Overview

When given a greenfield project […] you have two main goals:

• Make sure everyone involved in the project feels good about the initial direction and decisions being made
• Establish a location for developers to start contributing code

(p. 102)

Mention of the iteration Zero, that

[…] indicates that no direct business value is going to be delivered initially

(p. 102)

8.2 Understand the problem

You do your company a disservice to build an application you don’t think needs to exist.

To understand why the application should be built, find answers to these questions:

• What business problems will this application solve?
• Why is the proposed application the best solutiont o those problems?
• What other solutions were considered?

(p. 104)

Mentioning the importance of asking why about these problems, also, whether this decided solution is good / the best.

8.3 Understand the System’s Place in the Technical Architecture

Mention of the ‘technical architecture’:

existing applications and existing infrastructure

(p. 105)

8.4 Choose Technology

Using the Blessed Stack

Be prepared to heavily defend your position if you decide to not use the blessed stack, both to yourself and others. (paraphrased from p. 107)

Using a Different Technology

You must answer the question “Why shouldn’t I use the blessed stack?”

[…]

[…] your first duty is to deliver results.

(p. 108).

Also consider these factors:

• Fitness for purpose
• Performance
• Developer productivity
• Developer happiness - also called developer experience (DX)

(from p. 108)

8.5 Outline the Application’s Architecture

You want your application to ooze consistency

(p. 111)

you want to establish a “culture of consistency”

(p. 113)

Each developer should be encouraged to establish a convention when they first face the need to have one.

(p. 113)

[…] considering the political impact […] Since it often doesn’t matter what the decision is, making an unpopular decision can be little gain for a lot of trouble.

(p. 114)

8.7 Create a Minimum Deployable System

I like to think of deployment as the physical act of getting the code up in the production environment and launching as the act of allowing users access.

(p. 118)

The difference between deploying and launching. This can be enforced with some techniques to block/allow access, such as enabling/disabling these features or controlling access to said features.