Software is taken for granted.  Of all the things that humans can build, what else compares to software? An architect designs a house with known parameters, such as gravity, terrain, climate, plumbing specifications etc… The environment that a home is in may fluctuate, even to extremes, but a home will stand.  Houses are fairly standardized—they usually have a front and back door, x number of windows and all of the other usual features we expect from a typical home.

Enter a software application—the foundation on which it stands can change weekly via software operating system updates. There may be many entry points and exit points within an application—some of them are hidden to the software user.  There are usually hundreds, if not thousands, of dependent actions in a typical application.  Conversly, a home has a trivial set of dependencies:  you open or close a door, when it rains the water must flow into gutters, the trusses must be strong enough to support a maximum specified load etc…

There are many complexities that must be considered when architecting and managing a software application.  These complexities are often not fully realized.  Project managers, senior management, and potential customers underestimate the complexity of dependency—the intricate web of dependent actions and reactions that are required to enable a software application to deliver its advertised features.  To further exasperate the situation, developers often underestimate the complexity and magnitude of dependencies that they must account for to deliver a feature.  Let’s face it, the good developers are Creators of Software—in an almost Biblical sense. As such, the good developers are frequently overtaken by the power of creation at their fingertips and can easily underestimate the level-of-effort type metrics that managers need to estimate a project timeline.

To put it simply software projects succeed when all responsible parties understand complexity and human nature.  When developers are cognizant that they may not know what they don’t know, estimates become more accurate.  Managers understanding  a developers code-creationist mentality, can interpret their often optimistic  project estimations. 

Having software project managers that are intimate with code can be a great help as well.  Software cannot be created on an assembly line.  Trying to pump out code faster is not as simple as turning up the “speed” knob on the assembly belt.  Managers shouting down the line don’t increase productivity either with mind workers—typically this has the opposite effect. Performance anxiety is a code killer as with many other ares in life.  If a developer has a manager breathing down his or her neck—guess what their not going to be thinking about—code. A management team that understands these principles will pay big dividends.

 Remember the complexity/dependency discussion? This takes concerted concentration by developers in order to not “miss” anything when developing code.  Anything that interferes with a developer’s thought process lowers their productivity in the same way a factory worker’s productivity would decline if you added an extra assembly line belt for them to work on simultaneously.  Let the developer devote their mind exclusively to one task—writing code!  To supercharge this concept, provide developers with an atmosphere that mitigates thought process interruptions.  Most thought process interruptions are from co-workers or management inquiring about projects and/or adding new requirements.  The other, often not considered interruptions, are loud office spaces (i.e. conference calls on speaker-phone, high foot traffic developer work spaces, and even non-coders being located with developers which can increase office cross-talk).

Lastly, complexity must be managed and reduced where at all possible. The most elegant code, is very often not the most maintainable and understandable by anyone but the person who created it ( and often this isn’t true over time).   Disk space and processing power are relatively cheap—always write a few lines of extra code that lends to clarity over efficiency—if you like successful software projects. To mitigate complexity, write code that mimics life.  Code can mimic life by having flow control sequences that match the order of events that must happen in real life.  Objects can be created that match the real-world object (i.e. a file cabinet contains folders—folders contain documents, documents have paragraphs, paragraphs have sentences etc…).  In nature many seemingly complex processes occur, but when scientists study these processes, they find pristine simplicity.  To quote Albert Einstein, “Everything should be made as simple as possible, but not simpler.” 

The topics mentioned in this article are general areas that lead toward the success of software projects—but areas that are commonly overlooked. 

I admit, mother earth probably doesn’t have the warmest feelings for me (pardon the pun), but I do beleive that green technologies hold the promise of ushering in an era of ecological and economical salvation for humankind.  Why am I only”as green as I wanna be” you ask?  In most cases, being green just isn’t practical for gadget lovers and technologists.  I am not saying that being green isn’t important, but until being green becomes highly practical, not a headache to technology users, and performs as well or better than non-green stuff, the practice is not going to be adopted widely enough to make a noticeable difference. If a gadget can bio-degrade in a friendly way and be within the targeted price point, then I’m all for it, but where are these products?

Let me give you an example.  How many corporate workstation users deliberately leave their workstations on so that when system updates are pushed out overnight, they are already installed when they get to work the next day?  So, leaving my laptop on at work on while I am sleeping in bed (with it being set to hibernate) uses less electricity than the lamppost outside my door (with a 60 watt light bulb)—you know the one my homeowner’s association says I must have.  The laptop is putting my employer back less than 10 cents per day that I leave my laptop on outside of business hours. To the typical stressed out office worker, the 5 to 10 minutes it may take to boot up their workstation is worth much more than 10 cents, with carbon emissions a nascent thought. 

On a positive note, PC makers are using greener materials and I am all for that as long as it doesn’t affect my user experience in a negative way.  I mean, after all, we have been working hard to keep Moore’s Law going strong and Moore definitely isn’t helping on the power consumption front.  More transistors equate to higher performance and, with today’s semiconductor technology, more energy consumption.  Areas where performance has been increased without increasing energy consumption are in the use of mult-core processors. The same rules apply to the transistor counts in a core, but adding more cores improves the megaflops per watt consumed by a typical CPU.  While a little questionable in its reasoning, Wikipedia lists the MHz-to-watts  ([loosely]speed- to-power) ratios of all the main line consumer CPUs.  The wikipedia article demonstrates a point—if you note the Celeron line, typically used in mobiles, versus the Core 2 Duo processors, typically used in desktops, the speed to power ratio is much lower with the mobile CPUs.  Good for the green minded, bad for the performance minded.  

Some may be tempted to make the analogy between sports cars and the need for the extra power that typically doesn’t ever get used in commuter driving (so why would anyone want a sports car then?). Sports cars waist energy just idling at the stop light.  This analogy CANNOT be used with computer processors. Higher performing processors DO mean better application performance (assuming RAM and video are up to par).  An application user gets the opportunity to utilize the full power of the CPU much more so than a commuter with a tricked-out ‘vette.

Throughout the, often stormy, journey of deciding what I think I can contribute to  prospective employers, I have frequently pondered my job title.  Heck, I have even conferred with industry greats to glean what they would consider my most appropriate job title would be considering my interests, abilities, and aspirations.  I have often been ashamed of my very broad areas of experience.  The shame stemming from a self-contrived notion that not being a profound expert in one succinct area of IT made me a loser among geekdom. 

Over time, I have learned from managers, coworkers, and through self-observation that I am really good at making end-to-end solutions work—especially in areas where “no man has gone before.”  Fringe system integration solutions seem to materialize in my mind with relative ease.  Being very knowledgeable of many different IT technologies and approaches to integrating technology, as it turns out, does fit a job title pretty nicely.  I find that I am well suited to being an Architect.  While being an expert in every facet of an IT project is not typically a requirement—being really knowledgeable in most of the areas is very useful.  As an example—you might not need to know the most efficient method for executing a CRC checksum on a binary blob, but you must know that a coder on the project needs to develop an efficient method.   A broad swathe of technological know-how, the ability to communicate well, and an innate ability to lead make the best IT  Architects., in my opinion at least.

IBM has a very nice description of what an IT Architect is:

In terms of position in the organization, the architect is the technical lead on the project and should have the authority to make technical decisions. The project manager, on the other hand, is more concerned with managing the project plan in terms of resources, schedule, and cost. Using the film industry as an analogy, the project manager is the producer (making sure things get done), whereas the architect is the director (making sure things get done correctly). As a result of their positions, the architect and project manager represent the public persona of the project and, as a team, are the main contact points as far as people outside the project are concerned. The architect, in particular, should be an advocate of the investment made in creating an architecture and the value it brings to the organization.

The architect is also involved in organizing the team around the architecture and should actively contribute to planning activities as a result, since dependencies in the architecture translate to the sequencing of tasks and therefore the skills required at particular points in time. On a related note, since the success of the architect is closely linked to the quality of the team, participation in interviewing new team members is also highly appropriate.

So, I am happy to announce this shift in my professional repertoire.  For the near-term, a life of Architecture is where I will be focussing my attention.  I hope to meet many more Architects that might be out there along the way.  SHOUT OUT!