We're surrounded by people telling us that software design comes from requirements, and that code comes from design. However in the real world, particularly in hobby coding, it's very common for software to grow "organically" from the particular itches one or two people choose to scratch.

The result of this is that software, particularly at the surface, is almost entirely there to satisfy its contributors. Fortunately for the majority of us that means that early users of the software get to shape it which might mean that it meets our needs too. The better software is written by people who actually spend time working out what their users need and writing for that, rather than for themselves.

This issue can go beneath the surface too. It's very common to find that internal APIs in software projects exist only to satisfy the author and thus the code being written. It's rare to find a more complete API than the author themselves needs, unless the author is designing an API for others to use (and frankly even then it can be patchy). This is so common that even when you're aware that it happens you can fall into the trap yourself.

For this week, I'd like you to go back to some of your software which you have released (or if you haven't released any, some software you might one day want to release) and look at its functionality. Consider if there might be gaps which users would like to be filled, and look at making the codebase coherent inside and out. Then file some bugs, make some kanban cards, or whatever you need to let yourself know what you need to do. If you're feeling energetic then make the changes too.