The Computer is Dead, Long Live the Computer

Finally the follow up to my February 2007 Post.

If you look up the definition for Computer you will find that it has a second definition that may surprise you. This is actually not the second definition, but the original definition of the term computer. You see a computer is "a person who computes; computist." So where did that come from? Well, back in the stone age before the personal computer or fire, accounting departments used to be full of people who would keep the books. These people were not accountants, an accountant is someone you hire to help you make sense of all the numbers. An accountant can tell you if you are making money and how much. This is often much more difficult than you might imagine. It is so difficult that we still don't have computer programs that will do it. Instead we have Excel.


Obviously Excel means that we no longer need computers (the human version) in an accounting department, right. True, but only sort of. It seems that though we no longer have rows of people with their heads bent tallying columns of numbers, we do need to have book keepers. When personal computers began to automate what people computers were doing we quickly learned that they had task that were easy and tasks that were exceptionally hard. By easy and hard here I am talking from the computers perspective, not the people's. Accurately tallying a column of numbers is difficult for many people. When you add in the need to do it quickly, and without error it is nearly impossible for most people. Computers find this very easy however. Other tasks that the computers (people not machine now) were doing are very difficult or impossible for a PC. Tasks such as deciding which category an entry belongs in. Maybe you can create a rule like all invoices from Krispy Kreme Doughnuts goes into business expenses, but these type of rules typically break down quickly. So even though the people in the accounting department are not doing sums anymore there are not that many fewer people in the accounting department than there were prior to the PC revolution.

Why do I bring this up? Especially in connection to software development. The issue is similar. Back in February of 2007 I wrote an article about a company called Intentional Software. I talked about the issues facing software development and why I didn't think Intentional Software was going to change the software industry. The trick is that they are trying to create a piece of software that makes software development easy, and software development is hard. Software development is not hard because we have to learn cryptic languages to be able to talk to the computer. Software Development is hard because it is process automation and processes are inherently hard. We are back to making all those fuzzy decisions like what category does this invoice go into?

I am currently working on a project to create a panel that is ridiculously easy to use. There are some particular challenges to this project as it is a computer that will be used on a shop floor. Keyboard and mouse are not completely out of the question, but it will have to work without them most of the time. This has lead me to think about what easy to use means. Here are my ideas.

The Interface Must be Apparent
This is why GUI programs are often seen as easier to use. They are more apparent. When people are working they do not want to go looking for things, they want to just do what ever they are doing. As shocking as this may be to computer programmers, most people do not enjoy spending time on a computer. Furthermore, most people find figuring out arcane steps to complete a process a bore and more than a little annoying. At any given moment the interface needs to make the option as obvious to the user as it can.

Actions Should Work with as Little Interaction as Possible
Every question that the user is asked is a distraction. When I ask my word processor to put today's date into a document, it should use the format that makes sense given my locale. It would be nice if I can then change the format. However asking me to choose the format every time I ask for the date is bad. The vast majority of the time I want the format that is the default for my locale (locale is language and country). Similarly when I save a file I should be asked where and what to name it once, not every time. After I have establish the files name and folder, I will rarely wish to change it. These decisions depend on the use case that is expected, but I think you see where I am going. Another aspect of this is that I should not have to go hunting through the menus to find something I want to do. If it makes sense in the current context then it should be available with one or two mouse clicks. Everything should be available through the keyboard. In the case of the project I am working on there needs to be a button on the touch screen.

Side Effects Should be Minimal
When I select an action I should not have to spend any time wondering what else this is going to do. Each command should be self contained. In this way the user can start to think in terms of steps to accomplish some goal. If too much is wrapped up in a single action then the user can become torn between what they want to do and the side effect they wish to avoid. Furthermore, having minimal side effects fosters the user to use the software in way that you did not expect.

Action Should be Complete
This is the balance to the minimal side effect rule. The user should not have to build what they consider to be simple actions. To save a file it would hardly make sense to ask the user to select the default directory. Then go through the menus and set the current file name. Finally to go through the menus again and choose save. In addition to being cumbersome, this makes it more likely that the user will miss steps or in other ways mess up the process. There is a balancing act between minimal side effects and complete actions that is often difficult to manage. However when it is managed properly there is a real sense of power in using that software.

Software must be Reliable
You may not think of this as an ease of use requirement. You may say all software should be reliable and I would agree. In this case, however, reliability does enhance the usability of software. The goal of easy to use software is to create an environment where the user can focus on their goals rather than on using the computer. Any time the software fails it interferes with this goal. Furthermore, it can cause the user to second guess themselves when they are attempting to accomplish something. They will wonder if this mouse click is going to cause the program to exit.

So what do we need to make it easier to program? We need an environment that does these things, but we also need an environment that can choose data structures and algorithms well. Yes I know you are an Object Oriented Programmer (OOP), so you don't use data structures or algorithms. Actually when you create an instance of that Set class you are choosing a data structure, and when you choose to use the Singleton design pattern you have chosen an algorithm. These decisions are difficult. They tend not to have pure right/wrong answers. They tend to be highly dependent on how other questions where answered. Furthermore they are dependent on how the process "should work". This is almost never know in a definitive way.

The short answer is that though software automation will continue to improve. Libraries will become larger and more powerful. Software Developers will not be wholesale replaced by machines any time soon. It is difficult to think about the things that need to be decided when developing software. Currently people still think much better than machines.

Unintentional software

In my last post I came down fairly hard on a company called Intentional Software as I said in the last entry I do not mean to single them out. I do think they are jumping a bit far. I think the next step up the abstraction ladder is Component Base Programming. This is neither my idea nor a new idea. Building software from reusable and cheap components has been the dream of software developers essentially from the beginning. So far the components are not cheap (most projects still build their own) or particularly reusable, but they still have many strengths. In my last job I had the experience of working on a project that was using Component Oriented practices. After a couple of years of work on the system a team of about 10 developers had created 78 discrete components. What was more amazing is that we had created 4 distinct (though related) applications. I had the experience of prototyping one of those applications. I was able to pull together several of the existing components, write one that combined and extended the functionality of three other components and wrap it all in enough code to create a functioning prototype of the new application in 2 weeks. It really blew me away how powerful this paradigm is.
This is what software developers have been looking for, except that we were creating our own components. We had also created our own framework for the components to live within. The framework incorporated both the services necessary for components (creation, version control, etc) and an inversion of control container. This allowed us to inject customer specific functionality into the architecture at the component edges. The project went on to be a success with about 3 months work to complete the first customer implementation. The next implementation took 7 weeks.
The "failing" of component oriented development is that this is still work being done by programmers. So it does not reach as far as "non-programmer" writing a system, but it is definitely a major step toward that goal. I am hesitant to call it a failing because it is a major step forward. So what is the next step toward non-programmer programming? Well as the question implies the problem is in understanding the term non-programmer.
If someone takes a set of actions that result in a program that does something, isn't that programming? I think, as I said previously, that the core of this goal is flawed. Someone who has learned enough to cause the computer to accomplish some goal is a programmer. The issue is not to remove the programmer, but to allow a business expert to become a programmer. The goal is to create an environment that is easy enough to use that the people closest to the problem can work on automating it directly. I did not say that the environment had to be easy enough to learn, but easy enough to use.

In my next post I will talk about the difference between easy to learn and easy to use. I will also talk about why Excel hasn't put more people out of work.