Brian On Software

In Ten Simple Tips To Become A Valuable Software Professional, I listed “reading literature on various aspects of software engineering” at the top of the list. As you may probably know, our profession is pretty young compared to the other more traditional engineering fields as building engineering, electrical engineering and mechanical engineering. According to history, the term software engineering was popularized by F.L. Bauer during NATO Software Engineering Conference in 1968.

Exactly 40 years have passed since that conference was held in Germany and practitioners are still saying that software engineering is a pretty immature field and, unfortunately, displays a bad image as one of the major engineering branches. In the first page of the now popularized 1995 software engineering CHAOS Report from The Standish Group, a reason is given which supports the previous affirmation:

One of the biggest reasons bridges come in on-time, on-budget and do not fall down is because of the extreme detail of design. The design is frozen and the contractor has little flexibility in changing the specifications.

However, in today’s fast moving business environment, a frozen design does not accommodate changes in the business practices. Therefore a more flexible model must be used. This could be and has been used as a rationale for development failure. But there is another difference between software failures and bridge failures, beside 3,000 years of experience. When a bridge falls down, it is investigated and a report is written on the cause of the failure. This is not so in the computer industry where failures are covered up, ignored, and/or rationalized. As a result, we keep making the same mistakes over and over again.

There’s no doubt that that statement is still true: today’s software systems are much more complex to design and build than ever before. But then again, just like Jeff Atwood so properly stated, God didn’t invent x86. The laws governing physics in our planet are perfect. I can not say the same for the laws governing software engineering. I doubt whether we are going to achieve success from projects to projects unless we take time for ways to improve the way we design and deliver software. Nowadays we have to take into consideration many factors which comprises a software project:

• Constantly evolving technologies which we have to familiarize ourselves with (from COM/COM+ to .NET for example)
• Constantly changing requirements from stakeholders who seldom have a clue of what they want, even less of what they need in the first few iterations (typical)
• Pressure from the marketplace to constantly ship early, which increases the chance for bugs to make their way in the code (which proves Guy Kawasaki’s thought that in the software market, we ship and then we test)
• Dealing with social and cultural factors as more teams are composed of different people from around the world, each with their own unique personality, belief system, education and “professional ladder system”
• Evolving hardware that our software needs to support (by hardware, I don’t mean just computers or mobile devices, but think about automobiles, airplanes, autonomous unmanned vehicles (AUVs), medical devices, etc.)
• Familiarizing ourselves with heterogeneous software processes and methodologies when a company merges with another one (typical too).

My guess is that it will take many years, if not decades, before we see any improvement in each of those points above. And if Brook’s “Silver Bullet” theorem turns out to be a real prophecy (it hasn’t failed so far), then we better hold on to our keyboards and continue to find improvements to these problems, because just like our planet’s environment, our field is going to become a dangerous zone to live/work in…unless we do something about it. And you know what? There are many realistic solutions to such problems, and lots of them are waiting to be unfolded by people like you and me. I strongly believe that such solutions are being found in books and other literature in which professional individuals took some time in their lives to explain the problems and provide solutions to those problems in order to make our profession a better work environment for all. Not everything in software engineering is 100% about .NET, Java, TDD, Web application, SOA, software patterns, testing or software quality. In fact, according to Wikipedia’s definition on software engineering:

The discipline of software engineering includes knowledge, tools, and methods for software requirements, software design, software construction, software testing, and software maintenance tasks.

Software engineering is related to the disciplines of computer science, computer engineering, management, mathematics, project management, quality management, software ergonomics, and systems engineering.

The same is true for the other branches in engineering: not everything revolves around tools and technologies. In one of my engineering course, a professor once told us that engineers praise the Pareto principle (also known as the 80-20 rule). One instance of that rule is that for any engineering profession, in most cases, 80% of a project revolves around human interactions and only 20% is concerned about tools and technologies. Some even think that the actual rapport is 90-10. Nevertheless, we can agree that even in software engineering, human interactions and relationships have the upper hand in most software projects.

Going back again to the CHAOS report, the researchers discovered that three major reasons that a project will succeed are:

User involvement

Executive management support

Clear statement of requirements

According to them, “there are other success criteria, but with these three elements in place, the chances of success are much greater. Without them, chance of failure increases dramatically“. The following table shows what survey participants answered when asked about the factors that contribute the most to the success of a project:

These same survey participants were also asked about the factors that cause projects to be challenged.

Figure 1. My technology-oriented books collection (.NET, Java, PHP, Perl, OO, etc.)
 

All these results show that human-based decisions and interactions are much more important than knowledge of a technology when determining the success of a project. And as such, I urge software professionals to read books and literature beyond those that are technology-focused. Reading books about .NET, Java, EJBs, or other technology-focused subject is good for your current project or job (short-term) but not that great for your professional ladder (long-term) because technology changes so drastically in such a short time that we have to keep up with the new bits and bytes, whereas reading materials that focus on principles tend to be technology-independent and longer lasting.

That being said, I recommend books that deal about leadership, personal development, teamwork, business, economics, different cultures from around the world, etc. My favorite book of all is the Bible because it is a collection of 66 books that touch base with all those human-oriented subjects. A library of one book…simply amazing! But there are also other books which I highly recommend if you’re serious about becoming a better developer and more solid software professional. Figure 1 shows the technology-oriented books in my library which I have read and have been a great help in my projects…but I haven’t developed with COM/COM+ in over 5 years! I don’t even remember the last time I compiled a C++ application. I keep those books mostly to show novice programmers what was the world of development before .NET, but other than that, I don’t have much use for them. On the other hand, Figure 2 shows the books in my library which deal with human interaction and personal development. These books I have read and re-read many times. They have helped me in the job and outside the job as well. They have helped me to grow as both a professional and as an individual. Rare is a software project that is being built by just one single individual. Even open source software project involve multicultural individuals from all around the world. Trust me: technology is not the primary factor that will bring success to any software project. It will never be. People is the factor that makes the difference whether a project will succeed or not. Software is built by people and for people. Even operating system software and real-time software aren’t primarily built for hardware…they’re built for people. Knowing how to deal with people, even outside your organization, is the cornerstone of any software project independently of its criticality and scope. So next time you’re visiting Amazon, think twice before buying another popular .NET, Ruby or Java book and rather consider purchasing a book that will help you grow as an individual and make you a much better software professional.  

Figure 2. My human-centric books (personal development, business, leadership, etc.)

As you can see from both pictures above, my human-centric books only require one shelf, compared to two shelves for my technology-centric book (I might even need a third shelf as I’m starting to stack one upon another). You don’t need as much of these human-centric books. Just a handful is plenty enough. My favorite authors of such literature are Seth Godin, Guy Kawasaki, John Maxwell and Malcolm Gladwell. Three out of four of these authors maintain an active blog which you can access publicly at no cost.

But please, dear reader, don’t misunderstand me on books focused entirely on technology. I’m not saying they’re not worth it, quite on the contrary. They are excellent for reference on a very specific topic, but their scope is very narrow. There are two excellent resources which I recommend to software engineers who are looking for better ways to improve themselves and their profession:

• The Guide to the Software Engineering Body of Knowledge

From Wikipedia:

The software engineering body of knowledge is an all-inclusive term that describes the sum of knowledge within the profession of software engineering. Since it is usually not possible to put the full body of knowledge of even an emerging discipline, such as software engineering, into a single document, there is a need for a Guide to the Software Engineering Body of Knowledge. This Guide will seek to identify and describe that subset of the body of knowledge that is generally accepted, even though software engineers must be knowledgeable not only in software engineering, but also, of course, in other related disciplines.

• The ACM/IEEE’s Software Engineering Code of Ethics and Professional Practice

The Code contains eight Principles related to the behavior of and decisions made by professional software engineers, including practitioners, educators, managers, supervisors and policy makers, as well as trainees and students of the profession. The Principles identify the ethically responsible relationships in which individuals, groups, and organizations participate and the primary obligations within these relationships. The Clauses of each Principle are illustrations of some of the obligations included in these relationships. These obligations are founded in the software engineer’s humanity, in special care owed to people affected by the work of software engineers, and the unique elements of the practice of software engineering. The Code prescribes these as obligations of anyone claiming to be or aspiring to be a software engineer.

I’ll end this post with a powerful statement from the CHAOS report as they conclude their report:

There is one final aspect to be considered in any degree of project failure. All success is rooted in either luck or failure. If you begin with luck, you learn nothing but arrogance. However, if you begin with failure and learn to evaluate it, you also learn to succeed. Failure begets knowledge. Out of knowledge you gain wisdom, and it is with wisdom that you can become truly successful.

That wisdom you also gain it by learning from each other: from your team members, your customers, your managers, your employees, and others. An easy and quick access to such wisdom is also in taking some time in reading human-centric books over technology-focused books. It worked for me…no doubt it’ll work for you.