{ End Bracket }
Proud to Be a Developer
Adam Barr
When I was a senior in college, I remember a conversation with a fellow computer science major who was going to work for an investment bank. He explained that he would be involved in designing software, but he would not busy himself with the mundane task of actually writing it. That would be handed off to a coder—evidently a lower species. In other words, me. Coming from a university environment in which the ability to hack code was the ultimate status, I felt vaguely insulted.
However, he had a point. Back then, I was just a coder (not that he was any better). Today, as in the title of Mike Gunderloy’s book Coder to Developer, I have moved beyond being a mere coder and now consider myself a developer. I know more than just how to write code that compiles; I can produce software that is fast, reliable, well-tested, secure, maintainable, globalizable, and on down the list of attributes of high-quality code. The software industry in general is maturing from an army of coders to an army of developers.
Now, if you ask developers about their next career step, they may say they want to be an architect. The word conjures up visions of titanium and frosted glass, and relegates the mere developer, by comparison, to the role of construction worker. So do I feel like taking the theoretical next step and styling myself as an architect? My answer is no.
No insult to architects is intended: software development does need people to lay out the interaction between components of a system, and to keep the big picture in mind. Nonetheless, I am proud to be a developer, and I hope every other developer can feel the same pride.
What if you envy the freedom of design available to physical architects like Frank Gehry or Rem Koolhaas? My response would be that the discipline of software engineering is too immature to climb that conceptual ladder. Architects can design buildings like the Bilbao Guggenheim Museum and the Seattle Public Library because they are supported by centuries of knowledge about civil engineering. The software industry can’t afford the luxury of having everyone operate at this level; most of us are still trying to build a one-story house that doesn’t collapse when you slam the front door.
When Microsoft examines the cause of its bugs, it identifies a significant number that aren’t design bugs—the kind that would be found when an architect reviews a design document—but neither are they coding bugs—when the source code doesn’t do what the programmer intended. This intermediate class occurs when the source code does what the programmer intended, but there is a localized error in the intent: issues like passing the wrong flags to a method, or misunderstanding the meaning of a configuration parameter. This isn’t the province of architects. It’s something that we developers have to do correctly on our own.
Fred Brooks alluded to this in his famous "No Silver Bullet" essay where he wrote "The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions" and then went on to say "I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation." He is not talking about what architects do; he is talking about what developers do. He is saying, in effect, that being a coder may not be too hard, but being a developer certainly is. We should recognize the merit of what we do.
I know this is not the glory work of programming. It can be a thrill to perfectly architect multiple components in a way that neatly encapsulates variation and allows for future extension. Programmers like precision, and there is beauty in having all of the pieces fit together just so. But there is a large part of producing software that involves working like a skilled craftsman: performing code reviews, writing unit tests, cleaning up comments. Customers may not directly recognize how our hard work is ensuring their privacy or guarding their system against attack, but we know the value we provide. And there are areas like performance optimization and power management that are true black arts: not high-level architecture but close-in work, just us applying our skill and experience to the problem at hand.
I’m proud to say I’m a developer, not an architect. Maybe someday we’ll solve all the engineering problems in software, and then we can all become architects. In the meantime, we have some well-crafted software we need to finish.
Adam Barr has worked at Microsoft for 13 years. He has been a developer, a program manager, and is currently a knowledge engineer in the Engineering Excellence team, working as an internal consultant and instructor to support the development engineering process.