Skip to main content

The Future of Programming

The problem with abstractions

Programmers are experts in abstract thinking. To program is to generalize: A method is a general specification of different execution paths. A class is a general specification of objects. A superclass is a generalization of several classes.

Although our minds are capable of abstract thinking, concrete thinking is more natural, and concrete examples are the foundation for abstractions. For instance, how do you teach children what a car is? You don't give a definition like: 'A car is a wheeled motor vehicle used for transporting passengers.' Instead, you point at a car and say: 'Look, a car!' After seeing a few cars, the child understands what a car is.

Notice what I just did! I started with a general principle and then gave an example. Which part of the paragraph above is easier to understand, the first sentence (general) or the rest (example)?

Einstein said that examples is not another way to teach, it is the only way to teach. It is easier to start with a few examples and then generalize than the other way around. If you start with an abstract description, you will often try to comprehend it by visualizing an example in your head.

The problem with text

Another point is that children understand better what they see than what they hear. Or as they say, children do what you do, not what you say. This is not only true for children. We understand what we sense in fractions of a second, but words must be analyzed before they give meaning. This doesn't take long for simple sentences, but it can take hours, days or months to understand source code of any significant size. Some source code is actually incomprehensible and nobody dares to touch it.

What does this have to do with programming?

As programmers, we are highly skilled in abstract thinking and textual programming languages, but when the code becomes too complex, we try to comprehend it by imagining its behavior. And when it becomes too hard to imagine the actual execution by reading the abstract code, we log what happens or run the code in a debugger. Logs and debuggers are not abstract. They give concrete descriptions of what is actually happening. They give information on method calls, object instances and variable values. This concrete information is much easier to understand than the abstract code.

We can move programming closer to how the mind works by using examples as part of the implementation. Unit testing is one way to do this, because unit tests are examples of what the code can do. There is also a growing movement for using examples as requirements. This improves the communication between users, analysts, programmers and testers. These examples can be automatically tested to connect them to the code.

Objects are examples of classes

So what is the best way to specify examples? I think that the most effective formats are user interface sketches and objects. The user interface is the best way to explain the external behavior of a program, and objects can be used to describe the internal behavior. I am not talking about technical objects that is part of the infrastructure, but domain objects that the end user understands.

Objects can be specified as text, in tables or in diagrams. Diagrams are easiest to understand, but they can be cumbersome to draw and edit.

Here is an example of an object diagram:
It is pretty obvious what this means.

If Lars sells his car to John, the objects should be changed like this:
Alternatively, the same information can be specified in tables or as text.

Modeling examples as objects is an effective way to build a domain model. This makes the examples consistent with each other and helps to reveal details and missing functionality. They are great as specification for programmers, because they are specific and contain a lot of details. And they can be automatically tested easily.

I believe that using examples and objects is the future of programming because it is closer to how our mind works.


Popular posts from this blog

The Pessimistic Programmer

I decided to change the title of this blog to "The Pessimistic Programmer". Why? Am I a depressed person that thinks nothing will work? No, I am an optimist in life. Something good is going to happen today :-) But in programming, something will surely go wrong.

I don't actually view this as pessimism, but as realism. I want to be prepared for the worst that can possibly happen. Hope for the best, prepare for the worst. But my wife explained to me that pessimists always say that they are just being realistic. So, I might as well face it: I am a pessimist.

I think a good programmer needs to be pessimistic; always thinking about what can go wrong and how to prevent it. I don't say that I am a good programmer myself. No, I make far too many mistakes for that. But I have learnt how to manage my mistakes with testing and double checking.

Über-programmers can manage well without being pessimistic. They have total overview of the code and all consequences of changes. But I'…

Database dump with Java

I need to update a database that is created by PHP. The problem is that I am not a PHP coder, but a Java coder, and I need to use some other Java libraries to get the job done. So how can find out exactly which tables to update and how? It would take me weeks to search the PHP code, and I still wouldn't be sure if I got it right.

The first step is to install a clean application on my computer. There is no user data in the database, so if I perform commands like creating a user etc in the web application, I can look at what changed in the database. I'm sure that could be done in MySQL, but I'm not an expert on that either. When the only tool you have is a hammer, everything looks like a nail. So, I'll use Java for that to.

So, I wrote a small Java application that produces exactly the output that I need. It reads metadata from the database to find all tables and columns, lists that metadata and the content of all the rows.

Here it is:import;

Writing Better Requirements with Examples and Screen Sketches

We were agile, we had a Scrum master, we had standup-meetings, we had unit tests, we worked iteratively and met the product owner regularly. We did everything right, except the requirements. When we were almost ready to launch, we suddenly understood that we had missed a critical piece of functionality; namely the complex pricing model. The product owner thought we knew how this should work, but we didn't. This was not a feature that could just be patched onto the application in the end, it took several weeks of restructuring. We might blame the product owner for not communicating this clearly, but we were the software professionals. It's our responsibility to find out what our customers want.

Examples What could we have done to avoid this embarrassment? Should we have spent the first month of the project writing requirements? No, I don't think that's the solution. That might have helped, but it would have cost too much.

There is a much simpler thing we could have do…