Structure Driven Development - On the true nature of what it means to program

Sun Dec 13 20

Nobody even tries to pretend that structuring data into a computer is easy. Conceptually speaking though it's a very simple activity. Just put the bytes in order and you're finished. When you have data in the right order, it can become music, video, Shakespeare's complete works, or money. Even more curiously, when data is in the right order, it can become working software. For what is a program but a set of instructions executed in a known order? What are we doing in the meta sense but creating structured data in order to structure data? To see this we must look at what a solution, a project, a codefile is in terms of data.

A class a related set of actions. A method a listing of instructions. Classes are grouped via a natural namespace hierarchy. They are then specified with the project and related to their dependencies. Finally a compiler reads the specification on demand and produces an encoded binary for quick instruction retrieval at runtime. Code is data and data is code.

Curiously enough, we build programs made of structured data to help us structure data. This is fundamentally what a form is. The form is for end users to put in their names and dates of birth into whatever database they're interested in interacting with. It's ultimately entirely unnecessary though, it's just that other ways of interacting with a database are too inconvenient.

It's just as easy for me - the designer of this presentation layer - to input data into my database by running insert statements into the database. I don't need an input form, but I bothered to make myself one anyway because this is how I prefer to interact with a machine. In fact, I'm somewhat sure that if I applied myself I wouldn't need the database at all, instead designing my own data storage and retrieval system.

In fact that's exactly what I did as the first feature of Using the operating system and relative location of files, I programmed the computer to respond to certain GET requests with a fully formed RSS feed and associated media.

This isn't a particularly hard thing to do with modern computers. In order to tell the computer how to act I was forced to modify many-a text file and install various things to configure the computer properly. Nginx configuration, System-D configuration, .Net Core 1.1 (which is what I was using back then), Roslyn configuration, Ubuntu Linux configuration, SFTP+SSH configuration. On top of this I of course need to do my DevOps properly so I configured Git, Travis and my home windows setup to work with everything.

Essentially configuring all of these things revolves around the same concept and the same set of actions. No matter the technology, no matter the product or the action you want to take it's always the same set of tasks you have to complete. For nginx you have to write a specific set of JSON data to define your webserver and store it in a specific file at a specific location. For Systemd you have to write a specific set of JSON data to define your new service and store that file at a specific location, then run systemctl start myservice.service. To configure your operating system you just run a bunch of commands against it and look through config files. To configure your program you write a bunch of C# (or your favourite language) and run your compiler to get your program. The entire job is to structure data and configure your programs the right way and the software you're trying to build will magically begin to work.

Ultimately you can't be afraid because the computer doesn't work. It doesn't work because it's not configured correctly. And by "configured correctly" I mean that the data is not structured properly. Luckily you've been structuring data from your first interaction with a computer.