A blog about technology, software, business, and the user experience.
Written by the members of We Are Mammoth.
Tuesday, October 13, 2009
Why the corporate ladder doesn't work in the software industry
by Ka Wai Cheung
I never fully understood the corporate ladder in the software industry.

The typical corporate ladder generally follow this pattern: Moving up the ladder usually means you write less code. It means you involve yourself more with business objectives than with technical nuances. It demands you think more about some overall vision and less about the intimate details of code. Architect more, develop less.

The corporate ladder creates a false perception that once you've reached a certain level, programming is no longer where you're most valuable. Leave the dirty work for the junior developers. At the same time, it suggests that lower level programmers shouldn't concern themselves with the overall goals and direction of the application at-hand.

Great developers should be both "in the trenches" and "high level" at the same time. For software to really succeed, I'd rather have a group of developers that can think about why something's important, how to best implement something, and then implement it - all at the same time.

When you split up roles into the somewhat arbitrary hierarchy of those that think about the "big picture" and those that only think in if statements and for loops, you lose accountability. Pure architects can make a guess at the best architecture, the best design pattern or the best practice. But, it's only when you're in the trenches that you really discover where the problems lie (and don't lie). And frankly, if you're not in the trenches, you won't care all that much about the trenches - let the developers worry about it. The corporate ladder flies in the face of accountability.

Perhaps, we've taken the architect-developer analogy too far. Maybe, the corporate ladder in the software industry needs a better analogy.

To build a building, architects architect and developers develop. Architects have a general knowledge of building things - enough to create elaborate plans and specs in fine detail. But, they don't develop. It's not reasonable. The separation between those that think high-level and those that work in the trenches is largely for practical reasons. Ask an architect if they could practically design and then build, and I bet many would say yes.

1 Comments:

Blogger Craig Bryant said...

One important thing to realize though, is that trying to balance too long on the fence becomes detrimental to both sides of the fence. I can't remember the last time any of you guys patted me on the back and said, thanks for the great code. You have, however, acknowledged the benefit of having someone who mingles 'outside the code trench' ... prepping an application to best utilize the programmers time.

Should I involve myself with low-level programming decisions? I think not. And I think within a 'programmers hierarchy' it's the same thing. Some make decisions, some implement them.

Now. As for corporate ladders. I always hated being dictated to by someone who had no programming background, no design chops, and little respect for either.

I think your 'architect' needs to have a respect and comprehension of the 'engineers realm', and it needs to be complimented by the engineers occasionally sacrificing one of their own to make a more efficient build cycle.


Post a Comment

Links to this post:

Create a Link

<< Home

Previous months
The Company
We Are Mammoth builds beautiful web applications for some of the best known companies in the world.
Subscribe to our RSS feed
 
The Authors
Craig Bryant
Ka Wai Cheung
Anthony Koerber
Michael Sanders
Mustafa Shabib
Tom Stanley
 
Also by WAM...
DoneDone // Smarter, simpler issue tracking to finish projects strong.
It's bug and issue tracking for actual human beings. Starting at $15/month. www.getdonedone.com
X2O // Build rich Adobe® Flex®, Flash® and JavaScript apps faster
A web-based data modeling platform for Flex and Flash apps, available now at www.x2oframework.com. Blog | Docs
Flash Application Design Solutions: The Flash Usability Handbook
Essential reading for all Flash designers and developers, from beginners seeking valid solutions to veteran Flashers looking for a fresh perspective on application design, interaction, and reusability.
Purchase at Amazon | eBook