When Less Is More

A lot of the marketing hype regarding the next generation of programming tools and methodologies (e.g., extreme programming) has me concerned. It seems like the primary emphasis is on productivity and generating more code faster. I have nothing against productivity, but to my mind, the problem isn't a lack of code. All modern development platforms have productivity tool sets that facilitate rapid coding. Today's IDEs have graphical design environments, and the .NET and Java class libraries provide hundreds if not thousands of pre-built functions that you can readily use in your applications.

No, the problem with many applications is too much code—too much bad code, that is. Not that the code generated by some tools such as Visual Studio is bad—quite the contrary. The code is usually pretty good, probably better than the average coder would produce to do the same tasks. And nothing's wrong with making coding easier. The problem is in the mindset and expectations that this "more is better" mentality fosters.

For programmers, this mentality leads to the idea that coding must be done quickly—the faster, the better. The emphasis isn't on creating defensive and highly reliable code. Instead, it's on getting things done quickly—as if quantity were a desirable substitute for quality. Writing high-quality production-level code takes time, and for the most part, productivity enhancements such as generating code to make Web services from stored procedures or reducing the effort to create reports don't address the more serious issues of coding for reliability and security.

However, a far more troubling side of this mentality is the management expectations that it engenders. Buying into the improved-productivity line gives managers unrealistic expectations of the time required for coding tasks. Although not all managers fall into this category, plenty of them do, even some who have good technical knowledge. This way of thinking by managers creates an insidious trap for the programmer who argues for more realistic deadlines. As programmers know, this argument often translates in manager-speak to "the programmer lacks the skills to be productive" or "we've chosen the wrong tool set to get the job done." Both of these reflect negatively on the developer. The first could imperil his job and the second suggests that the business has invested in the wrong products. Fear of either of these management perceptions can lead programmers into acquiescing to goals they know are unrealistic. This path leads to poor code, followed by missed project deadlines, poor application quality, and dissatisfied users.

The battle between code productivity and code quality reminds me of the IBM adage: "You can have it right or you can have it right now." Lots of code quickly doesn't necessarily equal good code; this message needs to permeate the software-development process from the vendors to the application developers. From the tool vendors, the message to developers should be "doing more to help you do better." Programmers should expect code-productivity tools to help them produce higher quality code by reducing the time they spend performing mundane tasks. Expecting increased productivity to collapse project deadlines is a losing proposition. By building the expectation of improved code quality, everyone wins.