Be Scrappy, Not Crappy

It’s not so long ago that I learned the term “scrappy”. Someone was looking to build a “scrappy” team of software engineers to build the next big thing, and build it fast.

Not being an English native speaker, I had to look up the word “scrappy” and was confronted with two definitions:

  1. “consisting of disorganized, untidy, or incomplete parts.”
  2. “determined, argumentative, or pugnacious”

Why would anyone want to be part of a scrappy team? I don’t enjoy working in a disorganized team and even less in a team with argumentative people. Do you?

False Scrappiness

The intended definition of “scrappy”, of course, was to describe the spirit of iterating quickly and only doing the necessary to get to product-market fit and make the product successful.

And those are good and valid agile principles to build upon.

I feel, however, that terms like “scrappy”, “iterating quickly”, or even “agile” are more often than not an excuse for writing crappy code.

In reality, it often means that the team skips engineering best practices to get ahead faster:

  • we don’t write abstractions because it costs time.
  • we don’t write tests because the code evolves so fast that it’s not worth the time.
  • we drop junior developers into the cold water to develop important code without enough guidance, because it’s going to be rewritten by “real developers” later, anyway.

It’s all about saving time. And it’s all false assumptions.

With a small investment of time now, we can avoid an enormous investment of time later, be it to clean up the mess we made or to live with the mess (which usually costs more time than cleaning it up).

Here are a couple of things you can do to avoid false scrappiness.

Start Clean

When starting a new project or codebase, start clean. Set the expectations toward the new codebase. Establish the rules of engagement with the codebase. Write about the decisions you made.

Let everyone know that this code is worth caring about because that means that working on the code will be faster and less error-prone (your managers will love that argument).

Manage the Architecture

Before starting to code, think about the architecture. It doesn’t matter if it’s a small codebase. Every codebase has some structure. The question is whether this structure is hidden in heaps of code without abstractions or visible in plain sight to help the next developer working on the next feature.

What components will the codebase have? How do they communicate? A simple boxes-and-arrows diagram goes a long way.

Once the code has been written, write tests that assert that the dependencies between those components go in the right direction (you can get some inspiration from this article about clean boundaries). Avoiding unwanted dependencies is like vaccinating your codebase against sprawl.

Pair Up

Pair up with different developers to spread the vision of the codebase. Documenting architecture is one thing. But sitting next to someone with a vision while coding is quite a bit more impactful.

Pairing up will avoid long code review cycles and establish a common understanding of the codebase at the same time. Especially junior developers benefit from pairing, of course, but even experienced developers will learn a thing or two.

In any case, after a few pairing sessions, the team will have a shared vision and can communicate better because of their common understanding.

Be Proactive

Friends don’t let friends write crappy code.

If you see something that’s not to your standard, show how it can be done better. Don’t be pedantic about it, however. Don’t block people’s code because of minor style issues. Do block people’s code because of major architecture issues.

In any case, speak up if something doesn’t feel right.

Don’t Wait for Later

We can prevent a big investment of time to clean up messy code LATER by investing just a little time NOW. Sadly, it seems like we humans are blind to the future, as is evident in the way we handle climate change and even the current epidemic.

Be scrappy, but responsibly so.

Recent Posts

Getting Started with AWS CDK

Getting Started with AWS CDK

Infrastructure as Code (IaC) is the managing and provisioning of infrastructure through code instead of through a manual process. AWS provides native support for IaC through the CloudFormation service.

Read more

Complete Guide to the Immutables Java Library

Immutability means that an object’s state is constant after the initialization. It cannot change afterward. When we pass an object into a method, we pass the reference to that object.

Read more

Common Operations on Java Collections

Collections are containers to group multiple items in a single unit. For example, a collection can represent a stack of books, products of a category, a queue of text messages, etc.

Read more