Software design in my side projects

This article is part of the "Side Projects" mini-series I started quite some time ago.

I am not sure if it was a good idea to include this topic in my original list because I don't do much formal software design when working on a fun project. Again, I do things completely different when working for a client, where I am part of a team and everybody has to understand the design. But in this case there's only me. When designing some part of the system I usually do the following:

• Think about the problem and possible solutions, try to simplify the problem
• Maybe write a small throwaway prototype (this is optional, normally I won't do this
• Code the most streight-forward solution I can think about

In the end the only artifacts produced are the production code, and maybe - if it is a complicated problem - some automated tests. I don't write much documentation and I do not create UML diagrams or other artifacts. Sometimes some scribbling in my notebook. Sometimes.

The key to make this work is to code the most streight-forward solution I can think about. This means that, when I come back to the code later, I can easily figure out what it does: I just have to remeber the problem and then think of the simplest solution. This gives me a good lead for digging into the code.

Even if the simplest solution was not working when I implemented it first it is still easy to re-trace my steps from there. This works quite well because I am the only person who works on the code. I guess it would be extremely hard - or even impossible - to pull this off in a team with collective code ownership. But meybe it could even work there: When everybody agrees on how the simplest possible solution should look like.

And the advantage of no documentation: The documentation can never be wrong. And I don't waste any time wading through endless pages of (mostly outdated) documentation to find something - A problem that I've seen with some dev team wikis. Also, writing documentation is not fun, and working on a fun project better be fun! If I really fear to forget some important aspect of my code or the architecture I write unit tests instead of documentation. The test at least tells me when it becomes obsolete by not running anymore ("red bar"). Obsolete documentation does not have this feature.