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.