Extracted from:

The Developer’s CodeWhat Real Programmers Do

This PDF file contains pages extracted fromTheDeveloper's Code, publishedby the Pragmatic Bookshelf. Formore information or to purchase a paper-

back or PDF copy, please visit http://www.pragprog.com.

Note: This extract contains some colored text (particularly in code listing).This is available only in online versions of the books. The printed versions

are black and white. Pagination might vary between the online andprinter versions; the content is otherwise identical.

Copyright © 2010 The Pragmatic Programmers, LLC.

All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, ortransmitted, in any form, or by any means, electronic, mechanical, photocopying,

recording, or otherwise, without the prior consent of the publisher.

The Pragmatic BookshelfDallas, Texas • Raleigh, North Carolina

Many of the designations used by manufacturers and sellers to distinguish theirproducts are claimed as trademarks.Where those designations appear in this book,and The Pragmatic Programmers, LLC was aware of a trademark claim, the desig-nations have been printed in initial capital letters or in all capitals. The PragmaticStarter Kit, The Pragmatic Programmer, Pragmatic Programming, PragmaticBookshelf, PragProg and the linking g device are trademarks of The PragmaticProgrammers, LLC.

Every precautionwas taken in the preparation of this book.However, the publisherassumes no responsibility for errors or omissions, or for damages that may resultfrom the use of information (including program listings) contained herein.

Our Pragmatic courses, workshops, and other products can help you and yourteam create better software and have more fun. For more information, as well asthe latest Pragmatic titles, please visit us at http://pragprog.com.

Cartoons courtesy of Mark Anderson, reproduced with permission of the artist.http://www.andertoons.com

The team that produced this book includes:

Brian P. Hogan (editor)Kim Wimpsett (copyeditor)David J Kelly (typesetter)Janet Furlow (producer)Juliet Benda (rights)Ellie Callahan (support)

Copyright © 2012 The Pragmatic Programmers, LLC.All rights reserved.

No part of this publication may be reproduced, storedin a retrieval system, or transmitted, in any form, or byany means, electronic, mechanical, photocopying,recording, or otherwise, without the prior consent ofthe publisher.

Printed in the United States of America.ISBN-13: 978-1-934356-79-1Printed on acid-free paper.Book version: P1.0—February 2012

Essay 4

The “Ivory Tower” Architect Is a Myth

I’ve never liked the idea that technical architects should stopcoding.

In physical architecture, architects perch in an ivory tower,living in a world of only planning. They don’t hammer inthe nails or solder joints together. Requiring architects to dothe physical work of drilling holes and laying concrete issimply impractical. Architecting and developing are twodistinct career tracks.

The Corporate Ladder Leads to Less Code

In our industry, we work our way up to the role of a techni-cal architect by actually developing—bydoing the “physical”work of building applications. But inmost organizations, aswemove up the software development ladder, wewrite lesscode. We immerse ourselves more with planning than withdiscovering the problems on the front line. We concernourselves more about an overall vision and less about theintimate details of code. As an industry, we’ve held on tothe notion that architects should plan and developers shoulddevelop.

This creates the false perception that once we’ve reached acertain level, programming is no longer where we’re mostvaluable. Just leave the dirty work to the junior developers!At the same time, it pushes lower-level programmers awayfrom thinking about the overall goals and direction of theproject. They’re asked to concentrate just on the implemen-tation. The architect-developer model makes both partiesless accountable for the application as a whole.

When we split up roles into the somewhat arbitrary hierar-chy of thosewho think about the technical “big picture” andthosewho think only in if statements, for loops, andmarkup,we fracture two disciplines that belong intimately together.

• Click HERE to purchase this book now. discuss

Pure technical architects can take a guess at the best architec-ture, the best design pattern, or the best practice. It’s onlywhen they’re knee-deep in code that they discover wherethe real challenges exist. At the same time, the developerwho isn’t given the reins to think at a high level also doesn’tget the chance to voice a second opinion. Often, it’s the guywho’s doing the actual implementation who can see thebumps ahead most clearly.

We’ve taken the architect-developer analogy too far. Thecorporate ladder in the software industry needs a betteranalogy.

To build a building, architects architect and developersdevelop. Traditional architects knowhow to create elaborateplans and specs in fine detail. But they don’t build. It’s sim-ply not reasonable. The separation between thosewho thinkat a high level and those whowork in the trenches is largelyfor practical reasons.

In software, it doesn’t have to be that way. Great developerscan live both “in the trenches” and “at a high level” at thesame time. Sure, an architect might spend most of her timethinking at a high level, but she should be involved in devel-opment a little to get the full picture.

Making Time for Code

In many technical organizations, what I’ve proposed thusfar just isn’t feasible. Most technical architects have a full-time job in meetings with other groups in the company.They’re often brought in to client phone calls to discuss allkinds of technical challenges that face a software project.Where’s the time to code, anyway?

A fewmonths after I started one of my full-time web devel-oper gigs, we hired a new senior architect. Adam came inand set a very different tone among our group of youngwebdevelopers. Despite all the normal duties he took on in hisrole, it was clear his passion lived in code. Immediately, Ifelt like I was talking to just another programmer, albeit onea lot smarter and wiser than I. Our architect-developerrelationship became my personal mentorship.

6 •

• Click HERE to purchase this book now. discuss

On our first project, an extranet for a major law firm, Adammentioned something about code generation. To me, itsounded a bit sci-fi. However, as I would soon find out, theunderlying server-side objects, queries, and methods I wasgoing to write by hand were mainly algorithmic. We couldlargely deduce them from the extranet’s database schema.Instead of plodding ahead with a brute-force approach todevelopment, Adam suggested I focus on building outcustom forms and screens while he began writing a codegenerator. He did this for a fewweeks on his one-hour trainride to and from the office each day. In a few weeks’ time,we had a rudimentary but powerful tool to generate a lot ofthe stuff I would’ve written manually.

Whatever time we lost with our little divergence into codegeneration,we quickly recouped aswe began using the codegenerator. Each timewe changed our database schema, he’drun his little magic app that would rewrite all the code Ineeded to keep building the application. Itwasn’t long beforethe effort Adam made in writing his tool more than paidback the cost in writing it. And this was a tool we could useagain and again.

So, while I was still very much the lead developer on theproject, Adam had a large stake in the development. If Ineeded some different bits of algorithmic code, he’d workon adding those features to the generator on train rideshome. The next day, I’d have a fresh set of code that Iwouldn’t have to ever write by hand again. Much of what Ilearned in those first few months I keep with me today.

As you work your way up the programmer chain of com-mand, from developer to architect, don’t forget that code isthe glue that binds each role. It may not be a train ride.Maybe it’s an hour or two you can devote, at work, to onlywriting code. You’ll seeways of committing yourself to code-only time in Essay 23, Create “Off-Time” with Your Team, onpage ?. In the end, regardless of where you are in thedevelopment hierarchy, keep coding. It’s where you’re mostvaluable.

• Click HERE to purchase this book now. discuss

The “Ivory Tower” Architect Is a Myth • 7