My approach to experimental solo projects

As I wrote before, my current goal is to start specializing and that I want to focus on ASP.NET Core with Blazor frontend. To make the first step on this journey I started an experimental project – Wordrate. I thought I will use this occasion to reflect on my approach to running such projects and see if there is some wisdom to be gleaned from it.

It’s a lot easier than at work

There are many aspects of software development practice that have a big impact on the results of our efforts. They can be grouped into three categories:
– people interactions (e.g. communication, organization or collaboration)
– operations (e.g. versioning, deployment procedure or monitoring)
– construction (e.g. requirements, planning or technical design)

Modern methodologies like DevOps and various incarnations of Agile suggest approaches and practices aiming to help out in all those activities. It is a lot to tackle and it’s all important because big commercial projects are hard. Hobby projects are much easier and much more fun, which partly comes from the fact that we can focus on construction, simple operations, and we can pretty much forget about people interactions.

Incremental and evolutionary iterations

My philosophy on construction activities is based on two simple, but important observations about the reality of building software systems.

First one is that big designs up front essentially result in making a large number of unproven assumptions. Assumptions on our understanding of the domain; on the potential of creative vision; on stakeholder needs and finally on the fitness of planned technical solutions. Many of those assumptions will be wrong. Skill and experience can only reduce the rate of making mistakes but with scale, those mistakes will happen. Many will be easy to amend. Some will have major consequences.

The second observation is about the software’s potential to grow and evolve.

Software was invented to be “soft.” It was intended to be a way to easily change the behavior of machines. […] To fulfill its purpose, software must be soft—that is, it must be easy to change.

Robert C. Martin, Clean Architecture

Thanks to this potential, we don’t really need to build big systems at all. We can build small increments firmly standing on the ground of what is already working. Eventually, arriving at the scale of the solution we have envisioned.

Focus on extensibility and evolvability first

Granted, with size, software tends to get more rigid. And retaining this “softness” in places where it matters most (and identifying those places) is difficult and requires conscious consideration. Agility often comes at a price of something else like scalability or performance and such tradeoffs can get difficult on real projects with many kinds of stakeholders.

However, on experimental hobby projects, where we are usually tackling either very fuzzy or not-at-all-existent problems, the only thing you really need to care about is extensibility and evolvability. At least until the system reaches some level of maturity and other needs become clear.

Building vertical cuts

The common wisdom of modern programming practice is to ship new versions as often as possible. One consequence of that is our need for continuous delivery (which is a separate topic and has no place in this post). The other consequence, more philosophical in nature (fitting right-in in this post) is that we should prioritize incrementing in vertical cuts, rather then in layers.

Building an individual vertical cut of the system can then be treated as a small process on its own with phases like domain analysis, design and implementation, and delivery.

An optional extra phase I would like to do more often is the reflection. To take a step back and reevaluate the state of a system so far. Do I have enough automation? Do some parts get unwieldy and need refactoring? Should I adjust the general direction of the project? I think allowing ourselves to take such pauses helps us guide the evolution of the system in the right direction and pays off in the long run.

It can also be a good moment to think and decide if we want to invest more time in the project at all.

Software is never complete – it is only shipped

I like the word ‘system’, which Google dictionary defines as a set of things working together as parts of a mechanism or an interconnecting network. It reminds me that we can add and remove parts of software freely and we should not feel obliged to finally declare it finished. Or closed. We only need to ship it when it is at a state of being ship-worthy.

Where I’m going with it is to say that when running hobby projects it is best to ship early and ship often. Every time you release a version for others to see, you have potentially brought some value to the world.

After that the decision to either continue or abandon the project feels much lighter.

Leave a Reply

Your email address will not be published. Required fields are marked *