Processlessness

In the eight years I’ve spent caring for DoneDone, there have been very few dedicated hands on the product. Occasionally, we formalized some processes around the product, but usually those processes sputtered after some time. DoneDone, instead, matured in spurts. When consulting work got busier, product development often took a back seat. It’s both the unfortunate constraint and fortunate freedom of using your own time and resources to build a product.

For the past five years, only two primary developers have worked on the product — Jeremy Kratz and myself. Jeremy takes wonderful care of all the front-end development and I tend to the back-end services and data stores.

It’s a pleasure working with a small development team (and you can’t get much smaller than two). Assuming you have a good rapport and enjoy working with your team members (which I certainly do), you find yourself spending the vast majority of your time thinking about the product. Improving your code. Tweaking the UI. Simplifying the UX. Almost every minute of DoneDone thinking time goes toward the product.

I contrast this with what often happens when teams are larger, or when team members are more unfamiliar with each other. This would be the case with most development teams; particularly in Silicon Valley, where I once read that the average developer stint is something like nine months.

When development teams are constantly changing, you need a lot of process. You need a really clear, rigid structure so that the developer can be as interchangeable as possible — by design. It is the programming equivalent of an interface-heavy design. The injection of a concrete class becomes a lot easier when there’s less coupling between real classes. The interaction happens between interfaces. The drawback to this kind of design is there’s just a lot more stuff around the actual implementation.

In much the same way, process-heavy organizations mandate a lot more structure to manage outside of the product itself. Sometimes, that amount gets so overbearing that it affects developer morale. Even worse, developers end up spending more time on maintaining the processes around the code than on writing the code itself.

With just a couple of developers who’ve worked together for a long period of time, you’re able to shed almost all of that process. Now, that doesn’t mean we write code recklessly and push things live at our own volition. We still have formalities around committing code, reviewing each other’s code, and deploying to production. It’s just that the formality is so dead simple. It’s barely a process at all.

I’m a big believer that developers need time and space — some freedom to code, design, and think without all the trappings of process — to do their best work. We’ve taken that luxury with DoneDone. Perhaps, it’s been at the cost of some speed, but it’s helped produce a quality product with just a couple of people building things at a reasonable pace.