I was at a meeting Wednesday with a bunch of really bright software architects discussing the concept of what engineering discipline most resembles software development.   We used home building as our most common point of discussion, and the debate got pretty heated.   The speaker – Jesse Tilly – was trying to convey to us that software unlike physical construction, takes place in a virtual world.  With abstract concepts, systems modeling, and eventual system construction the developer will develop an entire working system that the end user will never be able to touch or feel.   Systems are often responsible for moving, or manipulating data, making calls to other abstract systems in which some form of business logic is applied, or are responsible for controlling a physical component.    In most cases this is just a matter of transferring or manipulating 1′s and 0′s, and because of this and a “development environment” the software developer can often take many chances during the construction of a system that the physical engineer cannot.   Jesse at one point used the phrase, “how many times have you tried something to see if it worked.”   The answer of course is often, because when I or any other developer tries something to see it’s merit or validity, money isn’t wasted – unless tried in production – which is often avoided.

With good version control, it’s trivial to roll back to before something was tried.   To contrast this with a physical engineer; If Aerospace engineers decided to simply try something on a test flight, the pilot might end up meeting his maker sooner rather than later.

Well this did not sit well with a few of my fellow architects.   Mostly those that view what they do as a bit more like physical engineering than it really is.  I love software design a great deal so don’t get me wrong there.  Our systems are vital in our society, as they control everything from an MRI machines and Titan Rockets to your Microwave.   But with that said, with a few exceptions our discipline typically does not deal with the physical world.

Our most pressing issue is money.   How much is this going to cost?  How can I do it cheaper?   What’s the shortest and quickest way to get to point B?   This driving force of software development, I think was the point most missed in our meeting Wednesday.   In software development today, 90% of the time it is run by business decisions and not engineering principals.  So often times the cost benefit analysis overrides peer reviews, and proper techniques.

I think the largest reason for this, is because of the inflexibility of our current most widely used software construction methods.   The stakeholder would fund the project, higher the participants, be involved in the initial requirements studies, then go away for months and sometimes years waiting for the final delivery.   Often times during that project time line, the requirements would change, people would move off the project, and the initial understanding of requirements would be lost anyway.   The most common method still in use today is the waterfall method.  This method is one software engineers have borrowed from the physical engineering trade; think blue prints, plans, concrete, steel, wood, etc.   In the physical world, teams of engineers or architects, get together, design what it is they are going to build, plan out the steps to build it, then allow the construction teams to go to work.

Why does this work in the physical world?  This works because those involved are dealing with concrete ideas, and scientific laws and theories.  The requirements for a car are straight forward.  Does it run?  Does it carry passengers.   What about an airplane?  Does it fly?  Does it carry luggage?     Not to minimize the design and creation of these two products but in both instances even though people are the final consumer of these items, most of the time their input is the least important.   Take a car for example, the job of the driver is to turn left and right, to break, to accelerate and decelerate, and to control the radio.   While that is going on, thousands of parts are involved in making that car go where the driver wants it to go, by compensating or dealing with the laws of physics.

However in software design it’s all about people.  Now I realize I said earlier that a person cannot physically touch the end product of software design.   While this is a true fact, software does interact with people on a different level.  It’s all about guessing how a user will think and anticipate how they will most likely interact with the final product.    This is a lot harder, than any physical construction portends to be, and is an ongoing process. How do you as a software designer, or programmer anticipate how someone will think.   If your user base is more than 1 user, you opinion base grows.   You could code a screen one way and user A would be extremely happy, but user B would be turned off, and possibly move on to another choice.

This leads us to the questions that Software Development is asking today.   How do we get User A and User B, along with the stakeholder to be more involved in the final product? How do we generate a system that is closer to the requirements at the time of delivery?  How do we continue to encourage the stakeholder to continue funding?

Enter Agile.

To Be Continued…..

Advertisement