A recent article ‘Real’ Programming Is an Elitist Myth hit a couple of points that I have been explaining to people for years. Although the author makes a few interesting points, he misses several more.
The author describes a system written using a “database as a service” system with little to no code, that solves a problem for a group of volunteers. The author goes on to declare that “Real” programmers would sneer at this amateur effort as not being real code. I will note that the author does not actually describe a particular instance of this happening, he just declares that programmers he knows would not be impressed.
The author goes on to describe how this system is particularly useful in its current state and that the data is more important than the code. If he had stopped at this point, the article would have been quite useful.
Well-Understood Problems
If you need a simple solution for a well-understood problem, the kind of tool described in the article is perfect. In fact, the straight-forward database with one or a small number of tables with a few hundred to a few thousand entries is a good model for several simple problems. It’s also relatively easy to build a system that allows someone to basically configure this solution instead of writing it from scratch.
While I might say this is not real programming, that doesn’t mean it’s not useful. There are lots of useful systems that do not require actual programming. If the tools solve your problem without programming, the important part is the solution.
Many years ago, I did a bunch of research on Pseudo-Random Number Generators (PRNGs). I even put together a library that provided a common interface for many of them, that handled everything from non-random algorithms for testing through generators that could be used in cryptographic applications. Someone contacted me to ask which algorithm would be best for randomizing a list of people for a game. While trying to understand the requirements, I found that there would be under 100 names to randomize and they only needed to do it once. I suggested printing the names, cutting them out, and pulling them at random out of a hat.
It’s not real programming, but for this example any code at all was not worth the effort.
Different Kinds of Problems
Different problems require different tools and levels of expertise. Well-understood problems can be solved without actually doing programming. But, there are problems that the simple tools described above will not handle.
I would expect most people would guess that the simple solution described in the article would not scale to millions of records accessed hundreds of thousands of times a day. It also would not be secure enough to deal with people’s personal financial or medical information.
When your problem scales to large amounts of data or information that can effect people’s lives, the problems stop being well-understood and configurable. At that point, you move into the realm of real programming.
Real Programming versus Solving Problems
The elitist comment that is the core of the article seems a bit odd to me. The author seems convinced that it is more important to be able to say they were programming, than to solve the problem. The solution itself is actually useful, why would anyone care if someone would call it real programming?
It should be obvious that this solution is not equivalent to the effort and knowledge that goes into building a system that makes a company like Google or Netflix possible. But, that does not negate the usefulness of the solution in solving your particular problem.
Birth of a Tool
What the post’s author is missing is that the tool exists because the class of problems they are looking at became so familiar that some real programmer put some effort at some point in the past into making sure that no one had to solve this problem from scratch again. At that point, this kind of solution is a bit of a commodity. While that might sound dismissive, it’s not. This kind of problem is so common, and needed by so many people, and so well-understood, that there should not be a need to solve it repeatedly. Just as importantly, someone who has one of these problems shouldn’t have to track down and pay a programmer to solve an understood problem, yet again.
If the class of problems is too broad, too much effort would be needed to configure each instance, and the tool would be worthless. If the class of problems is easy to solve, but no one needs them, there is no reason to make the tool. Because the class of problems can be pretty well specified, and enough people need to solve this kind of problem, someone decided that solving the whole class of problems was worth solving.
By making a tool that solves these kinds of problems without programming, the programmer reduced the effort needed by the person with the problem to something they can solve without a bunch of specialized knowledge. And, the programmers that would have been hired to solve this problem can now go on toward solving other problems that are not so well understood. The non-programmer who had the problem can now focus on their problem without wasting time on details. More importantly, they can solve their own problem.
Conclusion
Different levels of problem require different kinds of solutions. In some cases, programming is required. In other cases, configuring a tool is faster and good enough to solve the problem at hand. If a tool manages to solve the problem you are trying to solve and does not cause more problems than it solves, who cares if it is real programming? But, don’t forget the simple, easy-to-use tool won’t handle every problem. Any more than a bicycle will get you to space.
My main complaint with the article was the focus on what a real programmer might dismiss. Instead the author should have noticed that someone took the time to put their knowledge and skills to use handling the boring parts of a common problem and make it so that others can solve their own problems.