A few years ago, Kevlin Henney spoke on the topic of The Programmer at Devoxx UK. In his talk, he mentioned an article by Jack Reeves, What Is Software Design? It’s a long piece, written in 1992, musing on design, building and the job of the programmer. In the article, the author wrote something very striking.
This lesson is that programming is not about building software; programming is about designing software.
After reviewing the software development life cycle as I understood it, I concluded that the only software documentation that actually seems to satisfy the criteria of an engineering design is the source code listings.
If source code is a software design, then actually building software is done by compilers and linkers.
We often use the word “build” to refer to the act of creating software, but that word demotes us to people following a set of instructions. We write the instructions.
The dangers of micro-management in software development are real, because we allow ourselves to be seen as doing a job that will progress faster with more control. The opposite is usually true. While I don’t want to suggest that there should be no boundaries—I think boundaries and constraints drive creativity far more than the lack of them—those boundaries should be an artifact of the problem we’re trying to solve, not an artificial imposition by a misguided senior.
It’s my dream that one day in the future, all work will be creative work, simply because non-creative work will be automated. The automation, itself, is creative. I hope that in the future, any human being will be able to pursue a creative effort simply because they desire it, without financial worry driving them towards something mechanical, or worse, towards starvation as jobs become sparser in a more automated world.
Building is the job of the compiler. A machine. Humans create.