Brian On Software

I first heard of the Broken Windows theory while reading Malcom Gladwell’s The Tipping Point.  In a nutshell, the theory goes like this:

If a window is broken and left unrepaired, people walking by will conclude that no one cares and no one is in charge.  Soon, more windows will be broken, and the sense of anarchy will spread from the building to the street on which it faces, sending a signal that anything goes.

I couldn’t help myself thinking how this theory fits well with the current state of software development.  When a software project first begins, it is void of any imperfection for no one began to write a single line of code for it.  Then as the team forms and the tasks are being assigned and executed, the team members start to breath life into the software.  That software could have a very different life depending on various factors of the team in charge of developing it, such as the team members’ experience, skills, knowledge, professionalism and passion for the craft. 

From my days of consulting and working as a team member, I more than often see a lack of responsibility from the individual team member for the most important organ of the software: the source code.  Once the source code has started to rot, it doesn’t matter how colorful or beautiful your design documents are or how detailed your development plan is…your software has a cancer and it will die unless you do something about it.  The typical scenario of the Broken Windows theory in software development goes like this: Robert, a programmer, is working on a subroutine for the Shipping module.  While at it, he notices that the NotifySupplier method is lacking a couple of guard clauses and the comments don’t reflect the code at all.  Since he wasn’t the one to write that code, he ignores it and continues working on his work item.  Will he remember to ask the developer who wrote the NotifySupplier method that it is in need of some fixing?  Who knows.  One meeting here, one phone call there, and chances are that Robert will forget about it.  Upon that time, the software has started to confirm the theory.  It now has a broken window.  What’s even more dangerous is that this theory can cascade all over the core of the software if its internals show a high degree of coupling with many components.  A good analogy would be like a tree burning in a forest.  It doesn’t take much time for the fire to spread to the other trees.  The outcome of this is simple: chaos.  The remedy is also simple: you.  What are you going to do about it?  Are you going to run from it or are you going to take corrective actions to prevent the cancer to spread all over the system?

Another potential risky situation that may arise from the Broken Window theory in software development is that if you don’t take care of fixing the broken code as soon as humanly possible, your junior developers and interns (if you have any) will have the impression that all this is normal in our industry.  The result of this is that as they continue to build and ship software in the future, those junior developers and interns will have shipped products with broken windows in them.  The theory can also backfire on your organization as the developers, sooner or later, realize that the organization isn’t mature enough and might decide to work somewhere else that will provide them the proper environment to appreciate the craft of building software and pay attention to the smallest details.   Here are a few examples of what I consider a broken window in the code and that should get fixed as soon as possible:

• Missing unit tests
• Comments out-of-sync with the target code
• A method, class or module that should be refactored
• A complex piece of code that could be replaced with a design pattern to better express its intent
• A broken build
• Etc.

There are also some solutions to prevent this theory to hinder the software project:

• Performing code reviews at least once a week
• Encouraging pair programming, as four eyes are better than two
• Putting in place automated tools that will break the build when rules are broken (FxCop, NDepend, NCover, etc.)
• Having the programmer check in her modifications in a private build such that if it succeeds then the modifications are merged to the repository.  Have a look at Team City for it does that very well.
• Providing intelligent tools to your developers so that they can work more effectively with the codebase.  A tool like ReSharper quickly comes into mind.
• Instilling an atmosphere that considers quality as the most important instrument to drive the organization to success.

But the tools and processes aren’t the heart of the solution.  What will either make or break the software is the attitude of every single individual affected to the project.  To encourage the growth and maturity of this attitude, developers should educate themselves on the trends of software development.  Developers should constantly thrive to do as much as possible to become more valuable software professionals.  

Though he doesn’t talk about this theory explicitly in his book, Agile Principles, Patterns, and Practices in C#, Robert C. Martin does reflect on the basis of the Broken Windows theory and also does provide a remedy to fight this problem in software.  According to him, and I agree with his statement, it’s all about having an attitude of being professional:

The attitude that agile developers have toward the design of the software is the same attitude that surgeons have toward sterile procedure.  Sterile procedure is what makes surgery possible.  Without it, the risk of infection would be far too high to tolerate.  Agile developers feel the same way about their designs.  The risk of letting even the tiniest bit of rot begin is too high to tolerate.

The design must remain clean.  And since the source code is the most important expression of the design, it too must remain clean.  Professionalism dictates that we, as software developers, cannot tolerate code rot.

Remember: Only YOU can prevent broken windows in your software project from spreading like cancer.  You have access to a grand vast of online resources and tools to help you fix those broken windows before it’s too late.  Do you have the attitude to do as such?

If you’ve been reading my blog for a while, you no doubt know that I’m a fan of the IEEE Computer Society. 

I like working with .NET development tools and other technologies, but what I really, truly love in this profession is the engineering aspect of software development, such as requirements gathering, process analysis and assessment, software analysis and architecture, software quality, testing, project management, agile methods, etc. 

I think that in order to become a valuable software engineer for any organization, an individual in this profession should focus 80% on those core areas and 20% on technological areas (such as .NET or Java development, design patterns, SOA, web-oriented technologies, development and productivity tools, etc.).  In other words, you should try to become a generalizing specialist on core areas (the 80%) that I’ve mentioned in the second paragraph and a specialist on one or many of the technological areas (the 20%) mentioned in this paragraph.  For obvious reasons such as outsourcing and open competition amongst employees, having this kind of profile is key to ensure opportunities growth and career development at a minimum.

That being said, the IEEE Computer Society is a great source of information that does its best to focus on the core areas as previously mentioned.  But in case you weren’t aware, the IEEE Computer Society is big…really big.  In fact, it groups over more than a dozen other branches related to computer technology and engineering.  As such, it has recently launched a cool website which publicly offers great content on software engineering core areas.  This new initiative is Computing Now which is, in a nutshell, a public repository which aggregates content of all IEEE Computer Society magazines (IEEE Software, IEEE Multimedia, IEEE Internet Computing, etc.) and more!  According to their site,

Computing Now aggregates new print and online content from the IEEE Computer Society’s 14 peer-reviewed magazines into one website. Each month, we highlight cross-magazine coverage of hot topics such as robotics, green computing, and social networking. Check back often, because we’ll also be posting free articles and departments as each magazine goes to press. Participate in our From the Editors blog, and discover or subscribe to magazine-related multimedia content, such as news, podcasts, audio interviews, code snippets, and video demonstrations.

I was reading an interesting article in The Globe And Mail this week about how more and more managers are getting laid off their positions in the corporation due to the economic situation we’re currently in.  This affliction doesn’t affect the IT industry alone; it’s striking almost every companies in every sector in every country.  In order for workers in management to increase their stakes at keeping their current job or getting more attention for further opportunities, there are a few key points that should be considered.

In the Management Survivor Guide, Monika Morrow of Right Management points out a few ideas to make yourself more profitable and valuable.  Since this article pretty much goes in hands with my post on how to become a more valuable software professional, I thought that Morrow’s article would be a good complement to it.  So, without further a due, here’s the “Management survivor guide” which aside from targeting managers can actually benefit software professionals alike.

The Management Survivor Guide by Monika Morrow of Right Management:

• Position Yourself
  Scan the organization and the industry and make sure you are involved in an area that is hot and growing.

• Think Strategically
  Discuss the organization’s strategy with senior executives and point out how you fit their coming needs.

• Build Your Skills
  Don’t wait until the company offers training – stay on top of tech and management trends with courses and online learning.  (Check out my post on personal and professional development through reading for another take on this one)

• Be Multitalented
  If two operations are being combined, a manager who knows both parts will be more valuable than one who has experience in only one part.

• Get Advice
  Ask trusted colleagues or a coach to critique your management style and experience for areas where you might need development.

• Market Yourself
  Develop and tell stories of your successes.  You want to be known as the problem solver too valuable to let go.  (I highly recommend reading Jean-Paul Boodhoo’s blog to get an example of this point.  JP clearly nails this one as he constantly shares his successes publicly on his blog)

• Be Seen As An Authority
  Offer to mentor, organize training and speak at industry functions.

• Don’t Rush
  If it becomes clear you are facing the axe, don’t just take the first job that comes along without assessing whether it meets your interests and long-term goals. (This one is very important in my opinion.  Don’t waste your time on a job that isn’t compatible with your values and dreams.  If you are in such a situation, I also recommend you to read The Dip by Seth Godin.  Seth gives you some key points to consider in such situations)

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:

 

Project Success Factors	% of Responses
1. User involvement	15.9%
2. Executive management support	13.9%
3. Clear statement of requirements	13.0%
4. Proper planning	9.6%
5. Realistic expectations	8.2%
6. Smaller project milestones	7.7%
7. Competent staff	7.2%
8. Ownership	5.3%
9. Clear vision & objectives	2.9%
10. Hard-working, focused staff	2.4%
Other	13.9%

 

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

 

Project Challenged Factors	% of Responses
1. Lack of user input	12.8%
2. Incomplete requirements & specifications	12.3%
3. Changing requirements & specifications	11.8%
4. Lack of executive support	7.5%
5. Technology incompetence	7.0%
6. Lack of resources	6.4%
7. Unrealistic expectations	5.9%
8. Unclear objectives	5.3%
9. Unrealistic time frames	4.3%
10. New technology	3.7%
Other	23.0%

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.  

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.

I have been an IEEE member and an IEEE Computer Society member since 2003, the year I started my undergraduate studies.  From 2003 to 2007, I have been a Student Member, and since graduating, I have been a Professional Member.  The main reason I decided to join such an organization as a student was simply because I wanted to have one foot in the academic world(what I prefer to call the ‘perfect world’) and another foot in the industrial world (what I prefer to call the ‘real world’).  Being a student member of the IEEE Computer Society also proved itself useful when I was being interviewed for various internships in the course of my studies because it ‘demonstrated’ to potential employers that I had extra interests in the field of software development and technologies.  In a nutshell, the IEEE and the IEEE Computer Society is like a sea of information that provides the latest news and information in the field of research, achievements, innovations, inventions, policies, standards that targets both students and professionals alike.

Last week, the IEEE Computer Society’s president sent a newsletter to all the members.  Immediately after reading it, I thought to myself that I should quickly write a post about it to encourage computer science and software engineering students to become members of this fine organization.  <NOTE>: I was not asked neither by the IEEE, nor by the IEEE Computer Society nor by anyone related to the IEEE to write this post.  I believe that every practical student should keep his/her eyes in the “real-world” while having his/her feet grounded in the “perfect world”.  I also believe that the IEEE Computer Society is an excellent medium that delivers high quality information on what’s going on in the industry to students, so that when they graduate, for example, they won’t feel too lost when being interviewed for some position at a company.</NOTE>

For instance, 2008 IEEE Computer Society student members will enjoy a terrific new member benefit: they can access free development software from Microsoft (as long as it is used for research or educational purpose, of course!)  Software includes Vista Business, Visual Studio, Expression Web Designer, and much more.  Student members can also participate in the exclusive annual student competition “The IEEEXtreme 24 Hours Programming Challenge“, which is a worldwide contest in which teams of student members, supported by an IEEE Student Branch, advised and proctored by an IEEE Member, compete in a 24-hour time span against each other to solve a set of programming problems.

There are also other benefits for being a member of the IEEE Computer Society, including:

• FREE access to over 1,300 online courses http://computer.org/elearning
• Cutting edge resources and computing information are available at discounts up to 50% off the non-member rate
• FREE access to 500 IT books and technical articles. http://computer.org/elearning
• Special student benefits. http://computer.org/students
• Free fully portable email alias: You@computer.org http://computer.org/webaccounts/alias.htm
• Generous discounts on registration fees for more than 170 conferences, symposia and workshops. For upcoming events review our online calendar http://computer.org/conferences
• The strength of an organization of nearly 90,000 members and 150 local chapters worldwide…can you say ‘networking’?

So how much does all this cost?  Less than 30$ a year!  If that’s too much money for one year, I suggest that you start selling those chemistry and humanities books laying around on your bookshelf.  The membership fee pays for itself since a single license of Visual Studio 2008 Professional Edition is much more expensive than 30$!  No excuse if you’re a .NET developer/student!

I’m such a fan of the IEEE Computer Society, that when I received my IEEE Professional Member sticker, I had to think for a long while where would be a good place to put it on.  A car bumper?  A fridge?  A laptop lid?  Nah.  I decided to stick it somewhere very important to me: the Bible my pastor gave me after graduating from university.  Next time I hear someone telling me that I’m a church fanatic, I can also tell him/her ‘You’re right…and I’m also an engineering fanatic!”

There were two courses, during my undergraduate studies in Software Engineering, that forever changed my perspective towards software quality: Software Quality Assurance, and Software Quality Control and Testing. The former dealt more with quality assurance and process improvement with various frameworks (CMMI, ITIL, Six Sigma, etc.). The latter dealt more with service level agreements, various testing techniques and quality control. I purposely put “quality assurance” and “quality control” in bold, because I want to emphasize both terms. There is a distinction between these two terms. They do NOT mean the same thing, and they are NOT the same thing.

As you may know, I tend to write more about software development than specifics about software engineering, but I believe that as a professional software engineer, we should use and speak the same lingo, a sort of ubiquitous language within the profession, when defining an intent, a need or a role. In object-oriented programming, we use Design Patterns to reveal an intention behind a specific design or architecture. For example, when someone says “I used the Composite pattern in this situation for X reason” or “We decided to use a Strategy pattern with an Abstract Factory to do X and Y”, it communicates design decisions across the team. Even police officers use their own codes to share their intent amongst their fellow officers. For example, they’ll use a “10-4″ to acknowledge something, a “10-15″ to inform whoever is listening that there’s a prisoner in custody. Many professions have their own codes, standards and guidelines to easily share information between their peers and facilitate communication.

A while back, I wrote a post on “Promoting Professionalism Through A Common Body of Knowledge“. If you read any body of knowledge, you’ll note that each one of them defines a vocabulary that is common to the related profession. For some reason, which is beyond my understanding, the software engineering profession tends to use and express certain vocabularies which are neither standardized nor shared across organizations nor rightfully used in a particular context. For instance, we have titles such as “Software Architects”, “Software Designers”, “Software Specialists” and “Software Analysts” which are used liberally often without knowledge of the role. The worst one is “Software Developer”. Seriously, what does a “software developer” really mean? From what I understand, it’s a catch-all term which means a lot of things. It’s the “default switch case” of software development job titles. Anyhow, that is a discussion for another post…

In this post, I want to concentrate my energy on two terms, or “job titles”, which are often improperly used in our profession. These two terms are important to differentiate and understand, because they both deal with software quality. Quality is a major player in today’s software systems: it greatly influences the economics of the team, the credibility, the reputation and the lives of the people involved in the project, and most importantly it continuously defines the professionalism in our profession. Are we just hacking things together and wishing for the best? I hope not.

In his article, “Cost of Software Quality”, Dan Houston states that:

Software quality is difficult to define because there is no single comprehensive and complete standard definition of its lexicon. Various aspects and terms are found in sources such as ISO 9000-3, IEEE Software Engineering Standards, and various books on the subject. The following are some of the various definitions of software quality.

• Level of satisfaction: it is the degree to which a customer or user perceives that a software product meets his or her composite needs and expectations.
• Product value: it is the degree to which a software product has value relative to its various stakeholders and the competitive situation.
• Key attributes (”ilities”): it is the degree to which a software product possesses a desired combination of properties.
• Free of defects: it is the degree to which a software product works correctly in target user environments, free from operational defects.
• Process quality: in relation to the development process by which the product is produced, it means good people doing the right things in an effective way.

From that definition, we can say that software quality is a composition of defects prevention and defects detection activities. By “defects prevention”, we mean a set of rules and practices that helps us to build the system in way that will minimize problems in the road ahead. In other words, it’s making sure we’re building the system right. This is what we call Software Quality Assurance (SQA). By contrast, when we talk about “defects detection”, we mean a set of rules and practices that helps us to correct, tune and free our system of problems, such as bugs. In other words, it’s making sure we’re building the right system. This is what we call Software Quality Control (SQC). Let us now formally define both of these terms:

Wikipedia defines the term Software Quality Assurance as:

Software Quality Assurance (SQA) consists of a means of monitoring the software engineering processes and methods used to ensure quality. It does this by means of audits of the quality management system under which the software system is created. It is distinct from software quality control which includes reviewing requirements documents, and software testing.

SQA encompasses the entire software development process, which includes processes such as software design, coding, source code control, code reviews, change management, configuration management, and release management. Whereas software quality control is a control of products, software quality assurance is a control of processes.

Wikipedia defines the term Software Quality Control as:

Software Quality Control (also known as Verification and Validation (software)) consists of a means of controlling the quality of software engineering products. It does this by means of tests of the software system. These tests can be unit tests, integration tests, or system tests. It also includes the formal proof of individual pieces of code, and the review of documents and code.

It is distinct from software quality assurance which includes audits of the quality management system against a standard. Whereas software quality control is a control of products, software quality assurance is a control of processes.

The main difference between these two terms were underlined in bold:

Whereas software quality control is a control of products, software quality assurance if a control or processes.

The same way that, in object-oriented programming, an abstract class isn’t the same as an interface, there is a huge difference between “software quality assurance” and “software quality control“. SQA deals more on the methods and processes we’re going to adopt to build the system. SQC deals more on making sure the system is behaving as it was meant and designed to behave.

I used to work for a company that had a QA Director. I once asked him which processes were used to develop their systems. He replied that he didn’t have a clue. I then asked him what was his role as a QA Director if he didn’t know which processes were used in the organization to develop the systems. He replied that he was responsible to manage a team that was testing the system. Had his job title be “Quality Control Director” instead of “Quality Assurance Director”, I could’ve saved myself a couple of minutes that day. There’s something else wrong with this picture. Imagine the following scenario:

Helen, who is member of the QA Director’s team, decides to leave the company to work somewhere else. As she prepares her CV, she writes “QA Engineer” or “QA Tester” as her former job title. As she submits her CV to various interesting companies she would like to work at, she patiently waits for that one phone call. But there’s a problem: the phone doesn’t ring. There might be a few reasons why no potential employer is calling her back for a job interview. Maybe, this is what happened:

Helen submitted her CV to work as a “QA Engineer” at Company X. The only problem is that Company X actually gets the difference between software quality assurance and software quality control. So the recruiter sees Helen’s qualifications on her CV, but her job title doesn’t reflect the work she was doing at her former company. Her former responsibilities don’t fit with the position she applied for. The recruiter shreds Helen’s CV and takes the next one on the pile.

Had Helen wrote “QC Engineer” or “System Tester” as her former job title, the story could’ve ended on a more positive note for her and Company X, because Helen would rightfully be describing her previous role to Company X. Let us flip the coin and imagine for an instance that Helen knew exactly that her former role was “QC Engineer”, but Company X mistakes quality control for quality assurance. In that case, Company X will miss out on opportunities to hire software engineers that really know their stuff. For example, imagine a seasoned professional SQA Engineer being interviewed for a SQA position with Company X. As the interview unfolds, the SQA Engineer realizes that Company X has no idea what SQA is all about. The SQA engineer gets up and walks way from the interview, because as a professional engineer you’re obliged, by law, to “undertake only such work as he or she is competent to perform by virtue of his or her education, training and experience“.

You might think that the previous scenario was just a single event, but in fact a simple search for “quality assurance manager” in Workopolis produced the following result (I highlighted the word “test” in the job description):

The position is clearly one for a Quality Control Manager, NOT a Quality Assurance Manager. Spreading this kind of information, this kind of evangelism, is hard because so much have been written already about SQA being about testing. For instance, software engineer Steve McConnell wrote an article in 1996, “Software Quality at Top Speed“, where he clearly states that:

The most common quality-assurance practice is undoubtedly execution testing, finding errors by executing a program and seeing what happens. The two basic kinds of execution testing are unit tests, in which the developer checks his or her own code to verify that it works correctly, and system tests, in which an independent tester checks to see whether the system operates as expected.

This statement is wrong because it is not compatible with the vocabulary defined by our profession. He’s mixing apples and oranges. Even though Steve McConnell wrote that QA was about testing back in 1996, I know that he gets it today, because you can clearly see the distinction of both terms on Construx’s Testing & QA course plan:

Software testing refers to executing software to detect defects and evaluate features. Software testing includes test planning, test case design, automated test support, and specific kinds of tests including development tests, unit tests, component tests, integration tests, system tests, regression tests, stress tests, and acceptance tests. Software QA refers to activities that assure a specified level of quality in the software, usually prior to testing.

So if you’re a SQA Director or a SQA Engineer and the only work you do is software testing, developing test plans or conduct verification activities on the system, you should revise your title. Maybe you’re more of a SQC Director or a SQC Engineer. As more students graduate from software engineering curriculums around the world, it shouldn’t be too long that someone else will ask you these questions and they’ll expect you to answer them correctly. And if you’re looking for a specific job in software quality engineering, you should be very clear whether you’re looking for a quality assurance position or a quality control position. Furthermore, you should make sure that the company you’re applying at knows the difference too.

In essence, this whole post can be resumed with these words: Software Quality Control is about testing; Software Quality Assurance is NOT.

If you want to read and learn more on the subject of Software Quality Engineering, I invite you to download the Software Engineering Body of Knowledge and check out both Chapter 5: Software Testing and Chapter 11: Software Quality (I still don’t understand why they put this chapter last).

Have you ever wonder how some intrinsic mechanisms of the C# language actually work, i.e, generics, iterators and delegates?

What about the different syntax and constraints of the C# language?

Do you want to know more about the CLI, the CTS and the CLS, and how they participate in the .NET Framework, than just being satisfied with what their acronyms stand for?

Did you know that you can learn more about the C# programming language and the Common Language Infrastructure for free?

As a matter of fact, both the C# programming language and the Common Language Infrastructure are ECMA standards which are publicly available for anyone to download free of charge. ECMA, which stands for European Computer Manufacturers Association, is an international, private standards organization for the Information and Communication Technology and the Consumer Electronics. As stated in their website,

The aims of ECMA are:

• To develop, in co-operation with the appropriate National, European and International organizations Standards and Technical Reports in order to facilitate and standardize the use of Information Communication Technology (ICT) and Consumer Electronics (CE).
• To encourage the correct use of Standards by influencing the environment in which they are applied.
• To publish these Standards and Technical Reports in electronic and printed form; the publications can be freely copied by all interested parties without restrictions.

 

The C# Language Specification standard (ECMA-334) is currently in its 4th edition, and "specifies the form and establishes the interpretation of programs written in the C# programming language". It emphasizes on:

• The representation of C# programs;
• The syntax and constraints of the C# language;
• The semantic rules for interpreting C# programs;
• The restrictions and limits imposed by a conforming implementation of C#.

Click here to download the C# Language Specification standard as a PDF (553 pages, 2.6MB)

 

The Common Language Infrastructure standard (ECMA-335) is also in its 4th edition. It consists of the following parts:

• Partition I: Concepts and Architecture – Describes the overall architecture of the CLI, and provides the normative description of the Common Type System (CTS), the Virtual Execution System (VES), and the Common Language Specification (CLS). It also provides an informative description of the metadata.
• Partition II: Metadata Definition and Semantics – Provides the normative description of the metadata: its physical layout (as a file format), its logical contents (as a set of tables and their relationships), and its semantics (as seen from a hypothetical assembler, ilasm).
• Partition III: CIL Instruction Set – Describes the Common Intermediate Language (CIL) instruction set.
• Partition IV: Profiles and Libraries – Provides an overview of the CLI Libraries, and a specification of their factoring into Profiles and Libraries. A companion file, CLILibrary.xml, considered to be part of this Partition, but distributed in XML format, provides details of each class, value type, and interface in the CLI Libraries.
• Partition V: Debug Interchange Format.
• Partition VI: Annexes – Contains some sample programs written in CIL Assembly Language (ILAsm), information about a particular implementation of an assembler, a machine-readable description of the CIL instruction set which can be used to derive parts of the grammar used by this assembler as well as other tools that manipulate CIL, a set of guidelines used in the design of the libraries of Partition IV , and portability considerations.

Click here to download the CLI standard as a PDF (556 pages, 3.2MB)

 

Other noteworthy standards that might be of interest are:

• The C++/CLI Language Specification (ECMA-372). This Standard specifies requirements for implementations of the C++/CLI binding. The first such requirement is that they implement the binding, and so this Standard also defines C++/CLI. Other requirements and relaxations of the first requirement appear at various places within this Standard. Click here to download the C++/CLI Language Specification as a PDF (304 pages, 1.57MB)
• The Eiffel Programming Language (ECMA-367). This document provides the full reference for the Eiffel language. This Standard covers only the language, with an emphasis on the implementation aspects. Click here to download the Eiffel Programming Language standard as a PDF (194 pages, 3.4MB)
• The Microsoft Office Open XML File Formats (ECMA-376). This Standard defines Office Open XML’s vocabularies and document representation and packaging. It also specifies requirements for consumers and producers of Office Open XML. The standard is available as a 5-part series and there’s also an Office Open XML overview document available on the ECMA website.

For a more detailed list of the available standards published by ECMA, check out the ECMA Standards List section.

Next time you have a job interview, a research project or a commercial project to deliver and you need to know more about the C# language and the CLI, save yourself the money and download the standards free of charge.

In my last semester at university, I had the opportunity to attend a graduate class dealing with software maintenance, taught by Professor Alain April. In case you don’t know who he is, Dr. April is responsible for creating the Software Maintenance Maturity Model (S3M). Here’s an overview of that model :

We address the assessment and improvement of the software maintenance function by proposing a maturity model for daily software maintenance activities: the Software Maintenance Maturity Model (SMmm). The software maintenance function suffers from a scarcity of management models to facilitate its evaluation, management, and continuous improvement. The SMmm addresses the unique activities of software maintenance while preserving a structure similar to that of the Capability Maturity Model integration (CMMi). It is designed to be used as a complement to that model. The SMmm is based on practitioners’ experience, international standards, and the seminal literature on software maintenance.

Coming back to the subject of this post, we had to choose a subject amongst a list of proposed subjects which would be our project for the whole semester. I decided to write a paper on my personal recommendations for improving the ISO 14764, a software engineering standard which deals with the area of software maintenance.

The objectives of this paper are twofold :

1. Identify books and articles that discuss software maintenance and have been published since 2005;
2. Provide insights or areas for improvement that could contribute to update the upcoming version of the maintenance chapter of the Guide to the SWEBOK (ISO 19760) and to the ISO 14764 standard.

My recommendations were constituted of four different ideas which could improve the area of software maintenance within an organization which deals with software maintenance (and development). Here’s an overview of the ideas I present in this paper :

1. Instilling a quality mindset to top-level management
2. Introducing agile practices in software maintenance
3. Applying key domain-driven design concepts
4. Adopting a universal coding convention throughout the organization

I have archived both the report (PDF) and the PowerPoint slide that I showed during my presentation in class (some slides have notes associated to them for more understanding, in case you don’t want to read the whole report).

Click here to download the paper and the PowerPoint slides (zip file).

I hope this kind of information will help your organization to improve its software maintenance phase. Keep in mind, that these ideas can also be applied for software development activities, not just maintenance.

An athlete doesn’t instantly compete in the Olympics simply because she pumped her Reebok sneakers. A musician doesn’t instantly play Mozart symphonies just by listening to one of his masterpieces . A general doesn’t win a war simply by watching a war movie. All these examples have an intrinsic way of dealing with self-realization and application:

• It takes time
• It takes practice
• It takes motivation
• It takes inspiration
• It takes discipline
• It takes courage
• It takes effort
• It takes concentration
• It takes perseverance
• It takes education

It takes the same energy as the examples above to become a key, valuable and respected software professional, e.g. programmer, developer, architect, tester, SQA, vendor, trainer, etc. So how do you become a key leader in the field? Are there any steps to follow? I don’t think so. However, I do believe there are tips one can consider.

Here are my ten simple tips on how to become a valuable software professional.

1. Read literature on the subject

When was the last time you read a book or an article on a specific subject related to software engineering? If you’re not in the habit of taking a piece of literature in your hands, I hope you will break that habit, because reading is a privilege that not most of us have, and it can help you grow both as a person and a professional. In Code Complete, Steve McConnell writes that the average programmer reads less than one technical book per year. Reading a book written by a pioneer like Caper Jones, Cem Kaner, Karl Wiegers or Gerry Weinberg will set you apart from the majority of beginners and some professionals, because you are learning from experts in the field and their mistakes from the past can be very valuable for your future. That doesn’t mean you won’t make mistakes! Everybody makes mistakes. This is how you become the best in the field: by trying and by failing. The question you should ask yourself is Why would I waste my time in repeating the same classical mistakes instead of preventing them? The authors I have mentioned above are pioneers in the software development field, and they have taken time to write down their mistakes and their solutions for them. There are various medium of literature to read from: magazines, books, ebooks, blogs, newsletters, whitepapers, tutorials, etc. A tip: start out general so that you can build your habit of reading, and as time goes by, you can specialize in various areas such as programming, architecture, patterns, requirements gathering and analysis, software quality, testing, etc.

2. Write literature on the subject

Share your knowledge with others by writing articles, tutorials, books, or other type of literature in magazines, blogs, etc. Sure it takes time, but the benefit of it is much greater. I took almost five hours of effort to write this article, but if it can help at least one student, one professional or one aficionado, then it is worth it. There is also some research involved in writing a technical article, so you’re still returning to the first tip: reading; therefore, you’re still learning and growing. It’s a win-win situation.

3. Attend conferences

Some are free and some are not, but depending on the scope of the conference, you will learn a thing or two. Maybe you won’t learn anything technical, but you sure will learn something about communicating to an audience. Try to make it a goal in your professional life to attend at least one or two conferences a year. Remember that speakers have a mix of experience and research when they present a topic. They took the time you didn’t have to present you something worthwhile. You can attend international, as well as local conferences. For example, in Montreal there are bi-weekly conferences on Microsoft technologies (Microsoft Visual Studio Group of Montreal), Agile practices (Agile Montreal), software process improvement (SPIN Montreal) and software quality and testing (SQPA). In any case, conferences give you the opportunity to also meet new faces and network with other professionals like you. This tip is also related to reading and writing, since you can read about the topic before attending a presentation, and then write about it to solidify your understanding and sharing your opinion with the community.

4. Attend a professional or academic class, training or seminar

I am pro education and I think every human being should be glad to have the ability to learn. If you’re a student, I say to you “Well done. Don’t give up.” If you’re a professional, I say to you “Well done. Don’t give up learning.” There is something special and worthwhile when a little group of people are sitting in a class, and learn altogether from a teacher. I agree, sometimes the teacher isn’t the best, but remember that the teacher once sat in the same seat as you did. If you don’t learn from the teacher, you will learn from the textbooks, the materials, or even better: the other students; therefore it’s still a win-win situation. I don’t care much whether it is a professional class or an academic class. I know one is more pragmatic and the other more theoretical, but you’re still going to learn something. If something is too theoretical for your taste, see if you can do some research on the subject or attend a conference on it to get a better understanding.

5. Listen to audio on the subject

There are many podcasts available on the Internet about software development, processes, practices, tools, etc. Just google for “software development podcasts”, and you’ll see for yourself. Listening, as you know, is not the same activity as reading or writing. Your brain works differently. Nevertheless, the outcome is the same: you will learn something. Now the trick is to find the time to listen to one. I suggest listening when you’re doing some physical activity, such as cleaning the house or exercising at the gym. Don’t listen when you need to concentrate mentally on something, since it’ll be harder to capture the full intent of the show. It’s like drawing a square with one hand and a circle with the other hand: it’s possible, but very hard to do.

6. Watch a video on the subject

You can also watch online videos, presentations (aka webcasts). Some presenters also use PowerPoint presentations so that you can take notes while listening. There are various topics being presented by independent individuals or corporate speakers. If there’s something you didn’t quite get, you can always rewind the video. Some presentations also allow online real-time collaboration, so that you can ask questions to other people tuned in. I sometimes take some time to watch dnrTV, which uses a Camtasia capture of the presenter’s computer to better visualize his intent.

7. Join a professional society

Joining a professional society will expand your domain knowledge with other professionals who might have more experience than you. For students, this is incredible because the fees are just a fraction of the regular price. For instance, I pay less than 30$ a year for my ACM and IEEE membership. In return, I get valuable newsletters, magazines and invitations to participate in my local chapter. For professionals, this is an excellent way to build your network. If you’re working at a company, verify if the company can pay your membership.

8. Apply your knowledge

When I first started to learn how to drive, I spend my time reading books on how to drive, how to park…basically a Driving For Dummies kind of book. But the very first day I sat behind the wheel and accelerated, it was as if I have forgotten everything about driving. You see, sometimes theory without application is null. When you read an article, listen to an audio cast or watch a presentation, take some time to apply what you have learned. You can write about it as I have mentioned above, or even teach. You’ll be amazed in discovering new things about the related subject as you do so. You can also start a new project, or even participate in the development of one (e.g., SourceForge).

9. Get certified

What a greater way to apply your knowledge than to pass a formal exam on a subject? Most respected certifications have a body of knowledge as its core basis for knowledge and understanding. Personally, I prefer going with independent certifications such as the ones from IEEE, QAI or ASQ, instead of company-specific ones like Microsoft or Oracle, because I prefer to focus on the seldom changing software principles rather than the always changing technologies or tools, but that is my own opinion. Getting certified doesn’t give you the title of Master of a subject, but it does show your competency on it. For more information on various software certifications, I strongly suggest you to visit this site www.softwarecertifications.org. By the way, the software engineering field also has its own body of knowledge in case you were wondering: the SWEBOK.

10. Have fun investing in yourself

Last but not least, have fun when learning or applying your knowledge. If you’re tired of reading or listening to something, just set it aside and do something else. I truly believe that God gave us enough hours in a day to become the most we can be in a lifetime. Remember to live and enjoy your life. Technology will come and go, even after you die. That being said, ask yourself if there’s a contribution that you can bring into this field that can help others in the future. I’m glad for people like Steve McConnell, W. Edwards Deming, Joseph M. Juran, Timothy Lister, Tom DeMarco, Cem Kaner, Eric Evans and the like who have helped me grow to become a good software professional thanks to their writings and presentations.

The software development or engineering field is truly amazing. I hope this list of tips will help your knowledge on this subject to grow.

The term ‘software engineering’ was coined some forty years ago at the 1968 NATO Software Engineering Conference, in Germany. Software engineering is a new branch in the engineering field when compared to other engineering disciplines such as electrical, mechanical, building and construction engineering. No wonder that most of the world sees the profession of software engineering as an immature and young discipline. Nonetheless, the field of software engineering is very promising. In the last forty years, there has been a large amount of breakthrough, innovation, change, improvement and research in the fields of computer science, mathematics, business, management, leadership, human behaviors, and interactions, which are all pillars that feed and support the engineering practice that we call ‘software engineering’ today. As you may or may not know, a liberal profession is more often based on failures rather than success, and as you should know, there have been many failures in the area of software engineering and development. However, most of these failures have been documented in order to avoid repeating them, but most importantly their solutions have also been documented. As I said earlier, the discipline of software engineering encompasses areas related to computer science, mathematics, business, management, leadership, etc. That being said, there are currently many roles that a person can play in a typical software project today. In fact, if you search for ‘software’ as a search criteria for an employment opportunity in Monster or Workopolis, you will see what I mean. Most popular roles in a typical software projects include software project manager, business analyst, software architect, specialist in software quality assurance, software tester and software engineer (or software designer, software developer). A good question to ask ourselves (especially if you’re involved in HR or recruitment) is “How do I know what this specific role will do and won’t do in this project?”. Another question can be “What should I expect this person to know in order for him or her to perform well at this position?”. Fortunately, some smart people have taken time to answer these kinds of questions. In fact, many of the answers can be found in what we call today a Body of Knowledge (BoK). A BoK is "…an aggregate of what is known and understood within a defined field of endeavor due to familiarity gained through experience or association." Did you know there is currently a BoK for each of the roles that were mentioned above? Yep. Today you have a BoK specific to project managers (and even software project managers), business analysts, software architects and other roles. Some of them are in their final publications and others are in draft, but regardless of their state, these BoK are constantly being improved and approved by a committee. Some of them are freely available and others can be purchased. Nevertheless, you can use them today in your own organization to clarify the expected knowledge and activities that a role must support in a project. If you already have a framework available in your organization that guides people in their specific roles, you could use these BoK to improve on what you already have. Furthermore, if you’re interested, you can also participate in developing and improving a BoK that fits with your wisdom and expertise on a specific area. Another thing you might want to know is that there are also worldwide certifications which are solemnly based on these BoK, and which can help you to not only show your expertise in an area, but also to participate in making your profession more professional. I know this is a large post, but I truly believe that taking time to download (or buy) some of the guides related to these Body of Knowledge documents and to read them (alone or in a group) can be very beneficial because not only will you be learning more about your profession, but you will also learn to embrace it and make it better. My tip when reading these kind of documents is to see what makes sense to you and your organization, what you can use, what you could improve and what you can discard to make your projects more successful and your projects’ team members more knowledgeable in their activities. I’ll finish this post with a list of common BoK which might be of great interest if you’re in the software engineering field.

• For project managers, there is the popular Project Management Body of Knowledge (PMBOK) which is regulated by the Project Management Institute. The Guide to the PMBOK is the recommended source of information to pass the Project Management Professional certification.

• For software project managers, there is the Software Project Manager Body of Knowledge (SPMBOK) which is regulated by the Quality Assurance Institute. The Guide to the SPMBOK is the recommended source of information to pass the Certified Software Project Manager certification.

• For business analysts, there is the Business Analysis Body of Knowledge (BABOK) which is regulated by the International Institute of Business Analysis. The BABOK is the recommended source of information to pass the Certified Business Analysis Professional certification.

• For software architects, there isn’t yet an official body of knowledge (as far as I know). Nevertheless, I highly recommend visiting any of these sites which are fully committed in making the profession of software architects more mature: the Worldwide Institute of Software Architects and the International Association of Software Architects.

• For software engineers, there is the Software Engineering Body of Knowledge (SWEBOK) which is regulated by the. The Guide to the SWEBOK is the recommended source of information to pass the Certified Software Development Professional certification and is available in PDF, HTML and hard cover book. I strongly suggest you to listen to the DotNetRocks show with professional software engineer Steve McConnell to have a better view on this type of certification.

• For software quality assurance specialists, there is the Software Quality Assurance Body of Knowledge (SQABOK) which is regulated by the Quality Assurance Institute and the Software Quality Engineering Body of Knowledge (SQEBOK) which is regulated by the American Society for Quality. The Guide to the SQABOK is the recommended source of information to pass the Certified Software Quality Assurance certification. The Guide to the SQEBOK is the recommended source of information to pass the Certified Software Quality Engineering certification.

• For software testers, there is the Software Testing Engineering Body of Knowledge (STEBOK) which is regulated by the Quality Assurance Institute. The Guide of the STEBOK is the recommended source of information to pass the Certified Software Test Engineer certification.

These are the most common, popular and important body of knowledge documents for each of the areas that support a typical software engineering project. Of course there are many more which haven’t been written yet, i.e., the software architecture body of knowledge, but with time and dedication, people like you and me will make this “new branch of engineering” a more solid and respectful one. Feel free to add your comments and provide links to other useful resources related to body of knowledge documents that I may have missed.

Resources:

• "Software Engineering: An Emerging Profession?", an excellent article written by David Alex Lamb which presents the current state of software engineering and where it is heading.

• Software Engineering Professional Certification Programs by Learning Tree International provides a list of other software engineering-related certifications that might be interesting for you.

I’m in the process of ending my third and last internship for the bachelor’s degree. For the last few months, I had the privilege of working for a software quality engineering firm (software quality assurance, software quality control, software process improvement, training, etc.). I never thought I would enjoy learning so much from that field and have a keen passion for it all. Before starting my internship, I always thought that software testing was for developers who couldn’t keep up with the pace of development, or weren’t as technical as they should’ve been, therefore they had no choice to accept that position to pay their bills.

Man was I wrong. Very wrong. I realized that there is much more elements involved in testing, than just pressing a record/play button. In fact, there is a lot of human and technical abilities that must be taken into consideration when dealing with software testing. On the human side, there is

• Communication (been able to talk to other testers, developers, managers and clients)
• Leadership (have the ability or responsibility to drive your team members or colleagues to reach their goals)
• Confidence (in yourself, your education and your abilities as a tester)
• Courage (to step up and say the real facts of the situation, especially before delivery)
• Wisdom (learn from your mistakes and also from other people’s mistakes)
• Intelligence (software is complex enough to know this)
• Respect (for yourself and others in the team)
• Humility (it’s okay to say you were wrong. Show this, so that other team members can be this way too.)

On the technical side there is

• Software development lifecycle
• Project management
• Best practices and methodologies (Agile, UP, TDD, etc.)
• Standards and recommended guidelines
• Software development key areas (business processes analysis, requirements gathering and management, design and development, testing, configuration and management, build and deployment strategies, etc.)

I could go on and on, but I’d stop here, because this wasn’t my intent for this post.

Oh yeah, and for the first point, quality is a major activity in architecture and development, so there’s still work to do in that area.

Ok, my intent in this post was to invite you to read an interesting article that I’ve read this morning entitled "Software Testing and Industry Needs", published by the IEEE in August 2006. It basically talks about the state of the practice of software testing in the industry, from the viewpoints of five experts in the field :

• Robert L. Glass
• Ross Collard
• Antonia Bertolino
• James Bach
• Cem Kaner

If you are a Computer Science or Software Engineering student, or even a current practitioner, and you’re curious about the field of software testing, or maybe even thought about changing careers, I strongly suggest you to read this very interesting article. I’m including some of my favorite quotes in this article, to give you a more general idea of the each respondent’s viewpoint.

Robert L. Glass states that

I actually do believe that most software testing in industry effectively meets industry needs. I base my bias on the observation that this is the computing era – an era that wouldn’t be successful without successful software – and on my belief that software can’t be successful without effective testing.

Ross Collard says that

Effective testing is a quest and, like any quest, includes intellectual challenge, passionate debate, and the excitement of discovery. Rewards for the best 20 percent of testers typically include exponential career growth, substantial monetary compensation, and wide influence. There is plenty of room for more good testers.

Antonia Bertolino thinks that

…Testing impacts the whole life cycle, because any testing technique presupposes adequate preparation, modeling, and documentation.

James Bach believes that

Industry ultimately takes care of its own practices. Each company does what it believe will work. What we need to resist – and resist strongly – are efforts to take away each company’s right and responsibility to set practices for itself.

And finally, one of my favorites in the field, Cem Kaner tells us that

Most industrial projects have many stakeholders who have diverse interests and conflicting priorities. The purpose of testing during development is to help those stakeholders understand what they’re getting, in time to correct a weak programming practice or (re)negotiate the design.

I came about this excellent list of ten common myths or suppositions about the field of Software Engineering. The list is maintained by Sahil Thaker. According to him, these are the top ten myths about Software Engineering :

1. Software Engineering is the same as Software Development
2. Software Engineering has no formal basis – it is an art rather than a science
3. Software Engineering is a well-established field
4. Software Engineering involves more testing, requirements analysis, and documentation
5. Practicing UML, MDA, Aspect Oriented Programming, eXtreme Programming makes one a Software Engineer
6. A Software Engineer is he who handles both technical and managerial issues in software development
7. Software Engineers are much too different from Computer Scientists
8. SWEBOK represents the state-of-the-art in Software Engineering
9. Software Engineering is "engineering"
10. Software Engineering is not "engineering"

Would you agree?

As a professional software engineer, I’d have to agree with what he’s saying. Even some professional software organizations, right here in Montreal, have no clue about the difference between software engineering and software development. For example, this year at the University, there were some high tech companies on the campus to recruit co-op students or recent graduates, and most of them were looking for software engineers to code various algorithms in C or C++, design Web sites with the latest buzzword-oriented technology, etc. Hopefully they’ll take a couple of minutes to read the entire article.