Software Development: Building Reliable Systems
#6 Thou shalt recognize and retain your top talent
Too many software development books concentrate on technology or management practices. At the end of the day, a lot of your success in software development will come down to who you have working for you and how happy they are in their work. You can have the best technology and organize your team in the best way possible, but if you have the wrong team it won't do you much good. Another surprise, given the effort so many organizations put into recruiting talent, is their failure to recognize and retain that talent after they join the organization.
Organizations that are successful at retaining their top talent start by recognizing their top talent. There are plenty of metrics that can be gathered around a developer's productivity and quality. Don't forget, however, more subjective criteria as summarized in Table 1-3. Who are the developers who always show up at other code reviews and make constructive comments? Who is known as the "goto" person when you have a tough bug to find? Which developers really understand the business you are in? Who has the best contacts with your customers? Be sure not to concentrate 100% on hard metrics and overlook such factors as these. Once you know who you want to keep around, go about thinking of ways to make it happen.
Table1-3. Traits of Successful Developers
| Skill Dimension | Trait | Example |
|---|---|---|
| Technical | Operating system knowledge | Understands operating system principles and the impact of OS on code design choices |
| Networking knowledge | Understands networking infrastructure and matches application network demands to available infrastructure | |
| Data management | Understands how and when to use databases, transaction monitors , and other middleware components | |
| Hardware | Knows the limits of what can be accomplished by the software application on various hardware configurations | |
| Business | Understands the business | Can differentiate between "nice to have" requirements and those that are essential to the function of the application |
| Market knowledge | Keeps up-to-date on developer tools, frameworks, and hardware | |
| Professional | Written and verbal communication | Effective presenter at code reviews; documentation is easy to read and understand |
| Teamwork | Participates actively in other's code reviews | |
| Flexibility | Can work well on a wide variety of coding assignments | |
| Reliability | Always completes assignments on time; strong work ethic | |
| Problem solving skills | Viewed as a "goto" person for help in solving difficult software bugs |
Throughout most of the 1990s, demand for skilled high technology workers has far exceeded the supply. It is easy to throw software developers into this general category and assume good developers are no harder to find than other high tech workers. Based on our experiences, we believe good software developers are even more scarce than good IT personnel in general. Just consider some of the numbers . The Java language was introduced as a new programming language in 1995. By late 1997, IDC estimated that there was a worldwide demand for 400,000 Java programmers and that this would grow to a need for 700,000 Java programmers by the year 1999. While much of this demand has been filled by retraining existing developers to program in the Java language, it still represents a tremendous outstripping of the supply of knowledgeable Java programmers.
Developer skill, more than any other factor, is the largest single determinant to the outcome of successful software projects. This is reflected in software costing and scheduling models, most of which place higher weighting factors on developer skill than all other factors, including even project complexity. In other words, skilled developers working on a complex software development project are more likely to produce a successful application than lesser skilled developers working on a simpler project. It is no accident , therefore, that this book devotes a large part of its text to describing what makes a good developer (Chapter 5), how to hire one (Chapter 7), and how to retain your developers after they are hired (Chapter 8). Studies have shown that top developers can be two to three times more productive than average developers and up to one hundred times more productive than poor developers. This wide range of productivity and its standard deviation is higher than for any other profession. Good developers not only produce more lines of code, their code has fewer errors, and the code they produce is of higher general quality (i.e., it performs better, is more readable, is more maintainable , and exceeds in other subjective and objective factors) than code produced by average or poor developers.
One false belief we have heard from many software development managers, especially those without a development background, is the notion that as development tools become more advanced, they "level the playing field" between average and great developers. Anyone who has ever attended a software development- related convention has seen slick demonstrations showing how "non-programmers" can use a development tool to quickly build an application from scratch. Modern development tools, especially Integrated Development Environments (IDEs) addressing everything from requirements definition to testing, certainly help developer productivity. This is especially true in the area of graphical user interface code. Even with the best of IDEs, however, there remains a highly intellectual component to software development. The best software requirements, the best software architectures, and the most error free code continues to come from the best software developers and software architects .
Rather than leveling the playing field, our experiences have shown that good IDEs, used as part of the development process, increase rather than decrease the difference between average and great developers. There is often a compounding effect as an unskilled developer misuses a built-in function of the IDE, introducing bugs into the program, while never gaining the experience of thinking out the complete solution. We are not, of course, by any means against the use of good IDEs or the concept of code reuse. It's just that neither of these are a substitute for developer skill.