The birth of an idea

I am laying on the beach, thinking about the necessities to promote my band so that we hopefully find some venues that host one of our shows when I suddenly have an idea. Why not write a simple, small web-application and document the process: from idea to deployment, explaining choices and design decisions and software stack in use and whatnot. I could both showcase my skills and knowledge as well as build a tool which will come in handy for my band…!?

So, this is it. I will try to provide the curious reader with all the necessary information from idea to delivery, from software design through stack choices to continuous integration and delivery. I will focus on characteristics that I feel are currently understated and vastly ignored in software development and will explain why giving them more attention will eventually save time, stress and money and improve a product for good.

I will go through the whole project in (roughly, I have not done it just yet, for this is kind of a live journal) the following steps:

• outline the idea and define the scope,
• design the software architecture,
• write the code,
• deploy the code and
• finalize this documentation.

Since I find beauty in the efficiency of minimalist solutions and I fail to see measurable advantages in stacking software on top of software just to present some text over the world-wide web I will compose my blog posts in my editor of choice in org-mode, which allows me to render HTML out-of-the-box. Please excuse the lack of fanciness and enjoy the speed with which these pages load.

Some of the characteristics I will focus on are:

• efficiency,
• maintainability,
• verifiability,
• reproducibility and
• supply chain management.

I think it is necessary to explain some of these, or at least put them in context. Efficiency is a bloated term, and - somewhat like optimized - can mean anything. I put this term first, because unlike the others, it does not mean much by itself - but I will bear it in mind while establishing the others. In this context it means not to waste hours optimizing any of the other aspects without getting some real gain¹ from it.

Maintainability and verifiability somewhat sing from the same hymn sheet: they are as much about readability of the code as documenting intentions and design decisions. A future reader/user/hacker must be able to figure out why a function is written in a particular way - without having to break it first and only days later find out what other parts of the project broke with it. This of course implies previously uninvolved parties to find their way to solving problems or enhancing the software within a reasonable time frame.

Reproducibility is a topic I crossed some years ago. I am still as surprised as I was back then that the very idea has not really gained traction, even less (industrial) adaption of the (relatively simple) tools to use and work flows to adapt - for a gain that is otherwise simply unachievable. But I will explain when we get to that topic.

And while we're at it, I will talk about another favorite topic of mine: supply-chain management. It is the reason I try to stay as far away from node and other "package management" convenience software as possible. In short: whenever we make use "foreign" (not written by ourselves or our team) code, we better know about it, have an idea what problems it might inflict on our product and feel reasonably comfortable to either exchange it with a better fitting (as in: more secure) solution or be confident to fix future problems within them ourselves. Supply-chain attacks have, due to the now almost ubiquitous culture of "build fast, fix never" in software development, become a relatively easy and drastic attack vector of our time.