Hire programmers who are more systematic, thoughtful, and thorough and your projects will follow suit.

May 01, 1999
URL:http://www.drdobbs.com/management-forum-hiring-the-best/184415690

Every software development manager knows that one way to get the best results is to start with the best people. According to recent figures from consultant Howard Rubin, the average productivity of American programmers is less than 8,000 lines of code per year, and if you look at actual delivered functionality, as measured by function points, productivity is declining. However, if you hire the best, they could be 10 to 20 times as productive as the average developer—and, if you are lucky, they will only command twice the salary, or so the data suggests. But who are the best people and what are their qualifications? How do you know them when they walk in the door?

When I interviewed at C-E-I-R in 1963, it was one of the leading consulting firms of the day. But how did anyone there know to hire me? How did department head Jack Cremeans look at the brash college drop-out sitting across from him and see not an over-confident and under-experienced programmer but a promising professional? I remember he and Ken Mackenzie asked me more questions about good programming practices than about what languages I knew or what applications I had written. But what exactly were they looking for and how did they know whether or not I had it?

I also recall, with some embarrassment, that I tried to bluff my way through a question about an obscure variant of an instruction on the IBM 1401 that you could use to facilitate argument passing to subroutines. I hadn’t a clue. Much later, I asked Jack why he had hired me, knowing that I was making it up. He said he was more interested in the thought processes than the answer. He figured I would learn the nitty-gritty quickly enough.

He was right, in part because I had good teachers. Under the tutelage of Ken, Dave Jasper, and Bud Vitoff, I did learn. I learned not only about programming, but also about the value of thinking, particularly regarding the principles on which good programming is based. When I resumed my interrupted studies at M.I.T., I continued my investigations, trying to understand what constituted best practices and contributed to sound software.

These distant events may not, at first glance, seem to have much bearing on hiring and programming practices in software development today, but, as James Burke might argue, there is a connection. Perhaps I am in such a retrospective mood because this month marks the 25th anniversary of the publication of a paper that would alter my career and, some would say, change the course of programming history.

In May 1974, the IBM Systems Journal published a paper titled “Structured Design,” which summarized and finally gave a name to what I had learned about good programming and design and had spent more than a decade trying to make comprehensible. That widely reprinted and much cited article introduced many basics of modern software development practice to an expanded audience.

Structured design did not, however, suddenly spring from the ground, fully formed in 1974. The foundations had been laid much earlier. The basic methods, models, and concepts were already well developed when I presented a paper at the National Symposium on Modular Programming in 1968, the same year the ACM published Edsgar Dijkstra’s duly famed letter on the harmfulness of GoTos. In my archives are documents going back to 1966 describing notational innovations that have stood the test of time. Those little arrows indicating information flow in the newly minted Unified Modeling Language, for instance, come from structured design by way of the Uniform Object Notation developed by Meilir Page-Jones, Steven Weiss, and myself (see “Modeling Object-Oriented Systems,” Computer Language, Oct. 1990).

Is this ancient stuff still relevant? The average shelf-life of books in our field is a little more than two years. Can anything that is more than 25 years old mean something to you as a development manager? Well, you can still find Ed Yourdon’s and my book Structured Design (Prentice Hall, 1986) in stores, unrevised after more than two decades. Why? Open almost any current textbook or popular book on programming, design, software engineering, or even development management, turn to the index, and the odds are you’ll find references to coupling and cohesion even if you don’t find mention of Constantine, Yourdon, Stevens, or Myers. The fact that the terms are increasingly used without attribution or citation demonstrates that they have passed from coinages to become coin of the realm. Why?

Although it has been said that I invented structured design, it is more accurate to say that I invented a way of talking about design. In many respects, the concepts and techniques are simply software development best practices distilled. The best developers design their software systematically to increase the cohesion of individual components and reduce the coupling between them. This was true in 1963, and it is still true today.

In this age of object orientation and the first dawning of the so-called Unified Process, it is unlikely that many developers still practice orthodox structured design, and even fewer would admit it. But good developers will understand and apply the underlying principles, keeping the sundry parts of their programs distinct and independent, pulling together what is strongly related so it can be used as a coherent unit, and organizing the overall structure in a rational way that reflects the nature of the problem being solved. Whether you call them subroutines or object classes, whether you write in FORTRAN or Java, this stuff is motherhood and apple pie. Reduce coupling and enhance cohesion. Who could argue otherwise?

The core of structured design is, after all, design. You design what you build before you build it. You design it so the overall architecture makes sense. You design it so the pieces hide and encapsulate the appropriate bits of code and data. Except for the smallest and most uncomplicated problems, you cannot achieve this merely by cutting code, hoping to discover where to chop it up or how to connect it all together along the way. Architecture precedes carpentry, in software as well as buildings.

Sooner or later, after enough failures and near disasters, nearly everyone learns these basic truths. In Microsoft Secrets (Free Press, 1995), Michael Cusumano and Richard Selby quote Microsoft development manager Ben Slivka, who recounted the sad consequences of complex interdependencies and then said, “We should make all team members have practice at object-oriented design, focusing on data-hiding and minimal interfaces, to ensure that code will be modular, decoupled, and maintainable.” Laudable sentiments indeed, if only they were practiced.

Slivka goes on to suggest brief training in these software engineering fundamentals, which leaves me wondering: Is the two to four weeks he advocates enough? And why didn’t his developers know and practice these good practices in the first place? Which returns us to the issue of hiring the best people.

Consultant and former Microsoft manager John Rae-Grant has described how, in his first workshop from people outside Microsoft, he learned that there were certain admirable and desirable abilities that Microsoft didn’t value. Microsoft’s interview style, which stressed quick, on-your-feet decision making and rapid-fire responses, tended to reject candidates who were more systematic, thoughtful, and thorough. Such biases of one sort or another are common to many organizations, of course; problems arise, Rae-Grant explains, when the culture is blind to its own blindness.

I cannot attest to the accuracy of this characterization of Microsoft’s hiring methods—I’ve never applied for a position at Microsoft—but I can say that the purported practices are in keeping with what I have learned about the working culture at Microsoft, a culture that is, by all evidence, shaped from the top down.

In their book, Cusumano and Selby quote Bill Gates himself as saying, “There’s no ‘design,’ in the sense of how the code works, that’s ever done in program management.” Another manager explained that Microsoft uses little or no design documentation: “A developer’s job is to write code that we sell, not to spend time writing high-level design documents.” And Gates confirms this, rejecting any “methodology where you have a document that’s independent from the source code…. Going off and spending a lot of time on that—that’s ridiculous…. One document. One. It’s the source code.”

So, does Microsoft design or not? What is undocumented design? The same Ken Mackenzie who played a role in hiring me in 1963, and then tried to teach me the difference between coding and software development, put it succinctly in what he modestly called Mackenzie’s First Law: If it isn’t written down, it doesn’t exist. Undocumented design is no design at all. You cannot design anything of nontrivial proportions without putting pencil to paper or mouse to pad. That is the fundamental reality behind every design notation and modeling tool from data flow diagrams all the way through to use cases and the Unified Modeling Language.

As I write, I realize I may once again be charged with bashing Microsoft, but that is certainly not my intention. I point to Microsoft precisely because it is so often held up as the paragon of success. At conferences, developers often begin their questions or challenges with, “But Microsoft does such-and-such.” Whole books have been written about the Microsoft way, about the methods of development and management that are the supposed secrets of its success. If Microsoft is so successful, it is argued, it must be because its developers and managers are doing something right, so let’s all emulate them.

In my opinion, however, Microsoft has been so successful largely because it has been in the right places at the right times and has ruthlessly and relentlessly pursued advantage, not because it produces great software and certainly not because it exemplifies best practices. Microsoft is about selling code more than it is about writing code, and there is no argument that it does a good job of selling. Hiring people to write code to sell is, of course, not necessarily the same as hiring people to design and build durable, usable, dependable software.

Spending time designing and documenting design is “ridiculous” only if you don’t count the time wasted later trying to work around all the mistakes in partitioning the problem or fixing the thousands of bugs that you might have avoided by first planning how things would fit together. It is time wasted only if you don’t account for the thousands of hours your customers waste due to lost work or applications that freeze several times a day. If what you are selling is code, not solutions, only the code counts. If what you are measuring and interested in is quick answers to coding questions, then the coders who crank out the most lines of code by going directly from concept to code are the ones you want.

In all fairness, even the Microsoft megalith is not a cultural monolith. Ben Slivka seems to have learned his lesson, and a Wall Street Journal article on Windows 2000 honcho Jim Allchin (Feb. 4, 1999) suggests that he, too, may be trying to create a more sober culture focused on sound architecture. I can only wish him well. Cultural change is a slow process, and he has to contend with the gung ho hackers and commando coders (see Dave Thielen’s “The Commando Returns,” Management Forum, Mar. 1999) who already work there. Only time will tell if these are the best people for such an environment.

So, how do you pick the best applicants? What would I ask developers applying for a position with me? I would ask them about some of the latest hot topics in development, but I would also ask about “the old stuff.” I would ask them how they know where to put the code for a particular feature or bit of functionality. I would ask them what they do to try to make their programs easier to debug, maintain, and modify. I would ask them how they decide upon and describe the architecture—the overall organization—of a large program. If they used the terms coupling and cohesion, I’d ask them to explain what those words meant to them. But even if they did not, I would expect them to understand and apply such fundamental ways of thinking in their work. I would want to see not only some of their code, but also how they documented it.

I would probably give bonus points to candidates who said to some of my questions, “Let me think about that for a bit.” Or, “This is a complex issue with subtle trade-offs that need to be thoroughly considered.” If they started sketching ideas on the whiteboard or doodling on my desk pad, I would probably hire them on the spot!

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.