The Accidental Architect

By Michael C. Neel


Let’s paint a picture all too familiar among software developers.   You’re staring at a mess of code.- Jumbled loops and mammoth methods.  You’re wishing this wasn’t the result of your own coding.  It was never meant to be this big; this was a simple one-off app for Betty in accounting.  Betty loved it and asked for a few more features. No big deal right?  Then management wanted a copy. Soon the rest of accounting followed.  Now the CFO has decided to change the business accounting formulas and wants you to implement the changes.  Staring at the ball of tangled yarn and wondering how to fix it you may not feel like it, but you are in the role of software architect.

A building architect attends college for 5 years, spends two or more years as an intern and finally takes multiple certification tests before they can use the title.  In the world of software there isn’t even a half day orientation. Yet the choices in designing software can save or cost just as much time and money as a skyscraper blueprint.  I wish I could teach you everything you need to know to be a successful software architect, but I’m still learning myself.  I can however start you off with a few tips based on my own experiences.

 

Get some new friends


One thing you can do when you need to learn new skills is find people who have those skills and hang out with them.  By visiting this site and reading this article you are headed in the right direction. You can find more architects though local user groups, social network sites, or just by sending an email asking for thoughts on a problem.  Architects love to talk about software.
 

Sell out your current friends


You must, must, must (!) shift mindset from a developer when you are in architect mode.  Understand the needs of the business and customer intimately. Do only one of two things: save money or make it.  Consider the sin of buying verses building. Even though your inner geek will die a little inside when you say it.

I am a leaf on the wind


All the agile standup meetings in the world can’t save the project if the fundamental design is rigid and inflexible.  When designing software, think about what it will take to expand it, refactor it and ultimately remove it.  How will other pieces fit into it and how will they function if it is gone?  How will it scale to high demand and perform under load?  Consider these things but only design what is needed at the moment. Do more and you risk becoming the astronaut architect; a wasteful and costly being.

The cake is a lie


No Virginia, there is not one pattern to bind them all.  Since you are the good architect, one that will recommend buying a solution if it exists, you are only spending time on that which has never been built.  Since no one has built it no one can say which approach is best.  Truth exists only in code and is revealed only at runtime.  Write tests that go beyond error checking and into performance measurement.  Build small applications to test and measure one design against another.  If it were as easy as blindly following a pattern, you wouldn’t be needed!

Learn Spanish


You probably only work in one language and change languages when you change jobs.  As a developer this is okay but it’s unacceptable as an architect.  Learning another language gives you insight and perspective on software.  If you work in Java or C# there isn’t much merit in learning the other, as they both revolve around the same concepts.  I would recommend that a Java or C# developer learn C or C++ to understand memory management, a dynamically typed language like Python or Ruby to see the power of abstraction, and finally LISP just because it’s different from anything else you have seen.  Taking this a step further - learn another programming domain.   I enjoy learning game programming and artificial intelligence though I doubt I’d ever earn a living with either.

The good borrow, the best steal


There are many, many frameworks out there that cover things like data access, templates, caching and anything else you can think of.  Playing with each of them and using them in your solutions is a good start.  Seek to understand how and why they work. Then take those ideas and use them in your own software.

This is just a start.  I hope to use this space for deeper exploration of software architecture – sometimes in extensive code examples and sometimes just as food for thought.  I encourage everyone who disagrees, agrees, or has questions to leave a comment or email me personally at michael.neel@gmail.com.   Software architecture doesn’t happen in a vacuum. 
 

wirtten by Michael Neel

Michael C. Neel is a Digital Media Developer with Jewelry Television and independent consultant with ViNull Software. He is a board member and Vice President of the East Tennessee .Net Users Group (ETNUG) in his home town of Knoxville, TN.  Michael has been published in asp.netPro magazine and continues to publish .NET focused articles on his blog (ViNull.com) and at Devlicio.us with other community developers. An ASP.NET MVP, ASPInsider, and regular speaker at .Net conferences and user groups, Michael travels to most of the states surrounding Tennessee and organizes CodeStock http://CodeStock.org).