In my last post, I discussed the issues around using the title Software Engineer and how our educational system (i.e. Computer Science programs) needs to get into the software engineering game. While perusing about on this topic, I come across a posting on Grady Boochs site called, Certification of IT Architects.

 

Reading the Open Groups faqs, I came across this statement, 2.2 Will there be tests required to obtain the IT Architect certification?   Since there is no prescribed body of knowledge for the program, there is no test. Instead we will assess candidates experience and skills against the requirements of the program by evaluating their written applications and by a Certification Board interview.

 

The faqs go on to say how long it will take to obtain certification (3 to 6 months) and how much it costs ($1250 for the assessment plus $175 per annum to remain certified plus recertification every 3 years).

 

Now, I am all for industrializing our software world, but something bothers me here.  It is the statement that there is no prescribed body of knowledge and therefore no test.  No prescribed body of knowledge for an IT Architect?  Come on, of course there is.  Any seasoned IT Architect can pretty much tell you what the body of knowledge is required to be successful at the job.  It is the same body of knowledge that has been required since the first commercial software project was written some 40 years ago. 

 

It goes something like this: requirements, design, code and test.  Over and over again.  In fact, it has never changed, other than the fancy marketing names that have been attached to this process over the years.  Oh yes, you need some project management skills that you can find in the Project Management Book of Knowledge (been around for 20 years).  Specifically, I would also suggest Grady Boochs excellent book on Managing the Object Oriented Project (been around for 10 years) as a body of knowledge. You will need some body of knowledge on the process of quality as well, the Software Engineering Institute, has several bodies of knowledge on this subject area, including software engineering in general.  The SEI has been around for over 20 years.

 

10 years ago, I took a post-graduate, 2 year certificate program, called, Software Engineering Management at the University of Calgary taught by Karl Williams on behalf of Motorola University.  I can tell you there was a body of knowledge because I had to write 17 exams over those two years to prove I knew what it was. 

 

With respect to being a certified IT Architect, I am disappointed that our software industry would let an organization be accredited to issue certificates without any requirements for a prescribed body of knowledge and no written exams.  How is this advancing the industrialization of software development?

Shane Schick wrote this great article on why no-one wants to be a programmer  As an old-school programmer, I laughed out loud about being a cereal inventor, ha ha!  Thanks to George Rafael for sending this to me.

 

I think Shane is bang-on about Microsoft and other vendors have to take some time out from patting themselves on the back for making great products to show prospective computer science students that it stands to solve still more. They have to talk about what those problems are, and why they will be worth spending hours staring at a screen trying to combat them. They have to explain why the only thing better than living in an software-driven world is programming it in the first place.

 

I can tell you that we are still in the stone ages with respect to software development compared to other engineering disciplines.  The industrial revolution has not occurred yet in the software world.  As a programmer, I cant go to a software catalog and order a login component like I can order an integrated circuit in the electronics world.  How many login boxes do you think have been invented over and over again?  Millions!  And we as software developers continue to code these from scratch even today.

 

It would be great if the young bright minds of our computer science students helped us old-school programmers in developing tools that bring us into modern times so that we dont keep coding login boxes over and over again.  In fact it would be great if our Universities actually offered Software Engineering degrees in addition to Computer Science degrees (arent these the same? See Software Engineering, Not Computer Science ), but this idea still seems to be in its infancy in our software world.  Unfortunately, in Canada we are still arguing over the title of Software Engineer 

 

Titles aside, I am hoping that the professional engineering bodies in Canada are trying to help our immature software development world by institutionalizing some solid engineering practices in our computer science programs.  Doing so will bring software development out of the dark ages and into the modern world where our chances of building successful projects on time and budget will increase beyond the less then 20% success rate (The CHAOS Report) we currently have today.

So how to introduce this technology?  Lets start off with a quote from Craig McMurtry, Microsoft evangelist extraordinaire, who happened by one day to see BRIDGEWERX in action,

 

"BRIDGEWERX exemplifies a new breed of software vendor, best described as an on-demand software factory, that may well turn out to be the fabled next big thing in the Information Technology industry.  On-demand software factories provide superior software design tools in the form of freely-accessible services over the Web, and then sell the software that one designs with those tools, software that plugs right into the target environment.  In the case of BRIDGEWERX, that free designer is a masterfully simple, yet uniquely powerful facility for representing complex business-to-business, and application-to-application integrations in a practical and intuitive way.  Anyone with an integration problem to solve should certainly consider BRIDGEWERX among the top few tools they could use."

 

Barry Varga and I, being the creators of BRIDGEWERX, were quite flattered by Craigs quote.  For myself, it was a bit of a relief as we were (and still are) having a heck of time trying to describe our wares to people.  Craig gets it, but not too many other people do.  Why is that?

 

As Albert Einstein once said, the only source of knowledge is experience.  As it turns out, not too many people have experience with application integration.  For the ones that dont, they are quite surprised to find out that applications dont normally communicate with each other as a matter of course.  For the ones that have application integration experience, they are extremely skeptical as they know what a mind numbing, labor intensive process it really is and cant believe one can draw an application integration scenario, let alone code generate the solution.

 

In some small way, I would like to think Barry and I contributed to the industrialization of software with our invention.  If you want to see BRIDGEWERX in action, (it will only take an hour, grab a beer, some popcorn and treat yourself to a Live Meeting presentation (courtesy of Jim Bowyer - BizTalk guru from Microsoft).

 

In my next post, I will discuss the history of this invention.  As the saying goes, ...I have not failed. I've just found 10,000 ways that won't work --Thomas Edison

I am going to leave the sorry state of our software industry behind as I think it is fairly obvious by now that we are in need of some industrialization.  The type of industrialization I am talking about is similar to what happened to the engineering design and manufacturing world in 1982 when a company called Autodesk introduced a Computer Assisted Design (CAD) tool called AutoCAD.

 

AutoCAD revolutionized and industrialized the engineering design community, not only with its full-fidelity drawing tool, but also with its universal file format called Drawing eXchange Format (DXF).  This meant other drawing tools and devices like Computer Aided Manufacturing (CAM) machines could read the DXF and render itself on a computer screen or produce a physical part output.

 

AutoCADs revolution also came in the way of computer automation.  Look at what it did for building architects.  Aside from easily sharing blueprints electronically, it introduced standards in the way the blueprints were put together, in a fraction of the time it took to do it by hand.  Now they had reusable symbols and even room constructs where one room can be replicated 100s of times in the blueprint to produce a skyscraper in a matter of hours instead of months.  Revolutionary indeed!

 

What our software industry needs is a way of describing software size and complexity in the form of an architectural drawing or blueprint.  Lets take a traditional building blueprint for example.  Almost anyone, without any training, can differentiate between an architectural blueprint of their 3 bedroom bungalow compared to the Empire State Building. 

 

However, we as software developers have nothing like this or so it seems.  Some may say that this is what IBM/Rational Rose does with UML or Visual Studio.NET (2005) does with its Domain Specific Language.  However, it still requires highly skilled designers and programmers to work with these models and they seem to be quite far away from a full-fidelity modeling/drawing tool like AutoCAD.

 

In my next post, I will discuss a full-fidelity modeling tool called BRIDGEWERX in which a Business Analyst can use a drawing tool to completely describe application integration scenarios. Better yet, since it produces a full fidelity drawing, like AutoCAD for example, the XML output can be used to code generate the solution in minutes compared to months of manual labor programming time.

I would like to thank Jim Bowyer, BizTalk guru extraordinaire, for bringing this to my attention.  I have forgotten about the bozo bit. 10 years ago, I read an excellent book by Jim McCarthy called, The Dynamics of Software Development.  Jim sent me an article called, Un-Dynamics of Software Development, or, Don't Bite the Flip Bozo by Paul Kimmel that references McCarthys book, specifically the bozo bit.

Flipping the bozo bit means to make a mental note that a particular person is a bozo and everything they say in the future should be ignored or looked upon as the meanderings of a slightly annoying, occasionally amusing child or a drunken uncle.

 

Paul then goes on to write about Software Development Truisms:

1. It is still the Wild, Wild West out here and anything goes.
2. When someone says the schedule is going to be missed, they are never lying.
3. Change is a constant, but people will seldom thank you for changing their code.
4. A lot of bad software is being written by people who don't read.
5. People believe too much of what they read.
6. Authors are not smarter than the rest of us; they just read more.
7. Managers should not make technical decisions, but do.
8. If a manager says I am not technical, be prepared to spend a lot of time explaining things to them so they can make decisions they shouldn't be making.
9. Managers hire experts and ignore them all the time.
10. Messengers get shot more often than not.
11. Leaders have to lead; sometimes you will look behind you and find that someone is actually following.
12. You are the best programmer.
13. Programmers hate to read another programmer's code; if they volunteer to review your code, it is not to do you a favor.
14. There really are programmers ten times faster than everyone else.
15. Every man is in some way my superior, as long as he doesn't keep reminding me.
16. Programmers are emotionally attached to their code, but never say this out loud.
17. Many programmers are intellectual bullies and egomaniacs.
18. Everyone talks about constructive tension but doesn't want you disagreeing with them.
19. Benevolent dictators build the best software.
20. Decisions are, more often than not, emotional.
21. The mean time between the time you start speaking and someone flipping the bozo bit on you is ten seconds.

 

Some of you may think this is funny in a Dilbert kind of way.  Others may think this is cynical.  After being in the industry 15 years, I can tell you it is all true.  I am especially fond of this quote from Pauls article, Ultimately, software engineers will have to be licensed, but I hope to be retired before that happens

An unpleasant scene from Cool Hand Luke, but also represents the sorry state of our software industry is in today.

 

Here is a pictorial example of what I am talking about which represents software design at its finest:

 

 

Even the customer could not explain what s/he needed.  Whats wrong with this picture?  Even though it is something as trivial as a swing on a tree, everyone has their own ideas as to what the words mean because we dont have a way of visualizing what the software should be.

 

Had the customer drawn the picture, rather than describing it with words, which is what we usually do in gathering software requirements, then the outcome may have been different.  In fact, that is the key.  Look at the picture again, everyone knows what the customer really needed.  So whats wrong again?

 

The current state of the art in software engineering has us describing customer virtual requirements using words.  Even worse, once we have the words then software designers (architects, programmers, whatever) use highly specialized drawings that mean nothing to anyone but the person who drew it.  We cant even share some of these drawings with our fellow programmers because even they may misinterpret the drawing depending on the dialect and that persons training for that language.

 

What the software industry needs is a way to draw software so that all of the participants can understand the picture.  What that looks like, I dont know, because it has not been invented yet.

So why do we throw software together as described in the previous post?  Aside from our software industry being very young, we still have no way to visualize the size and complexity of any computer software.
 
Think of it this way, building architects use blueprints to visualize and construct buildings. They are full fidelity drawings that describe the size and complexity of any building structure.  Even a person that cant read blueprints can easily distinguish the size and complexity difference between a house and the Empire State building.
 
Yet, in software, nothing like this exists today. We are still at such a low level of abstraction that even professional programmers have a difficult time envisioning software architectures (i.e. the size and complexity of the software structure that we are to design and construct) let alone trying to explain it to someone non-technical, like a customer who cant understand why his/or her software is going to cost so much and take so long to design and build.  If we could show them a blueprint that they could understand...
 
Software seemingly defies the laws of physics as it is all virtual.  That it is why it is imperative for our industry to develop higher levels of abstractions as discussed in David Frankels excellent article, Software Industrialization and the New IT. 

 

We need an AutoCAD like tool for designing software blueprints.  If we can draw the software architecture in full fidelity, similar to any other engineering CAD drawings, then we are getting closer to moving our industry out of the dark ages and into the 21st century.

 

Then maybe we can apply some software engineering techniques as we have a real way to model software instead of the hammer and chisels we now have.  AutoCAD revolutionized the engineering design industry with a Computer-Aided Design (CAD) package in the mid 1980s.  I wonder who is going to invent this for the software world?  And when?

Someone asked me the other day why the need for software industrialization and to give an example of whats wrong.  Here is one trivial example.  I have a new washing machine that is run by software.  Fully programmable!  The user interface is interesting, but that is another topic of discussion.  Here is the problem, once it is all finished it beeps at me every minute with three beeps.  It seems that I need to actually hit a button to say that machine, you are all done.  Ridiculous!

 

So I decided to see if I wait long enough, it will just shut off by itself.  So I let it go for an hour listening to its 3 beeps every minute for an hour.  Thats 180 beeps.  OK, maybe I aint so bright, but I just about took my sledge hammer to the thing to shut it up.

 

I looked in the owners manual to see if this is normal behavior.  First of all the owners manual is 27 pages!  Its a washer, how complicated can it be?  Next under a section called Acoustic Signal was the magic key combination to turn the sound off.  Of course, would have never guessed this without reading the manual.

 

And thats the point of why software industrialization, its a frickin washing machine!  How many millions of washing machines have been designed and produced over the years and I still need to read a manual for one?  Why cant there be just one button that says Start or Go!  Thats a feature I want in my next washing machine, but it seems its going to take a software revolution to get this one feature.

 

Oh, by the way, my stove timer does the same thing it does not automatically turn off, I actually have to go over and click cancel (with my finger) or it beeps three times every minute.  Now where did I put my sledgehammer

I came across this article, Software Engineering, Not Computer Science while researching Software Industrialization, the subject matter of this blog site.  Steve McConnell has written many good books, most notably, Code Complete.

 

Steve asks the interesting question, "should professional software development be engineering?"

 

Good question and I am sure the debate will continue for years.  Even though I am a firm believer of engineering practices, I believe that our industry is still too young to have developed any real solid engineering practices.  Even today, I feel like I still am using a hammer and chisel to develop software the tools suck and it is going to take forever.

 

So what about all of the modern methodologies and practices?  Well, my training in software engineering still defies what I do in my day job.  It is more akin to this approach:

 

"Absolutely the only way I know to succeed with an innovative product is to throw something together quickly, push it out the door, persuade some lunatic early-adopters to start using it, and then rapidly evolve it on a quick turnaround cycle based on market acceptance and driven by a wish list from actual users.  Every successful product I have been involved with, either as a developer or as a user, seems to have followed this path."  From John Walker, inventor of AutoCAD.

 

John calls this, old time engineering philosophy. However, I still do it everyday, even though I am thoroughly trained in software engineering I end up always throwing stuff together.  Why is that?