Keyboardless Programming

"For an idea to go from your head into the computer, it must go through someone else's hands." Llewellyn Falco

Photo by Alex Bunardzic

Computer programming is an activity that is drenched in abstract thinking. When writing a computer program, we are aiming to automate some behaviour that is detected in our world. For example, booking a visit to doctor’s office. While the everyday activity of booking a visit to doctor’s office seems very concrete (i.e., either go to the office in person and book the visit with the front desk personnel, or phone the office and do it over the phone), when it comes to doing it in a self-serve automated fashion, we need to teach machines how to assist us. And to be able to do that, we need to model the patient visit domain. Which means, we need to be able to extract some abstractions (read: simplifications) of the entities and rules involved in the modelling.

This modelling is what we call software design. When we think we have a good grasp of the patient visit domain, we move into implementing it. How do we do it? We do it by automating the process of walking in/phoning in to the doctor’s office front desk.

How we actually do that is always open for debate. As the saying goes (an ugly saying, by the way, but we’re stuck with it), there is more than one way to skin a cat. Still, whichever way we choose to go about implementing our model, we will be trying to translate our ideas into something that machines can understand and execute.

This machine understanding/execution is what we call computer programming. We need to have a good grasp of the programming language of our choice, and use that language to describe to the machines (computers), to teach them, how to go about booking a visit at doctor’s office. At the end of our task, a computer should be able to accept some input values (e.g., patient’s full name, patient’s health number, the reason for visit, the date/time of the intended visit, etc.) Once the computer is capable of doing that, it also needs to be able to know how to validate those user supplied values, and once validated, how to actually book the visit and how to notify both the patient and the doctor of the upcoming booking event.

Or, the computer should also know how to deal with incorrect information. All that knowledge must be supplied to the computer in the form of syntactically correct source code written in the programming language of choice.

With me so far? OK, so what’s the big mystery? That’s how we’ve always been developing software. Well, what’s kind of new in our practice is the introduction of the so called ‘keyboardless programming’.

How Can We Program Without A Keyboard?

Some people may be thinking that we’re talking about programming by speaking to the computer, by dictating. No, that’s not what keyboardless programming is about. Keyboardless refers to the fact that when trying to implement an idea by writing the source code, the person who proposes the idea must not be the person who actually goes ahead and types the implementation of the idea using the source code.

This approach implies at least two people working at a single computer. One person is the ‘idea guy’, the other person is the ‘roll up my sleeves and do it guy’. This practice, as strange as it may seem to many software developers who are accustomed to working alone in front of their computer, is actually quite old. It was introduced back in 1990s by Kent Beck, when he formulated Extreme Programming (XP). This thirty years old practice is called Pair Programming. Here is what Kent Beck wrote about Pair Programming:

Write all production programs with two people sitting at one machine.

Taken to its natural resolution, that practice leads to keyboardless programming, where "for an idea to go from your head into the computer, it must go through someone else's hands", as Llewellyn Falco famously wrote.

That orientation only got improved some 15 years later by the introduction of mob programming, where more than two people are sitting around a single computer and collaboratively developing software. The improvement led to the realization that software development is a branch of the discipline known as “distributed cognition”. It is impossible for a single person, no matter how competent that person may be, to produce quality software product all by him or herself.

In other words, it takes a village.