The birth of an idea

I am 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 have an idea. Let's write a simple, small web-application and document the process: from idea to deployment, explaining choices and design decisions and software stacks in use and whatnot.

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?) delivery. I fill 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 the 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:

1. outline the idea and define the scope,
2. design the software architecture,
3. write the code,
4. deploy the code and
5. finalize the documentation.

Since I find beauty in the efficiency of minimalist solutions and I do not see major 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. These files I will upload to the server which you are probably reading this text on right now.

Some of the character traits I will focus on are (but are not limited to):

• 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 (with each other). Efficiency is a big term, and - somewhat like optimized - can mean pretty much anything. I put this term first, because unlike the others, it does not mean much all by itself - but still I want to bear it in mind. In this context it means not to waste unnecessarily many hours optimizing any of the other aspects without getting some real gain (yet another set phrase) from it.

Maintainability and verifiability somewhat sing from the same hymn sheet: they are as much about readability of the code as documenting intents 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. Also it should be obvious that this 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 and 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) work flows one needed to adapt.

And while we're at it, I will talk about another topic that has come to my attention and is a personal favorite of mine (with the same emotions and reasons as the previous one): supply-chain management. It is the reason I try to stay as far away from node and other "package management" convenience software as possible: whenever we use "foreign" (not written by ourselves or our team) code, we need to know about it, have an idea what problems they might inflict on our product and feel reasonably comfortable to either exchange them with better fitting (think: more secure) solutions or fix problems within them. Supply-chain attacks have, due to the history of "build fast, fix never" culture in software development, become the easiest and most drastic in our time.