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.

jABC's business logic editor screenshot

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.

Well, that's what availability means. And I think that it is a boon.

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

silky (id) on 09 June 2010 commented:

Interestingly, I think the law profession would be more easily adaptable to a programming (automated) solution than programming. Or at least, around the same ease.

After all, if you can specify the "job" properly, (and have a sufficient database) I would imagine a program to be far more efficient at constructing arguments than a real lawyer.

Pavel Shved on 10 June 2010 commented:

Totally impossible. Lawyers talk to people. People are no XML data. Hence lawyers can't be automated.

Last year I had an interesting discussion with a bored Russian Migration Service representative at "Softool" exhibition. We discussed a possibility of automated processing of human fingerprints. The conclusion was that though the process could be automated--in an ideal world. But here we need to persuade judges and society that this man is guilty, and that is not. That can't be done by computers alone. People don't trust computers. But people do trust lawyers. Perhaps, that's because the lawyers are homo sapiens as well, but computers are not.

So before the lawyer profession will be automated, (by nice and shiny and smiling robots) my kids will already be dead.

Let alone that specifying the job properly is the most difficult part of the process. As for theorem proving tools, they showed some success several years ago, and I think that there'll be a major breakthrough in less than ten years. Lawyers still don't have to be worried though :-).

silky (id) on 11 June 2010 commented:

You're clearly a smart guy but your logic in your first statement is not sound. Lawyers do talk to real people; that is a component of their work, but the primary component of being a 'lawyer' is being familiar with rules and constructing arguments. This is programmable. So while there may not strictly be a computerised lawyer, there may be software able to do the primary job of a lawyer. So you may end up with lawyer-bot-operators. Clearly less-skilled work than a true lawyer, and - in an ideal setup - significantly more accurate/productive.

Pavel Shved on 12 June 2010 commented:

I don't agree that analyzing existing data, in order to construct arguments based on them, is the primary job of a lawyer. I currently work with lawyers on some personal stuff, and here's what I see them doing:

  1. Gathering data relevant to case. My whole life (and the lives of others) just can't be formalized, and investigating what's important can hardly be automated.
  2. Checking if it's possible for me to do something that can affect these data.
  3. Deducing arguments and planning appearance in court. Construction and verification of this can be automated.
  4. Actually making appearance in court.
  5. Talking to people and persuading them to perform specific actions.

One out of five. At most, there can be a program that automates (or assists in doing) the third step. But it's not the most difficult part, is it?

But what it see in movies and in media demonstrates that a successful appearance requires more than just a logical argument. A masterpiece example of an attorney's work, portrayed in The People vs. Larry Flint movie, is less of a logical argument than of the way he spoke. In most case arguments are much more boring and automatable, but there surely is a lot of cases, which not the argument wins.

silky (id) on 12 June 2010 commented:

One of five yes, but the most skilled One.

Lets not forget that most law is not anywhere near as interesting as movies portray.

Nevertheless, I'm going to assume both sides of the argument are now visible; we've both made our points and I'm sure the general theme of the comments is getting through.