Commandment 6 and 7

6: 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. Plenty of metrics can be gathered around a developer's productivity and quality. Don't forget, however, the more subjective criteria summarized in Table 3. Who are the developers who always show up at other code reviews and make constructive comments? Who is known as the "go to" person when you have a tough bug to find? Which developers really understand your business? Who has the best contacts with your customers? Be sure not to concentrate 100% on hard metrics and overlook factors such as these. Once you know which developer(s) you want to keep around, go about thinking of ways to make that happen.

Table 3 Traits of Successful Developers

Skill Dimension	Trait	Example(s)
Technical	Operating system knowledge	Understands operating system (OS) 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	Differentiates between "nice to have" requirements and those that are essential to the function of the application
	Market knowledge	Keeps up to date on developer's 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 developers' code reviews
	Flexibility	Can work well on a wide variety of coding assignments
	Reliability	Completes assignments on time; strong work ethic
	Problem-solving skills	Viewed as a "go to" person for help in solving difficult software bugs

Throughout most of the 1990s, demand for skilled high-technology workers far exceeded the supply. It's easy to throw software developers into this general category and assume that good developers are no harder to find than other high-tech workers. Based on our experiences, however, we believe that 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. The worldwide estimated demand Java programmers stands at over 1 million. While retaining existing developers to program in the Java language has filled much of this demand, 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 weighing factors on developer skill than all other factors, including project complexity. In other words, skilled developers working on a complex software development project are more likely to produce a successful application than less-skilled developers working on a simpler project. Studies have shown that top developers can be 2–3 times more productive than average developers and up to 100 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 is of higher general quality (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've 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 "nonprogrammers" can use a development tool to quickly build an application from scratch. Modern development tools, especially the integrated development environment (IDE) that addresses everything from requirements definition to testing, certainly help developer productivity. This is especially true in the area of graphical user interface (GUI) 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 continue 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. Of course, we don't oppose the use of good IDEs or the concept of code reuse. It's just that neither of these is a substitute for developer skill.

7: Understand Object-Oriented Technology

Every key software developer, architect, and manager should clearly understand object-oriented technology. We use the term object-oriented technology versus object-oriented programming because one doesn't necessarily imply the other. Many C++ and Java programmers develop in an object-oriented programming language without any in-depth knowledge of object-oriented technology. Their code, apart from the syntax differences, probably looks very much like previous applications they've written in FORTRAN, C, or COBOL.

While object-oriented technology is not a panacea for software developers, it's an important enough technology that the key engineers in every development organization should understand it. Even if your organization doesn't currently have any ongoing object-oriented development projects, you should have people who understand this technology. For starters, without understanding the technology you'll never know whether it's appropriate to use on your next project. Secondly, due to the long learning curves associated with object-oriented technology, organizations need to invest in it long before they undertake their first major project. While object-oriented programming syntax can be learned in a few weeks, becoming skilled in architecting object-oriented solutions usually takes 6–18 months or more, depending on the initial skill set of the software engineer.