Failure’s Enemy May 18, 2006Posted by Zach Hendershot in licensure, software engineering.
Failure, as a Swiss study pointed out in a previous post, in physical engineering is found to be statistically caused by a few primary factors: insufficient knowledge, underestimation of influence, and ignorance or carelessness. After looking at studies like this I would imagine that professional engineers got together one day and decided that something must be done to ensure that they mitigate as many of these factors as possible. Their solution to the problem was licensure. From the NCEES:
"The [engineering] profession regulates itself by setting high standards for professional engineers, and by law, many jurisdictions require engineers to be licensed in order to practice. These requirements and high standards help protect the public's safety and welfare. Licensure is the mark of a professional. It demonstrates accomplishment of the high standards of professionalism to which the engineering profession subscribes."
I think one of the key points that stand out in my mind here is: "These requirements and high standards help protect the public's safety and welfare." While it is very true a physical engineer must keep the public's safety in mind during every phase of design, I would argue that software engineers must also be increasingly aware of ways to increase safety and security. If you think about the daily news reports of identity theft and security breeches across the country, most of which involve thousands and sometimes millions of dollars of damage, you begin to get an idea of what we are up against. These are almost always a result of the software designed to protect that data and information being flawed. Additionally, software engineers involved in embedded design (especially industrial control) often truly have to design and and prepare for human safety.
All of this leads to one conclusion, or actually one question: "Is licensure for us?" Well, I think in the past we've made a half-hearted attempt at licensure with things we call "certification". While for some industries and companies certification is good, it give the HR department a warm, fuzzy feeling because it's something that they can quantify and touch and lean back on. However, I don't think it goes far enough. In some industries (namely the financial, health-care, accounting, etc. industries) I think that it should be required, maybe even by law, to have demonstrated a comprehensive understanding of secure programming techniques, sound programming skills, and ethical behavior. The test should not be designed to focus on the person's technical ability but their methodology. In today's software industry technology comes and goes. I would be much more interested in a demonstrable commitment to their field and its techniques than how well they know their Java language constructs.
No matter how well trained and prepared any engineer is for solving a problem, failure is a fact of life. Physical engineers have had many years to experiment and document their failures, but we have had comparably very few. Jeff Atwood over at Coding Horror has a very interesting take on failure in our field. "If you forget how easy it is to make critical mistakes, you're likely to fail." With this, he means that we should be very aware of our failures and sometimes even obsessed with them. And I agree. In a future post I want to talk a bit more about failure and how we can learn from it.
What causes failure? May 16, 2006Posted by Zach Hendershot in physical engineering, software engineering.
add a comment
In the last post, I talked about the hunter and the rational need to solve his immediate problems. He needed to cross the river so that he could feed his family. The reason was simple, but the effects were not so simple. Without much formal training in structural engineering he forged ahead and devised a workable solution to the problem. It met his immediate needs. The problem arose when his circumstances changed. He was unable to return across the bridge with the additional weight of the fruits of his labor. In retrospect, if he had chosen his materials and design a bit more carefully his return trip might not have been so disastrous. I think that this situation is played out in software engineering every day. We often design solutions to meet OUR needs or, more specifically, we supplant our needs over those that we think are our customer's needs. It is so easy for us to do this because our medium is so mutable; we like to stay agile and quick to change. Many advocate that this is our strength as software engineers. "We can solve people's problems faster and more efficiently than ever before," people say. While from a business perspective this often is desirable, there are many companies that live and die by selling software before it exists with the mantra: "If we pitch it, they will come." Because we can build the software so quickly, this often works (in the short term.)
- 36% – Insufficient knowledge
- 16% – Underestimation of influences
- 14% – Ignorance, carelessness, negligence
- 13% – Forgetfulness, error
- 9% – Relying upon other without sufficient control
- 7% – Objectively unknown situation
- 1% – Imprecise definition of responsibilities
- 1% – Choice of bad quality
- 3% – Other
After analyzing this data, it seems to illustrates the fact that the causes of failure in physical engineering seem eerily similar to failures that we see in the software world. I think that every one of the above items can be seen as the cause of some failure in almost every software shop in the world. With this in the back of your head, I think that in the next post it would be very interesting to discuss the physical engineer's solution to this problem: licensure.
From the Physical to the Non-Physical May 15, 2006Posted by Zach Hendershot in physical engineering, software design.
1 comment so far
More than 4,500 years ago one of man's most important contributions to the world was born: engineering. Every year since important insights were gleaned and lessons learned. Sometimes through recorded history the efforts were far from a success. However, all of these lessons learned have culminated and grown into arguably one of the most successful sciences the world has ever known. Everyday around the world billions of people use the buildings, bridges, ships, and other physical infrastructure designed and produced by engineers. Every single one of these examples of physical engineering build upon thousands of years of experience and knowledge. Consequently, when somebody walks or drives over a modern bridge spanning a 100 foot deep river there is no second thought as to whether it will hold your weight; we take its design and structural soundness for granted. To be sure, it was not always this way. Imagine for a minute the first time that an enterprising hunter was faced with crossing a rushing stream to, no doubt, continue his hunting in a more bountiful forest. Being as resourceful as possible, he notices a large tree near the bank and determines that if he cut it down it would easily reach the other bank. He toils for hours to finally chop the tree down and finds that it does indeed easily span the river. Much delighted, he continues his hunt and is rewarded justly with an abundance of food. Understandably, he is quite pleased with himself until he rounds the bend on his way home and finds his makeshift bridge. It is getting late and his children are getting hungry. He decides to take a risk and starts to walk carefully with his heavy bounty from the day across the tree trunk. It's not long until the weight is too much for the tree and it cracks loudly underneath the hunter, sending him plummeting into the river below.
I think that there are very important and fundamental parallels between the histories of physical engineering (those disciplines encompassing civil engineering, mechanical engineering, and the like.) and software engineering. While physical engineers have had several millenia to learn from their mistakes, software engineers have had a mere 50 years. I want to liken the hunter's primitive solution to solving his problem to our attempts at solving a similar fundamental problem: meeting all of our user's needs. There is much to learn in the study of the history of physical engineering; many ideas and lessons are found that can benefit a software engineer today. I want to analyze and discuss these lessons and how they affect modern software design. Immense progress has been made in our profession the past few decades, but I hope that with a fresh perspective we can focus our progress into solutions that not only solve problems but change the way people work.
I started this blog to give me a medium to discuss the ideas that will define our science in the coming years. I see a very important shift on the horizon and I find it very exciting that we all get to be part of it. With the advent of the Web 2.0 companies and the continual redefinition of how we use the web, and how we get things done on a day-to-day basis, there is a renaissance of ideas and solutions. Some may define this as just a second dot-com bubble. I think that it might just turn out to be a bit more deeply rooted than that. Lets see what happens.