You might think, declaring that programming is still a stone-age craft is a little bit exaggerating, no? After all, it’s a high-tech job. Ok, I might be exaggerating, but certainly not by much. We might call our work by respectable names, such as software engineering, system design, software architecture, etc, but at the end, it is still, at best, craftsmanship. This is, by no means, belittling craftsmanship. After all, good craftsman, as we programmers all are, take pride in our works. As much as we do, it does not make it less stone-age-ish.
Let’s look at the tools we use everyday in our trade, e.g. the design tools, documentation tools, development tools, verification tools, testing tools, monitoring tools, etc. How many tools do you actually use? And how many of these, can you claim, allow you to easily translate your requirements into a solution, and then into a working program, and allowing you to perform scientifically sound verification to ensure the program’s quality and correctness? We use a lot of tools, but there is a disconnect between our mind and the tools, and a disconnect between the tools used at different stages. There’s no easy way to translate our thought model into a solution, and no reliable way to map the solution into a working program. And certainly no easy way to prove the program is correct.
Now, let’s also look at our daily works, e.g. specify requirements, translate requirements into solution, map solution model into computer codes, verify that codes are correct, run after bugs, etc. How many of these tasks, can you claim, are not trifles? Admittedly, some of these tasks do involve intelligence and creativity, but most don’t. They are tedious, repetitive, mind numbing.
We can claim that this is exactly the beauty of programming. You can do anything on computer, you have freedom and full control. But in reality, most programming works are menial jobs. They hide behind fancy names such as web services, enterprise architecture, micro service, etc, but most of them are simply CRUD functions, with very similar parameters. Obviously, programming tools have progressed, and re-usable software modules have significantly made system integration a lot easier than, say, 20 years ago when I first got into this trade. It would probably take ten programmers 20 years ago to do the same work that could be done by one person today, as we do not have to create everything anymore. The value is in putting different modules together to create a larger solution. However, the way we work hasn’t change much, we still need teams of programmers, banging on keyboard to repeat thousands and thousands of lines of similar codes, and then even lines of codes for unit testing, integration testing, performance testing, etc, etc. No wonder to call ourselves code monkeys in self-mockery. It’s like coolies digging tunnels with pickaxe under a mountain, wondering when we are going to see the light at the end.
If you consider yourself lucky to work on some high-performance, multi-core and parallel programs, the tools are even more rudimentary. Talk to someone who has his feet deep in the multithreaded and parallel codes and you’ll understand. Sure, no-lock concurrency, immutable variables or functions etc, do help in keeping the sanity, but it’s still a crazy world.
And if you have the chance to work on some fancy algorithm, you’d probably claim this is creativity in work. Let’s say you have designed an extremely cool algorithm to solve some pernicious problems. And you have mathematically proved it to be correct. Now, try to convert that into a working computer program. And try to prove that your computer program is as correct as your mathematical algorithm. Yes, you can use fancy programming language, you have type theory and dependency, you run static analysis, you capture programmer’s intentions, you do code review, you use theorem prover, you create DSL (domain-specific language) to abstract away all the nitty-gritty details, you write tons of codes to test corner cases, etc. At the end, can you still be sure that the program is correct? But how do you prove that the tools and frameworks you used to prove the correctness of the program, are themselves correct?
This post is not about complaining, it’s just a personal reflection on the status of our job and our daily chores. We need better tools.