You are reading a MIX Online Opinion. In which we speak our minds. Joshua Allen Meet Joshua Arrow


20Comment Retweet

Ninja Coders and Despot Designers: Game Over

Feb 1, 2010 In Web Culture By Joshua Allen

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.

Cute chubby ninjaHowever, 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.

Follow the Conversation

20 comments so far. You should leave one, too.

Offbeatmammal Offbeatmammal said on Feb 1, 2010

so... you''re saying if we stopped messing around with design and went back to 80 column green screen for everything we''d all be cranking out awesome apps in negative time? and they''ll test themselves?!

Sign me up! I don''t need no stinking RIA!

(please ask Nishant not to nail me to the wall if he reads this)

Nishant Nishant said on Feb 1, 2010

@offbeatmammal - You must be mistaking me for someone else. I can''t remember the last time I evangelized RIAs as the savior of all that is good about design on the Web. "Au contraire": :-)

@allenjs - Great post; more comments soon. How long did it take you to wireframe the app vs. build it?

frank siede said on Feb 3, 2010

you forgot the times you lose a whole day from incorrect documentation, or a buggy new version of a platform or changing code to work one every browser type.

Merix Studio said on Feb 3, 2010

Good reading. Agree that "project planning", wireframing and UI design is highly intensive and challanging process, but still, keeping in mind our recent apps we worked on, development phase exceeded (or at least was equal to) design/wireframing phase.

Joshua Allen Joshua Allen said on Feb 3, 2010

@Nishant - It was about 12 hours total; with maybe 4-5 spent on coding/testing. I should''ve mention that the "design" phase involved a a number of iterations with my "client", aka my wife.

@Merix, @Frank - Thanks for the input. The more I''ve thought about it, the more I would agree that my observations don''t always hold true (yet). The observation has held true for a couple of projects I''ve worked on recently, but that''s admittedly because nothing major went wrong. We have another project we''re doing that uses a bleeding edge technology -- which is very productive, except when you hit some undocumented bug and blow 2 days. Maybe a corrolary to my theory is that dev schedules will be dominated by unexpected problems :-)

One other thing to note is that, in my experience, the more thorough a job is done upfront in design, the less work it takes to develop -- so maybe there is give-and-take between where we invest.

Saud Khan Saud Khan said on Feb 4, 2010

It certainly applies to smaller application / integration only projects. However, for large scale application - coders will end up taking most of the credit.

I guess we need to reconsider how society should think about "jack of all trades"

Gillesv Gillesv said on Feb 4, 2010

I try to be both things, design- and develop, as I believe good code is as much a design process as anything.

Jacks-of-all-trades-masters-of-few are currently undervalued in most firms. Perhaps the future will change that.

Mark Mark said on Feb 4, 2010

I agree whole-heartedly, design is paramount.

When people find themselves wasting time and effort writing and re-writing, facing the same problems over and again there reaches a point when design becomes P1.
Companies with a strong focus on design and the user are easy to recognise (Apple, Google etc..)

Pinche Juan said on Feb 4, 2010

design and coding is a symbiosis, nobody can say one is more ''important'' than the other.

Henrique Carvalho Alves Henrique Carvalho Alves said on Feb 4, 2010

If the planning steps (IA and wireframes) are taking longer than the implementation, this is natural of any well done work.

The same can be said for development. Not one good developer starts a project by spitting a code mess, it normally requires a planning phase, where you get your modeling right, research the tools and documentation you can use, start laying out the API and the test suite, and only then you develop the actual code.

Having said that, normally the design phase precedes the code development, because it''s when you define, roughly, what your requisites are, how it should work and what it should do.

Jeremy Weiland Jeremy Weiland said on Feb 4, 2010

As interface patterns become more mature, we will lean more and more heavily on designers for input. No doubt. That said, it really depends on the application. The underlying premise of your post is that development is becoming commodified. Why is that? Because everybody''s implementing similar data models, and to the extent we''re all writing the same app over and over, we''re getting better at it.

But that''s like saying that design is becoming more commodified because you can grab a free WordPress theme. It depends on how complex and application-specific the code is - and, hell, how varied and complex the design is. Your sample size is pretty small to draw such a sweeping conclusion, don''t you think?

There are tasks that call for more design creativity, and there are tasks that call for more development creativity. Wherever creativity is needed, there costs will rise.

Joshua Allen Joshua Allen said on Feb 4, 2010

@Saud, @Gilles -- Yes, I really believe the roles will grow closer together, and developers will need to know more about design, designers will need to know more about development, and so on.

@Mark, @Pinche, @Henrique -- Agreed. Often when my coding takes a long time, it''s because I didn''t spend enough time planning, or the design was unclear.

@Jeremy -- Fair criticism about my sample size. Nishant has been keeping detailed time logs for a bigger project we did, and might talk about that in a future opinion. I still think we''re seeing a trend, though, as we get better at making platforms that "just work". It probably only applies with things like MVC, RoR, Django -- but I believe that other platforms will catch up in terms of simplicity.

Jacob said on Feb 13, 2010

On the flip side, it is getting ever harder for the dilettante coder.

Ninja coders raise the expectations of what a good app should look like.

So, if I want to build a simple website by today''s standards, then I have to learn a new development framework. Two years later, the framework and methodology is obsolete, before I ever learned it properly in the first place!

Mathew S. Mathew S. said on Feb 16, 2010

Yeah sorry this may only work in stupid simple instances like this but this is not always the case with the majority of jobs & instances where a real coder with experience and knowledge that can''t be point&clicked with a drag&drop API to accomplish what you want. Just becasue you did one job like this doesn''t mean the end of two long-term, experienced professions. Pull your head out of your ass already. if this was the case the entire industry would have failed a decade ago.

Joshua Allen Joshua Allen said on Feb 16, 2010

@Mathew - Thanks for droppping by!

I don''t believe that *any* of the platforms I mentioned support "drag&drop", though, so I''m not sure where you''re getting that. But yeah, I''ve been doing this for 20 years, and I see a pretty clear trend.

But I like your line. Next time my boss tries to staff a project with equal number of designers and devs, I''ll say, "Get yer head outta yer ass already!", lol

Daniel Daniel said on Feb 17, 2010

I think that design gives direction as to where to go, but development shows the road conditions on how that design will eventually perform. Lack of technical knowledge usually leads to unoptimized design. Choosing the "right" technology for a task is an artform by itself, sometimes low tech answers prove to be as efficient as the most overkill framework out there.

J. Jeffryes J. Jeffryes said on Mar 4, 2010

Developers make sure something is built right.

Designers make sure the developers build the right thing.

This is a lesson I''ve had to beat into people over and over again. You can have the best development team in the world, if you don''t spend the time to make sure you''re building what the client needs (not wants), and build it in a way that the client can use, then all of that development horsepower is wasted.

Will developers resist this? Of course. They all want to be Captain Kirk, not Scotty.

David O. David O. said on Mar 25, 2010

If you consider the job boards companies are hiring more developers(coders) than designers, this has not changed for the past 20 years. More designers won''t speed up development. However I have to wonder why it took longer to do a simple IA and Wireframe than code the application, it could be the fault of a mediocre designer.

Boca said on Nov 3, 2011

Not a bad article!

Phillip Lim Shoes said on May 23, 2012

This blog site is great. How did you come up witht he idea?