Recently I visited a conference for beginner scientists and engineers entitled Summer Young Researchers Colloquium on Software Engineering, and presented my paper On Reasoning about Finite Sets in Software Model Checking. My talk wasn't great--mainly because the research didn't yield the results it was expected to. However, the post is not about this.

Most of talks weren't very inspiring. However, some of them revealed interesting ideas that concern availability of programming.

Service-oriented development

The first talk, devoted to service-oriented approach to programming, was given by invited speaker Dr. Prof. Tiziana Margaria-Steffen from Potsdam University.

The main idea of her report was that software development is unnecessarily complex. Software Engineering, the discipline that studies the craft of creating software, mostly addresses issues of how it should be made, not what should appear at the end. However, if we switch focus to the services that software should provide, we can make the development process different.

She later passed on to the system that demonstrates the success of such a focus shift, jABC. Its main purpose is to separate business logic from implementation of the concrete components, and have a nice graphical editor of the former (see side note).

Of course you heard about such systems a lot of times. Of course, I couldn't stand trying to find out what's so special. According to Tiziana, that system has been developed for over 15 years, and still isn't dead. The reason is that the business logic was constrained to having absolutely no synchronization between concurrent processes; an only parallelism supported is fork-join parallelism: spawn a constant number of threads and wait for them to finish.

But of course, expressiveness isn't the main feature of such systems. The main one is that it allows non-programmers to construct programs. In my opinion, however, if a person is capable to create a runnable flowchart, he already has enough skills to do it without any "flowchart-driven development". Tiziana's answer to my question about that was that to create a program, a certain amount of skills is indeed required. But if you need to slightly modify the program already created by someone who has enough skills, you don't have to bear them as well.

After I poured upon that, I agreed that it's possible. Perhaps, the reason is that minor modifications require the skill of reading programs, not the skill of programming, which is necessary to creating them. And it is such "flowchart" systems that make this possible. And it means that more people will be programming.

Not-so-natural language

Another report that interested me was the one given by Andrey Klebanov from SpB ITMO. It presented yet another system that verifies automata-based programs, but it had a minor issue which is, in my opinion, more profound than the rest of the work.

The specification for the checker should be written in English language, constrained by a specific grammar. The specification language, which defined some kind of a temporal logic, had a grammar which contained natural-language sentences! So the requirements would look like this, literally: After the red button was pressed, in the finite amount of time coffee will be made. (instead of a temporal logic formula "Button -> ◊Coffee"). And what is important, these requirements will be processed by a machine.

Anyone who's familiar with maths, and who is a specialist in software engineering would argue whether it's convenient. Such enormous amount of unnecessary text in conjunctions and pronouns would anyway make specification writers auto-generate them from a more succinct format.

But I later realized that this system has an important benefit. It increases the availability of specification writing, lowers the bound of education necessary to write a machine-readable spec. If a highly-qualified specialist is to write such a spec, it will convert it from a succinct notation--but such conversion would anyways have been made. Abstracting away from the natural language, writing temporal logic requirements in mathematical notation requires certain skills, which not everyone possesses. So you could hire a less qualified programmer to to the specification writing job. A "natural" language notation should make writing requirements in a formal way more available, more cheap, and increase demand for verification tools.

Are the programmers still needed?

Of course, the increase of availability of development arises sad questions. Will we, the programmers, be needed by mankind in the future? Will we be the new Luddites?

I think, we totally will. However, someone has to write and maintain programs that will replace us. Someone has to make a relevant research. Communications of the ACM May 2010 issue presents an article about the (still research) prototype of a genetic algorithm that fixes bugs in programs. Today it makes most of us smile. Soon the smile will change to grin, and then--to panic.

However, I will not worry about that. It's natural, at the first place. Also, the first parts of the process that will be overtaken by robots and by low-qualified workers are the most tedious aspects of programming. Fixing bugs by digging into stacktraces, writing integration code, writing tests, creating specifications for complex obsolete programs will be the first to automate and outsource. What will left is the pure art of programming, that small piece of our work we all love it for. There'll be enough of that for the rest of my life.

And my kids will be lawyers.

Comments imported from the old website