The Yin and Yang of software

As I was looking out of the window of my flight, I looked on to see the house and neighborhoods below and couldn't help but admire the beauty of the organization intertwined within the chaos and randomness of the surrounding environment.

I couldn't help but draw parallels to my own world, as a software architect for almost the last decade, as to how similar that world is to mine.

I have always struggled trying to clearly explain the difference in rules between a software architect and a software developer. Even more difficult has been trying to explain the difference between the different types of architects themselves.

Barcelona Spain. Bing Maps

A lot of people tend to think that an architect is something one becomes after they are the top level developer they can be, the next step up so to speak. That might be because the salary structure in our industry rarely values nor can properly price developers to begin with. That's a whole other blog post in its own, so we aren't going to get into that right now. It might be because some executive read a book, article or a blog (not this one) telling them that they need to start calling top developers architects so they won't leave their company. Whatever the reason, if it's not something the person is inclined to or wants to do, it will ultimately be a failure.

Carrollton TX. Bing Maps

Let's take an example from the construction world, lets consider the building of a home. The architect is the one who comes up with the design and the blueprints. They might work out all of the hard problems like load-bearing etc for the developer to take over and build. Let's call this guy the systems architect...I'll explain in a second.

Now the developer has the pans in hand is ready to build, he is usually working with the buyers or the realtor or both. Those are you product and business owners. They may want to have changes done to the structure of the home, so they can bring back the architect and work out its feasibility, but mostly they are ok with general direction the building is going.

They then turn their attentions to the features if the building, the kitchen, the bedrooms, the bathrooms and maybe the pool. Sure the developers can probably put an awesome kitchen together, but it may be overkill for the client. Even worse, they may listen to the client and end up putting in two double ovens because, well, it's cool. What they need is a kitchen designer (or a kitchen applications architect). That person has done it before, knows the trends and what's going to work when you want to sell the house later. That same person could just as well design the pool and patio area, or map out the electrical and plumbing lines, but that's usually left up their respective architects.

Great! Things are lined up, put on paper and are ready to go. Time to bring in the talent. That's right, I said talent. I'm not convinced writing code is a science or any form of engineering otherwise someone would've programmed a robot to do that by now.

To that end, there are different levels of talent and experience, just like there are different levels of developers. Some will be able to build you a kitchen that's eventually functional but will have warped counters and shelves, and others will build you a piece of art, on time and on schedule. Of course, there are many times more the former than the latter, but it's just like software in the end.

So, let's summarize so far, we have a systems architect that provided the main proportions and framework needed to build the home and guarantee its safety and adherence to code. The application architects are the ones providing the designs and guidance for the parts of the home like plumbing, electrical, kitchen as well add the fun stuff like overall curb appeal and maybe even the pool. The realtor and buyer are the product and business owners and they might even have a project owner keeping things on time and budget. They primarily deal with the lead developer, who can jump in and hang drywall and build a cabinet, but is more interested in making sure all the other developers are staying on track and doing things right the first time. He is also the one who had to explain why they have to repaint the cabinets because they didn't drill the holes for the handles first. Or he might point out to one of the architects that there is a better way of doing something that he may have heard of or tried somewhere before. Finally, all the building itself is done by developers, who would range from apprentices to master artisans.

Great! But there's still one kind of architect missing, the enterprise architect.. Where do they fit in in this example. Well they are the city planners. They work with all the different parts of the community as a whole to put together regulations and plans. You could make the streets a single lane wide, since that's all you need, but you'll never get your trash taken away. You'll never be able to get water in and out of that home if the water and sewage companies didn't have a clear easy way to work with you.

So, there you have it, Architects and Developers, the Yin and Yang of the software and two parts of the equation. They really are two different things each with their own merits and skills. I personally don't think one is a transitional position from the other, but each has their own paths and levels that grow and flourish just like any other career. So, if you're a developer, treat your code like your art; refine it and become that master artisan that produces work of art time and time again. And if you're an Architect, learn to find and appreciate your Developers and listen to what they have to say. In the end, neither can work independently of each other nor will your clients come back to you for more work in the future.