The Web Gambit

One of the cornerstones of the Agile Manifesto is Responding to change over following a plan. 

Most of the time, we see this parable being applied to teams of software developers, but not always to the software itself.  After a certain point, the software’s architecture becomes rigid and inflexible, and only allows for minute changes to its supported feature set.

This becomes especially true later in the software’s lifecycle as its code base matures.  As time passes, most software packages need to be substantially rewritten to support new technology changes.  Such changes can include:

• Newly supported database platforms (e.g. SQL Server to Oracle and MySQL)
• Changing the presentation layer to support a different platform or go native (e.g. Web to WPF and Silverlight)
• Changing the application service layer platform (e.g. J2EE to .NET and RoR)

When designing your product architecture, it is easy to remain platform agnostic in some areas, while exceedingly difficult to do so in other areas.  Additionally, most organizations are limited by time, money, and the expertise of the developers writing the software and thus make quick decisions with limited resources.

Database support is usually the most flexible part of most application architectures as it is considered a best practice to support the big three database platforms.  While this may result in losing some performance benefits specific to a database, most developers are willing to sacrifice these benefits to avoid the excruciating pain later on when support for more databases is injected after the software has been released.

Presentation layers, on the other hand, can be notoriously inflexible as most platform evangelists tend to emphasize Rapid Application Development through the use of platform specific tools.  While these tools can help build a demonstrable application quickly, they sacrifice a great deal of flexibility to do so.  By emphasizing the use of less visible code, these tools tend to hide the inner workings of large sections in the application’s architecture.  Thus it is difficult for any developer to successfully emulate the patterns implemented by these tools when the time comes to change platforms.

Service layers are generally the most difficult to flexibly design as this layer is generally composed entirely of platform specific code.   The good news is that of all the pieces of technology that compose your architecture, the Service Layer is the one which tends to have the longest shelf life.  The degree of difficulty involved in changing Service Layers leads most organizations to only change this layer once per decade.  I believe that a degree of inflexibility in this layer is probably unavoidable in most situations.

Expecting to develop a code base that is flexible to every one of these changes is an ideal situation that is nearly impossible for most organizations. 

In turn, most developers are likely to be more successful if they can limit their scope to one platform and leverage the platform specific capabilities to build more efficient, solid code.  Introducing an unfamiliar platform to inexperienced developers can result in enormous costs and heavily impact productivity.

However, there are significant advantages to making your architecture agile as it can make you better prepared for unforeseen changes down the road.  These changes may include:

• Requests for new platform choices from customers
• Emergence of a competitor with greater platform support and thus a wider audience
• Staff changes resulting in gained or lost technical expertise

Building a more Agile architecture is indeed a daunting task, but I firmly believe that the benefits outweigh the risks.  If it may not be possible to make your first product architecture an Agile one, the lessons learned from building it should certainly be utilized when building a second, more Agile architecture.

Further reading:

Jeff Palermo’s blog post – Focus on the Core

Refactoring Databases: Evolutionary Database Design

Rob Walling had an amazing post where he described his experiences and frustrations during his career when moving  from senior software development roles into management roles.

Much of Rob’s frustrations stemmed from losing the creative satisfaction one gets from writing code despite gaining the money, power, and respect generally associated with higher level management roles.

This post struck a chord with me because I had many of the same thoughts while I was a management consultant.  I saw many colleagues that were great developers become terrible managers.  Many of these former developers were so accustomed to the fine degree of control one wields with code that they had forgotten that people are not as easily manipulated.  Out of frustration with this loss of control, many of these former developers resorted to becoming Taskmasters and were very disrespectful to their subordinates.  Much of the reason I left big consulting was because of not wanting to go down the same path.

However, things are not all bad for those who aspire to get to management but have some anxiety about not coding.  I have recently met a few rare individuals who are very successful at both the management side of things while still feeding their creative side by doing some programming work on the side outside of their management-based day job.  The work they do on the side may be in the form of User Group Contributions, Open Source Contributions, or just general on-the-side consulting work for friends and former colleagues.

It’s been my experience that these types of managers are generally even better at their day jobs because they stay connected to the technology they are managing and are often very involved in the communities revolving around the same technology.  Additionally, they often have less trouble finding and hiring good developers due to their large people networks.

As one would expect, such outside activities usually require sacrificing some personal time.  But they give an individual the creative fix of coding while providing the prestige gained by going into management.  So for those who are willing, it’s a very good option if you can survive with a little less sleep