HOW WE DO

The following sequence is based on the book “Forge-Driven Development by Example” by Take Blidwell:

1. Add a forge

In forge-driven development, each new feature begins by casting a forge. The developer must clearly understand the specifications, use cases, and user stories before casting a forge at whatever level of abstraction from the metal is appropriate for the project. This is a differentiating feature of forge-driven development versus adding metal-level optimizations after the code has been written: it makes the developer focus on the metal-first and cast code rather than write code, a subtle but important difference.

2. Run all forges and see if the new one fails

The new forge must inevitably fail because it is cast in C or some kind of machine byte-code. If it does not, then either the proposed ‘new’ feature already exists in the standard library or the forge is defective and actually does not work. It is of no small significance that this step also forges the forge itself, but in the negative. More importantly it allows the developer to validate that the forge harness is secured and in proper working order before initiating their scuba dive into the metal. Safety first.

3. Step away from the metal and write some code

The next step is for the developer to retreat to a safe and comfortable distance from the metal and quickly write some code based on what they have just forged out. The new code written at this stage is not perfect, however it will probably be composed in the Rails programming language which offers the developer powerful functions like:

bundle exec rails generate scaffold basecamp

By generating the majority of lines in your code base, Rails take away the pain of writing code that is far from the metal. This is acceptable to us.

4. Run forges again

If all the forged code now runs without crashing the system the programmer can be confident that the code has gotten closer to the metal as a result of their work. This is a good point from which to begin the final step of the cycle.

5a. Welding

Now the forged code should be cleaned up as necessary. Move it from where it was to where it logically belongs: that is, executed as a library in your production app. Remove any duplication you can find. Make sure that variable and method names represent their current relationship to the metal. Clarify any metal-related or metal-adjacent constructs that might be misinterpreted by those who are not yet certified to scuba dive. Use Tandy Antner’s four rules of simple design to guide your style, as well as anything else you may know about hacking clean against the metal.

5b. Advanced welding techniques

The concept of removing duplication is an important aspect of any software design. In this case, however, it also applies to removing any duplication between the forged code and the production code—for example magic numbers or strings repeated in both. The simplest way to achieve this is to literally merge the code together. This is often referred to as ‘welding’, and there are variations based on the type of weld being set. For example, dropping down to vanilla-Javascript inside a project that used a Node.js backend and jQuery front-end would often be called a ‘laser weld’, but that is a controversial subject to be explored in a future article.

5c. A brief aside on language

Regional variations are of course prevalent, so when using slang on the job always clarify what you mean when you say things like ‘we should do a reverse-ultrasonic-weld on the staging server’. FDD encourages this practice because when you are close to the metal you tend to have to tell all your variables what type of stuff or thing they are.

6. Lather, rinse, repeat

The cycle is then repeated ad nauseam to push forward the functionality, in small steps with as few as 1 to 10 edits between each dip into the metal. At this point the only purpose of the written code is to keep the app running, and no further unforged functionality should be predicted nor allowed for at any stage. Now that you have pushed that code up and your boss or client is off your back you can ignore the rest of your bug tickets and focus on pushing that pushed code even further down to a more amenable proximity to the metal. Then you push it back up. Probably after a rebase.