I came from the R&D electronics engineering world in the 80s and got into software development in 1991.  After 15 years in the software dev biz, the only conclusion I can draw is compared to the industrialized electronics world I came from, the software development world is decidedly unindustrialized.  In addition, we are going backwards instead of forwards in our progress towards industrialization.  I am genuinely concerned about the future of our software industry.

 

Nonsense you say?  Let me put some context and perspective around my statements.  In the 80s when I was still in the electronics engineering world, software computer programs (i.e. CAD/CAM) were on their way to the top of the Technology Adoption Curve,  particularly with the release of AutoCAD in 1982, which soon brought a level of design automation to the electronics engineering world that was literally revolutionary.  I lived it.  Here is a concrete example of what I experienced.  Instead of handcrafting printed circuit board layouts by hand, within a couple of years, we were operating several sophisticated computer (i.e. CAD) programs that could assist with the design of the layout of the board cheaper, better, and faster than I could do it manually.  What the CAD programs didnt have was my experience so in the hands of a skilled and experienced operator meant the ability to put cheaper goods, with much more quality in the hands of consumers, faster.  It also meant some serious electronics industrialization has happened over the last twenty-five years - almost feels exponential in my opinion.

 

I used the term unindustrialized in the first paragraph, what do I mean be that?  I mean that in our software development world, we do not have any (real!) predictable or repeatable processes for the specification (i.e. design) of software.  And please dont tell me about yet another great process methodology**.  Worse yet, when we do design and construct a software artifact, it invariably is the wrong thang.  We also cant scale in anyway to design large scale architectures.  Finally, our software development world today is based upon designing software from first principles, rarely do we leverage other peoples excellent work, including CAD systems and/or approaches that worked in other, now industrialized industries (e.g. electronics).  I see the latter being the biggest hurdle to overcome as it is a cultural change instead of a technical one.

 

** Note In 1995 I worked at Eastman Kodak in Rochester, NY.  Kodak Equipment Commercialization Process (KECP) was a new product introduction (NPI) process methodology that has evolved for decades we have nothing this evolved in our software world.  Further, some would say that in order to make a process predictable and repeatable, you need to be using the same tools over and over again or at least for a period of time to establish a baseline and then a feedback loop.  Our software tools keep changing every six months (or earlier), so we cant even establish a baseline let alone a feedback loop  Kodak knows a thing or two about industrialization and we in the software industry could learn from that.

 

What do I mean by going backwards?  I feel that we are going backwards in two areas, programming languages and more importantly, design environments that can produce design specifications, and no I do not mean CASE tools.  We are woefully lacking Computer Aided Design tools that are now best practices (and have been for years) in other industrialized industries like electronics, manufacturing, building construction to name a few.  Do you think it is unreasonable of me to expect better software design tools when I was handed exponentially more powerful tools in the electronics industry years earlier?  Thats my gripe, still hand crafting single lines of code after 15 years in the industry.  Something is wrong, man!  Maybe I am real naive or born in the wrong era, but you would think that we in the software industry, after 15 years (try 30!) could come up with better design tools than a glorified text editor, now mockingly called an Integrated Development Environment.  No?

 

So, programming languages, how can I say we are going backwards?  Preposterous!  Well, whatever happened to Smalltalk?  Yes, every programming language is a foreign language, some easier to learn than others and thats my point.  Have a quick read of this short article from 1991 to see what I mean.  From my industrialization perspective look at how incredibly simple and efficient Smalltalk is!  The language consists of 5 keywords (Java and C++ have +50) and the entire language specification can be expressed on a single sheet of paper!  Isnt this the pinnacle? The state of the art?  Its language roots are +30 years old and seem to be one of the most mature programming languages available.  What happened?  Not only was the language simple, but the development environment was equally as simple along with the most seamless source control I have ever worked with.  Again, what the heck happened?  Whats wrong with Smalltalk?  No, I dont mean strongly typed versus dynamic or VM or GC or anything technical.  I mean is it because our industry is so immature we cant see a good thing when we see it?  Is it because our industry is dominated by a handful of companies which dictates the software programming languages market?

 

The multiple programming languages I use today and the IDE I am in are far more complex by at least an order of magnitude.  Further, rather than optimizing a language that is simple to learn and effective, we proliferate choices for the sake of choice, nothing technical here.  I know of one vendor that supplies 7 different graphical user interface technologies, each complete with its own framework class library and even more IDEs.  7 UI technologies from one vendor?  How is this making it easier (for anyone)?  How do I know which one to choose?  How do I become expert in any of them, as I still need use my primary language (C#) and another incredibly large framework class library, .NET 2.0.  If anything, it is getting harder and harder to develop custom applications, not easier.

 

XAML is a brand spanking new declarative programming language from Microsoft.  This raises the level abstraction from an impetrative programming model (e.g. C#) to a declarative programming model.  So if I need a day job and live in the MS world, I would take a long hard look at XAML.  It goes far beyond then just another user interface mark-up language (using Windows Presentation Foundation).  Sure the view is separated from the model, yay, but that was a Smalltalk invention (i.e. MVC).  However, the crucial invention here is that XAML is a language that enables developers to specify a hierarchy of common language runtime (CLR) objects with a set of properties and logic.  Meaning specifying a hierarchy of any .NET objects using a declarative language.  Hmmm there is a CAD program for designing software in there somewhere.  Key point to get - just like Objective-C provided an interface to any objectified clib to be plugged together like electronic integrated circuits.  Remember Brad Coxs Software ICs?

 

When I was working at a software company called the AND Group in the early 90s, an extremely sharp programmer named Tim Wasko (look at you now Timbo!), showed me Brads invention on a NEXTSTEP computer.  I was blown away and so was Tim.  Brads Interface Designer and Integrated Circuit (IC) library approach to supplying and assembling software components using a common interface (Objective-C) rang true to me then as it does now, 15 years later.  It is an excellent analogy to the tools and approach we took in the electronics engineering world.  Not only did it work, but software programs like AutoCAD had a major impact on the entire product development process for the electronics industry (and others), meeting the requirements of industrialization.  Finally, a piece of software that can really claim automation of processes and offers scalability that no human could do.  AutoCAD (and similar) revolutionized the electronics engineering through the 80s.  Note that the tool enabled the process of industrialization and in fact, you hear little about the product development process, cause it is well known.  However, in our industry, because we have no standard way of designing software, all we have is process methodologies with dumb a$$ names.

 

Brads Objective-C System Building Environment is interesting as most people classify his invention as yet another programming language.  Unfortunate, as the crucial invention here was that the language (i.e. building environment) allowed systems to be easily designed based upon assembling composite objects using an Interface Designer and IC Library.

 

This approach is very similar to the electronics world where our designers are various CAD programs that would specify what we wanted in terms of electronic schematic circuit diagrams, circuit board layouts, mechanical drafting design, etc., which all represented the specifications (i.e. design) of what was to be implemented (built, constructed, made real, realized, whatever you want to call production).  We also had our IC libraries called electronic parts catalogs that we could order parts that met our specifications and then could be assembled onto our now made printed circuit board whose layout was based upon a circuit diagram specification, all of which we specified (i.e. designed) in some sort of CAD tool.

 

Why do I think this comparison to the CAD world of electronics and our own?  I believe this is the path to software industrialization.  I recently talked to an old mate (hi Darren!) I used to work with in the early 80s when we were part of an electronics R&D shop.  He went on to get his Masters in Electrical Engineering and has been working in Nortels R&D department as a RF Designer for the last 8 years.  I asked him what some of the advances were in the way of specification (i.e. design) tools.  He laughed and said that they have a directory tree full of CAD tools used to specify what they want built.  Most if not all of the tools are visual design tools with a few (visual) simulation tools.  In other words, they are domain specialized tools, with their own languages for each aspect of the specification that needs to be designed.  In fact, if you were to classify it to our software world, one could say that each one of these CAD tools encapsulated their own Domain Specific Language (DSL).

 

I would also say that Brads System Building environment, from 15 years ago, was also a DSL that objectified clibs using a standard interface (i.e. pluggable palettes and a common design surface).  In other words, the visual design raised the level of abstraction to a point where you were assembling prebuilt C libraries that plugged into a standard interface.  That meant any supplier of clibs could objectify their library and have it plug into the design environment.  One analogy is like Visio where you buy a set of 3rd party symbols (like electronic symbols for example) that plug into Visio as a standard palette in which now you can interact with on the drawing surfaces and design circuits.

 

In fact, this is the point of the analogy.  In the electronics world, the electronics circuit schematic diagram with its symbols and lines represent a design specification.  Every other artifact and/or transformation is derived from the design specification.  Note that everyone uses the same (domain) specific language to design electronic circuits.  This language consists of numerous symbols.  Each symbol is an abstraction of the real thing.  There are symbols for resistors, capacitors, transistors, integrated circuits, etc.  But note that the symbols are simply interfaces.  Each interface has a definition, like a resistor symbol typically has two connectors and between those connectors is where the specification of the resistor is specified, in which there are a million combinational values. Or another way to look at it is someone elses spec sheet is the resistor value.  In fact for every symbol or interface on the design surface is where you indeed plug in a spec sheet that came from a catalog or that you have to custom build yourself or a third-party builds it for you.

 

Of course, in the electronics world, we use CAD programs to draw our schematic diagrams using these standard symbols.  We still dont have these types of specifications tools in our software design world.  In fact, we still dont get what software design is.  Have a look at this 1992 article on, What is Software Design.  Software design is still the 1000s of lines of code - in other words, the actual program listing is the only real design specification.  This program listing was hand-crafted