Lets take a break from whats new in software development for 2006.  In Part 1 and Part 2 of why software industrialization, I discussed some basic concepts around what does software industrialization mean and why we need it. Software industrialization is designing and constructing software in a predictable and repeatable manner.  Software industrialization is also producing a software, of any sort, that actually meets the user communitys requirements, whatever and whomever they happen to be.  Thats it.

 

In our software industry, there is a still a tremendous gap between requirements (i.e. describing the intent of the software) and the actual software deliverable (i.e. executables).  In fact, if you look at and believe statistics, our numbers aint so good!  The reality is that, we as software developers or engineers, dont have any predictable and repeatable process for creating software and we dont get the software right the first time.  In fact, we may never get it all right.

 

I have been involved in the software development industry for 15 years and have worked for several companies both in Canada and the United States ranging from my own start-up company, that I co-founded with Barry Varga, called, 5by5Software, now Bridgewerx to the very large (Kodak, Motorola and lots in-between.  Each company had their own process for designing and constructing software.  These development processes ranged from fly by the seat of the pants to highly process controlled CMMI complete with formal assessments.  In these companies I participated in several different development methodologies including RUP, extreme programming, Agile, old school waterfall for those that remember, and a mix of pretty much everything in-between.

 

I have read several dozens of books on the subject of software engineering, hundreds of articles and attended many a conference/seminar on the subject area.

 

Based on 15 years experience, I draw a few observations and maybe a conclusion or two:

 

1. Its still the Wild West" when it comes to software development.

 

2. None of the software development processes or methodologies that I have participated in has proven that one is no better than the other. The harsh reality is that manual labor software development is still mostly a trial and error process.  Meaning we are still far away from making it a predictable and repeatable process.

 

3. I have had the good fortune to work with several dozen extremely talented and brilliant software developers/engineers, project amangers, BA's, etc., who are directly responsible for the success of the projects/products I have participated in.  It is these people that have made the difference between success and failure and had nothing to do with processes or methodologies or toolsets or programming languages or technologies.  Its all about the people!

 

4. There have been a few critical innovations of late that appear very promising for increasing the level of predictability and repeatability of designing and constructing software.  These innovations are described in a book called Software Factories  

 

5. Another critical innovation is the renewed interest around Domain Specific Languages (DSLs).  Every programmer should take the time to read Martin Fowlers most excellent paper called, "Language Workbenches: The Killer-App for Domain Specific Languages?  DSLs assist in raising the level of abstraction for developers to produce software in a more predictable and repeatable manner thats the real point behind DSLs.

 

6. All the business user ever interacts with 100% of the time is the user interface, graphical, text or otherwise.  All the business user cares about is that through the user interface they can get at, manipulate, save data in an intuitive and functional manner.  Functional manner means that the software does what the business user expects or wants it to do.  In our technical world, this maybe written as workflow or business rules or custom C# libraries, or whatever development artifact(s) represents this functionality.  However, we software developers forget that the business user does not care how it is done, or what with - when I click on this thing, here is what I expect to happen, your software needs to do that.  Its that simple from a business users perspective.

 

Point 6 will be a topic of a future post, because after 15 years in the biz, I finally get the business user.  And interestingly enough, from a programmer perspective, not getting the business user is the number one reason why software projects/products failed in 1994, and still failing today