Our industry has just been changed forever. Many have predicted that this day would come, and it finally has -- design has irreversibly supplanted development as the center of gravity in software projects.

OK, so maybe that's a bit dramatic. The revolution has taken longer than a day, and will continue for some time. But I believe we can safely say that we're past the turning point.  Design has won.

This is a topic that Nishant and I have discussed many times, but the "eureka!" moment for me happened when I was building a Web application to handle MIX Open Call voting. It was a simple application that needed only 4 or 5 page types and was only going to be in production for a week or two -- so it wasn't worth hassling a designer over. Since I did the design myself, I didn't create any comps and I decided to use the base CSS that comes with ASP.NET MVC. In other words, I sketched out the IA and wireframes on paper and iterated a few times before creating the markup.

Despite this severely truncated "design" process which involved no Photoshop or CSS work, the design phase took longer than coding and testing the application. I'll repeat: it took longer to do a simple IA and wireframes than it took to code the application. I was honestly surprised. My expectations had been violated. Coding the application shouldn't have been easier than creating the wireframes.

My code needed to implement data models from three different types of stores (XML, Cookies, and SQL Server). It also had to support search functionality and permalinks.

But it was simpler to implement. I'd like to say that it's because I'm such an awesome coder, but that wouldn't be true. It had nothing to do with my awesomeness.  I believe that anyone who set out to build the voting application would have experienced the same thing.

Ninja Coders

Fred Brooks' influential book, "The Mythical Man Month" has left a concrete impression on our profession ever since it was published in 1975. In the book, Brooks makes the famous argument that development costs dwarf all other costs on a project, and that superstar developers are tremendously more productive than “average” developers. Therefore, the best way to control software cost is to hire superstar developers and get rid of the average developers. Brooks' insight has informed hiring practices at Microsoft and elsewhere and contributed to Zen-master Ninja Complexes among good developers.

However, things aren't so clear-cut today. Developer productivity has been improving by leaps and bounds every year. The tools and frameworks we use today seem like magic compared to what we used in the past. A developer using ASP.NET MVC and LINQ, or frameworks like RoR and Django, can crank out code that we wouldn't have even dared to try 10 years ago. And things are getting more reliable. When was the last time you had to debug a null reference exception or a performance issue caused by excessive use of the heap?  We may all be ninja coders today, but it’s only because we have magic weapons.

By contrast, the design process is limited by human factors, especially in the early stages. The early design phase is about discovery and building shared context with your client or customer. This is the phase where you decide exactly what you want to build, so there is a lot of iteration and interpersonal communication involved. You could optimize this process by hiring UX folks who are expert hypnotists, but even this wouldn't be enough to outpace the productivity gains developer tools and frameworks are making.

A Lesson from History

I first began noticing cracks in Brooks' development thesis seven years ago, when I was working on the SQL Server team. At the time, the CLR was fairly new.  We were in a unique position to compare native code versus managed code development, since we were simultaneously shipping XML APIs built entirely in C++, and XML APIs built entirely in managed CLR code. The functionality of both was similar, and used the same team of people.

In those days, most test teams were roughly the same size as the development team. But when it came time to allocate headcount for our managed code software, many of us were shocked when the test manager was asking for nearly twice as many people as the development manager. It violated our expectations. Was the test manager trying to build an empire? Was managed code so buggy that it needed extra testing? What was the deal?

It was just simple math. The developers could code up the functionality twice as fast as before, but all of the functionality still needed to be tested. You can't skimp on test coverage just because the developers are more efficient. More productive development means that you spend a larger percentage of your overall budget on test. Simple math, but it opened my eyes.

The Rise of Design

Of course, the past seven years haven't seen development teams being replaced entirely by testers. Instead, TDD has incorporated testing more directly into the development process, so developers spend more of their time testing. And testing has become more efficient.

It's pretty easy to see where this is going. If development and testing are taking less time, the design phase will eat a proportionally larger chunk of the overall budget. We can certainly imagine productivity improvements to some of the design tools, but design will always have a big bottleneck: clients and their psychology.

Yes, there are plenty of other reasons that design is more important now than ever, but simple math is sufficient to make the point.

What Does it Mean?

Does this mean that designers will soon outnumber developers and testers on projects? I don't think so. Brooks also demonstrated that you can't necessarily speed up software development by throwing more developers at a problem -- the same is true of designers. Think of the last project you worked on where you were the sole designer, or where you worked with a single designer. Do you think it would have been completed in a sixth of the time if you had put six designers on it? Ha!

This suggests that we will simply see smaller teams, with a small number of designers, working with a small number of testers and developers. Our challenge will be to scope projects to stay within the capabilities of a smaller team size, or else pay the price in diminishing returns.

Does this mean, instead, that designers will be corrupted by this newfound power and despotically wield control over the developers? Again, I think that’s the wrong way to look at it. The customer always has the ultimate power, and that power is mediated through the designer.  This is how the world should be, and I’m sure the designers will still let us wear ninja costumes to work.  Besides, Norbert Wiener, who published the tremendously influential book “Cybernetics” in 1948, showed that the most flexible component of any complex system will exert the most control over the entire system. Becoming more productive and adaptable is always a good thing. It's only when designers and developers work in harmony that the true potential of both is realized.

Your Turn

Does the “simple math” presented here agree with your own experiences?  How do you see these trends playing out over the next seven years?  Leave a comment below.