I have a great deal of respect for Brad Cox. In fact, consider this essay a tribute to Brad. Ten years before he wrote, Planning the Software Industrial Revolution, I was living in the integrated circuit world of R&D electronics, where it was already an industrialized industry. I could order chip, card and rack level components from catalogs and plug them together though a set of standardized interfaces that solved a set of problems that I had specified in an electronic schematic diagram. During that time, I was also a participant in industrializing printed circuit board layouts that initially took 6 to 8 weeks of hard manual labor on a light board to, ironically, using a computer program to read an electronic schematic diagram (i.e. specification) and producing the printed circuit layout in a matter of minutes. In other words, I experienced first hand what industrialization was and meant in the electronics industry.
When I first got into the software industry in 1990, I thought it was going to be similar to the industrialized electronics industry I was used to. I could order software components (like integrated circuits) from catalogs and using a schematic diagram, CAD like software program of some sort, assemble those components to solve a set of problems. Nothing could be further from the truth. Then I read Brad Coxs article and realized what I took for granted in the electronics engineering world may not even happen in my lifetime in the software world. It was quite a shock to me. I had no idea the software world was so far behind, and in fact, completely unindustrialized.
Flash forward 15 years and I have performed just about every role one could imagine in the software industry, including running my own software company. I feel like I have gone nowhere in this industry and in fact, in some respects gone backwards. I still write the same source level code I did 15 years ago and build most everything from first principles. Sure technologies have changed, but we (meaning everyone in this industry) are still building our software world, one source code line at a time. As Brad says, grains of sand where bricks are needed. Whats wrong with our software industry? Why dont we learn from the successes of other industrialized industries? Are we that arrogant that we have to do everything from first principles over and over again?
In Brads article he discusses the importance of Blanchards pattern lathe and that the real crucial discovery made was, that implementation tools were insufficient unless supplanted by specifications tools capable of determining whether parts complied to specification within tolerance. As Brad points out, this discovery has not yet occurred in software. In my opinion, 15 years later, it still remains undiscovered. Making software tangible and observable, rather than intangible and speculative, is the first step to making software engineering and computer science a reality. Brads sentence still applies today.
Ironically, computers and computer programs have helped other industries become fully industrialized. In 1982 AutoCAD came to the world and revolutionized the industrial design and manufacturing industries, including my printed circuit board story above. The craft of drafting has not gone away, but the tools used have raised the level of abstraction to the point today where those specifications are now items that I can order out of a catalog. For example, if I want to design a house, I dont have to invent the drafting symbols that represent my house, they already exist and in fact, can be ordered from a catalog. Further, I can order the entire house specification (funny enough called an architectural blueprint
from a catalog and customize it (using standard symbols) to what I want. That specification is then used to implement (i.e. build) the house. Some people would say in the software world we have that through UML. When I showed a business person a UML use case diagram, he said, Stickmen? Thats all you have is stickmen? And then he proceeded to laugh uproariously and just walked away. At the time I felt angry and thought another bozo that does not get it. But as years went by, I realized he was totally right. How embarrassing for our software world where the best we can do on the specification side is stickmen.
So we need better specification tools, thats for sure what else do we need? As Brad writes, the programmer shortage can be solved as the telephone-operator shortage was solved by making every computer user a programmer. I wholeheartedly agree. This would dramatically increase the chances of industrializing our software world. At the very least it would help us with the most frustrating part of our world and that is human machine interface design. Generally speaking, software engineers and simply dont get it, for whatever reason. Lets look at several examples of what I mean and tell me I am wrong.
Take your average DVD player. Did you ever happen to notice that the hardware (DVD player) does not control the software (DVD disc)? One of my commenters (thanks Michael K) on my blog said, I want a DVD player that works like a VCR. When I press fast forward on a VCR - the recording goes forward. With a DVD - it is up to the disk whether I can fast forward it or not - total lunacy! Its my player it should do what I tell it, now! And just how many DVD players are there in the world?
How about automated phone attendants? A sure way to increase the blood pressure of even the calmest West Coaster, particularly the new and improved attendants that respond to your voice commands instead of key commands. Insert your favorite voice command here
The fact companies purport that they are customer driven by using automated attendants is a joke or is it that they dont get it? (ha!). When I speak to a company, I want to hear a human being answer the phone and one that knows the inner workings of the company to provide me with a layer of abstraction between the companys goofy organizational structure/behavior and myself. S/he is the public interface to the company that hides the inner workings from me. The thing about it is that we used to have it, so what happened?
What about ATMs? Well, it is a matter of convenience. The fact that I can quickly get money, usually without waiting in line, is what I want from a users perspective. So that part of the abstraction is good, but the human machine interface could do with another tweak. That is, if I have only one account, then dont give me account choices. I get asked for checking, savings, and other, every time I use the machine, no matter where I go in the world and I have only one account. How hard can it be?
Even the firmware in my wifes German precision engineered washing machine is koo koo. It has lots of intelligence built-in, but the machine does not automatically shut-off by itself. It will beep beep, beep at you until you come and manually turn it off. Going through the 27 page manual, I found a way to at least turn-off the beeping. However, months later it came back and I forgot the magic key combination to turn it off and I refuse the read the frickin manual again. How can this be? How many millions of washing machines have rolled off the production line in the last 25 years? And still cant get down to the one button interface called wash clothes, and dont bother me again.
Or how about, Windows Vista, 5 million lines of code, 5 years later and Hasta La Vista Baby! As you will see they have also opted for aesthetics over functionality. What does the customer really want? An extremely fast, low memory, transparent to the user and completely reliable operating system. Thats it! Again, how hard can it be? Yet, wait till you see it and by the way, you will need to buy a new computer to run it. That from the largest and most successful software development company in the world today.
Finally, while not really software based, is an excellent example of poor human to machine interface design. The building that I work in is having its washrooms renovated and you guessed it, upgraded to automated faucets, soap dispensers, urinals and toilets. Yes, the toilet is fully automatic, with no manual flush. Of course, the renovations are occurring floor by floor meaning that for the people on the floor that is being renovated will need to go up or down a floor, which means those washrooms are rather busy. So what if the automatic toilet does not flush? And there are people waiting? I can tell you that one of the toilets, (3rd floor, right stall), is batting a .500 average.
The first lesson for anyone becoming a software programmer is to become a designer first. There is an excellent book called. "", written around the same time as Brads essay. This book should be required reading for every designer, software, hardware, industrial, art or otherwise. One story discusses the design of doors and the visual clues it presents to the user to determine does this door push forward or draw backward and if I need to turn a knob or push on a bar or what exactly to make it work. Yes, something as simple as a door, we still cant get right. Aesthetics win over functionality, almost every time cause thats what the consumer perceives s/he wants. Me? I just want the door to open like in old school Star Trek, complete with the cool sound. Oh yeah, you will recognize the book as it has a picture of a red tea pot on the cover with the spout and the handle on the same side. Nice design!
So what does this have to do with industrializing software? Everything actually. Until consumers demand better software, cheaper and faster, we will continue to handcraft solutions one source code line at a time that cant be measured for conformity to any users specification. Eventually consumers will revolt or go elsewhere where someone else has figured out a better way to do it, just like when consumers got fed up with American cars, they went to Japan.
I am somewhat encouraged by the fact that Domain Specific Languages (DSLs) are making a resurgence as I believe this is the right path towards industrializing software development and meets Brad Coxs vision. DSLs raise the level of abstraction to a point where a visual model specification is used to specify the implementation and can verify its correctness. AutoCAD can be classified as a DSL as it allows non-draftsperson or non-engineer to still produce a drawing that is accurate enough for someone to implement it. For example, from a catalog, I can order a drawing of a piston, put it in a CAD program and modify a dimension, save the electronic file output, take it to a milling shop and get my pistons manufactured, and yet I know nothing about the industry. Now thats industrialization.
A Challenge to My Software Developer Peers
I challenge my software developer peers to help industrialize our software development industry. Brad Cox has made a major contribution not only with the article he has written, which I reference here, but also with Objective-C System Building Environment that he invented. My very small contribution to software industrialization is co-inventor of a DSL called Bridgewerx that allows a Business Analyst (not a programmer) to specify (AutoCAD like) an application integration specification that is then automatically implemented, without any programming knowledge required. And before you crucify me for plugging a product I no longer have any financial interest in, I did it because I am personally sick and tired of writing the same source level code over and over again for the last 15 years. I want higher level abstractions in better tools. What are you doing to raise the level of abstraction in our software industry?
I leave you with the last paragraph that Brad Cox wrote 15 years ago in his article. It is just as applicable today as it was then and probably still applicable when I am no longer around.
I only wish that I were as confident that the changes will come quickly or that we, the current software development community, will be the ones who make it happen. Or will we stay busy at our terminals, filing away at software like gunsmiths at iron bars, and leave it to our consumers to find a solution that leaves us sitting there?