- The Fundamental Argument
- Process: How We Got Here
- The Next Step: Velocity
- Approaching Tomorrow
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Next Step: Velocity
The waterfall model slowed development by creating blocks; Agile sped it back up again by removing them. While removing blocks improves development time by eliminating dead spots, it doesn’t actually increase speed.
The naïve method for increasing speed is to work harder or work overtime. Thirty years and hundreds of studies in organizational behavior later, we’ve learned that constant pressure to work harder doesn’t improve results. Under intense schedule pressure, people make mistakes and don’t bother to fix them, until integration doesn’t work at all. Then the bugs have to be fixed. The result is buggy software and slipped schedules.
There is a better way, and the first step in the process is to slow down. Mathematicians often consider a problem and an approach to that problem for minutes or even hours before they pick up a pencil. Back in the office, this means thinking about how to solve the problem before trying to solve it. It means focusing on the angle of attack, rather than on the appearance of progress. With a large number of potential techniques in his arsenal—we’ll get to those in a moment—the worker can choose the best tool for the task.
Getting to the Essence
When trying to reduce development costs, many people focus solely on programming tools such as Java or .NET. But programming is only one portion of development; Honeywell Labs estimates that coding is a mere 20% of the overall development cost. Even if we could cut the cost of programming in half, the overall cost of development would drop by only 10%. Fred Brooks identified this problem two decades ago in his essay "No Silver Bullet: Essence and Accidents of Software Engineering." More importantly, Brooks distinguishes between accidental and essential difficulties of software development; many of the accidental difficulties have been handled by modern tools, but to speed up development, we have to attack the essence of the problem.
More than one research study has concluded that the best programmers can develop software 10 times faster than the worst. This may be in part genetics and in part free will, but we assert that developers can learn a set of tools that attack the essence of engineering work. A top-of-the-line integrated development environment won’t help developers here; the programmer’s tools are really mental tools.
Sharp Tools
It’s said that when the only tool you have is a hammer, everything looks like a nail. Programming languages and tools are often created to solve a specific problem; each will have pros and cons in different environments. Developers who know how to program in several styles notice when one style is more appropriate than another. For example, a developer who understands both relational databases and object-oriented programming will be able to look at requirements and say, "If we use a relational database, I could do all this work with a single update statement." That developer just saved the organization the work of developing a custom version of that update statement. When the developer says, "If we use a template method, I could eliminate half of this code," he should be empowered to do so. When developers have those conversations with each other, knowledge is flowing; the organization is growing.
To get there, organizations need to hire, promote, and mentor developers so that they learn different languages. Developers who know how to use a relational database, an object-oriented language, a scripting language, and a functional language can recognize when one language will be faster than another—and make better choices in the moment. When a different language isn’t an option, understanding the different methods allows the staff to use the best approximation.
Little Languages
The most productive programmers know a secret to developing software faster: new languages. For handling text files, AWK and SED are optimal. C allows developers to write operating systems for several different machines. For an interactive environment that can also be scripted, the Bourne shell is the order of the day. When Bourne fails, Perl is always available.
Most developers have heard of these languages; they might reply, "I know those languages; tell me something new." The key is not to use existing languages, but to write a new language that solves the current problem. These "little languages" allow a few terse statements of code to implement pages of business requirements.
Your organization won’t be selling this language—just using it. If it doesn’t cover every corner case, or can’t be embedded, or whatever, it doesn’t matter. The idea is to get a specific project done faster; it doesn’t have to be a fully general solution.
Generative Programming
Writing repetitive code can be a terrible drag on the velocity of a developer. Not only does it take time, it’s boring. Boring work tends to be done in a sloppy way, and errors are likely. This danger can be averted by instead writing a program to generate the code.
For example, many teams extend object-oriented techniques to cover databases by writing a "database wrapper." Often the code is the same code every time, such as writing a getter and setter for every column of the database as well as lookup, insert, update, and delete functions.
Writing one or two code wrappers is easy. Fifteen, on the other hand, is tear-your-eyes-out boring. Then again, writing a program to query the database itself, ask about the code structure, and generate 15 (or 50) code wrappers—now that’s exciting. Writing the generator might take two days and the custom code might take two more; but then it’s done. Next time a half dozen tables are added, or a table structure is modified, the code generator can create the new wrappers. The resulting code is, arguably, free.
Code generators can also run in reverse—Cog is a code generation program designed to build small snippets of code that live inside a hand-rolled framework. Even a few lines of initialization code can be generated automatically.
Coding at the Bare Metal
High-level programming, sharp tools, little languages, and generative programming all provide ways to attack the problem instead of the solution. The Pragmatic Programmers, Andrew Hunt and Dave Thomas, call this "programming close to the problem domain." In eCommerce, for example, customers care about ordering and shipping product—not about pointers, memory, and databases. Once the technical staff is focused on solving the problem and not managing memory, it might be time to attack the requirements process by using rapid prototyping.
Rapid Prototyping
Rapid prototyping is a big term for a very simple process. In essence, the programming staff asks the customer what he wants, draws a picture, and asks, "Is that what you meant?" The team then uses discussion and feedback to further refine the requirements. Whereas traditional requirements-gathering sessions can take months, a one-day offsite meeting with developers and customers, talking face to face and mocking up screenshots, may result in good enough requirements to begin development the next day.
When development starts earlier, the customer will see what needs to change earlier, which means that delivery of the real need will happen earlier.