Building quality software systems in a reasonable time at a reasonable cost is an uncertain business. Much has already been accomplished to tame the technical dragons, such as complexity, which give rise to much of the uncertainty. For nearly every software engineering activity there are now methods and tools available, which, when applied, enlarge our chances for success. The influence of the individual software engineer or programmer on project outcome has received considerably less attention. Yet the manner in which the individual practices his art has a profound effect on cost, schedule, and product quality.
Logic is our product. It reflects the intellect and the training of its authors. The power of a program is limited only by the minds of its creators. It follows that our best hope for success is to leave the construction of our software systems to the brightest and most capable software engineers we can find. We have failed to make this common practice. The price for the failure is steep.
A great deal of time is wasted producing programs that are only marginally useable. Apparently some engineers have not looked at their calendars lately. Their code looks like “stuff” from the 1960s. The programs they construct violate the most elementary programming precepts. They lack logical structure, and do not map well to any system model. Code is tightly coupled. The capricious use of global objects, when none are needed, makes it difficult to make modifications to logic with confidence that unwanted side-effects will not erupt. Subprograms extending to 700 lines and more, making them nearly impossible to understand, are not uncommon. As a consequence, large volumes of code must be discarded and rewritten if change is required; inordinate effort is expended to maintain poorly designed code; or low product quality puts at risk the continued use of the software and the economic survival of those who manufacture it.
We have an easy option for mitigating the damage done, unwittingly, by these programmers. We can deprive them of their opportunity to do harm by selecting in their place software developers with a demonstrated aptitude for problem solving and a willingness to apply software engineering principles. We can stop trusting in the myth that the ability to write a C++ program that compiles without error is a sufficient qualification for employment as a software engineer. We can conduct goal-oriented interviews, whose purpose it is to identify candidates who possess problem solving aptitude.
The attention given to “skill sets” and to web-based skills certification takes us in the wrong direction; it handicaps our efforts to find good software engineers by diverting attention from what should be our first concern, identifying accomplished problem solvers. Making skill sets our primary selection criterion is a bit like choosing an automobile mechanic based on the brand of tools he uses. Can you imagine the young Dr. Einstein being rejected for a position because he had no experience operating IBMs new 15-digit mechanical calculator? The developer who cant move quickly from Unix to Windows or C++ to Lisp, or rapidly master PowerBuilder or Oracle has no right to call himself or herself a software engineer. We need software developers who understand methods for deriving solutions from problem statements, who can find patterns in apparent randomness, and who can communicate designs, with clarity, in words and pictures. It matters not a wit, whether they mistakenly suspect that grep is the third person form of the verb to grope.
The job interview provides an opportunity to assess a candidates abilities. Unfortunately, techniques for making sound judgments are almost never employed. Opportunities for eliminating problems in the organization before they become new hires, thus, are lost. Typically, the interview is a superficial affair in which only the candidates manners and resume go on trial. The interviewer and interviewee are on their best behavior, like a couple on their first date. Most interviews are so predictable they seem scripted. The interviewer paints a picture of the organization and the work more as he wishes it were than how it is. Gentle probes for information yield little more than what can be gleaned from the resume. On the other side, the interviewee responds in ways designed to please.
We need, instead, to learn whether the candidate can translate a problem statement into a set of software requirements, and then transform those into a design. We need to know what methods they use to model systems. We need to know whether they understand the effect of information hiding and data abstraction on software maintainability. If they don't come up to our standards in every respect, that may be all right, as long as we detect a willingness and a capacity to learn. We need to ask ourselves, “What sort of solutions is this person capable of creating?” This is the question whose answer has the greatest bearing on the cost and quality of software.
Early in my career I traveled to Los Angeles to meet with a prospective employer. The company I visited built aircraft guidance systems. The job market was pretty hot at the time, and competent engineers had their choice of work. While some events of the day are mostly forgotten, the two plus hours I spent with the director of software engineering are clearly remembered. What made the time spent with him memorable was that it was more an examination than a job interview.
We sat together at a table in his office, where he and I worked together to solve a real problem. At some point I was no longer the fellow being interviewed; I had become his colleague, working with him to solve a practical engineering problem. I suspect that whether or not his subject ultimately arrived at a solution was less important to him than was the manner in which attempts to find a solution were made. Afterwards, I learned that all applicants were tested in this way. I never regretted accepting that job, and not since then have I found talent so tightly packed in a single organization. Our products were highly regarded. What he did worked.
I don't mean to suggest that we discard all our yardsticks for one that takes into account only an aptitude for problem solving. I am suggesting that if our goal is to improve quality and reduce development costs, it is more quickly realized when the focus of recruitment is shifted to where it rightly belongs, on problem-solving skills. I am suggesting, also, that we devise techniques for accurately assessing a candidates talent for logic design. Is it unreasonable to ask a candidate for employment to take a test, or to bring a portfolio of their work to the job interview?