Programming, Fast and Slow

I have experienced two types of development projects. They require an opposite approach to organization and technology selection.

Programming Fast

The first type is a typical product project. The codebase is developed daily, by a team of professional engineers for a foreseeable future, as long as the developing company stays in business.

Under those conditions, it makes sense to organize development as “fixed time, variable size” since the amount of humanpower is roughly consistent.

Maintenance is done continuously and incrementally. You can upgrade to every new version of your infrastructure and dependency once they come out. Those upgrades are small and painless. You don’t have to allocate that much time to them as they are a relatively small proportion of the overall work.

When making technology bets, it makes sense to take a calculated risk. Emerging technologies can give you an edge. New cool tech helps with hiring and retention. In case your bet fails, you have enough force to change gears mid-flight.

It makes sense to use as many fitting libraries as possible. You can keep up with their development and develop alternatives or fork if needed. And if they have aligned motivations, they superpower your progress.

You may need to create user experiences before the underlying technologies are ready. It makes sense to create a complicated technological solution to deliver ahead of the mainstream market as it gives you a business edge.

You move fast and take shortcuts.

Programming Slow

The second type happens with hobby or community projects. But it’s not just that: a lot of projects outside of company’s core business share the same properties. A special mention goes to throwaway one-time tools that end up being a critical infrastructure.

The codebase is developed occasionally. A common pattern is “the 20% time on Friday” or “volunteer sprint for two weeks in a year”.

Work is organized as “fixed scope, flexible time”—and the scope is exploring what “minimum” in MVP is. The rest of the work is put into the backlog.

Maintenance is done in batches and has to catch up with the past week, month, or year. It may eclipse new development completely. Rewrite may be easier than maintenance catch-up.

When making technology bets, it makes sense to be as conservative as possible. You should aim at using standard libraries and browser functionalities. You are not looking for an edge: you are looking for technologies that are not going away.

The fewer dependencies you have, the fewer upgrades are waiting for you.

It makes sense to drop functionality to achieve aggressive simplicity.

You move slowly and steadily.

Fast and Slow

The two approaches are opposite ends of a spectrum. I already hear people arguing “but you should always strive for simplicity and minimal dependencies” and yes yes, but where to draw the line is very context-dependent.

Is React a simple dependency and a stable foundation? The answer is different in 2013 (no), 2016 (probably yes), and 2020 (maybe, aren’t web components enough for you?) and depends on whether you are trying to make a CMS viewer (isn’t server-side render enough?) or an interactive, client-side page builder.

Making an explicit decision on where your project belongs is especially important when taking advice, either from your friend or from “the Internet”. If you are not from the same side of the spectrum, it causes similar issues as copying someone from a different scale.

Thanks to Mark Foster and Honza Javorek for review and comments.

Published in Essays and tagged

All texts written by . I'd love to hear your feedback. If you've liked this, you may want to subscribe for my monthly newsletter, RSS , or Mastodon. You can always return to home page or read about the site and its privacy handling.