The Deadly Cycle or Keeping up with the Latest Technologies

As we progress through another year as Software Engineers, I'm starting to sense an alarming trend.  Please indulge me as I explain, if you are a software architect you are responsible for picking the right technologies to construct your system, to do this effectively you really need a fairly in-depth knowledge about the existing technologies or building blocks that are not only available today, but what is also available as either a CTP or beta release.  Now you pick the right technology and start constructing your system, let's say it's not a huge system, but it isn't trivial either, let's say you have a cycle time of 6 months.  As you build your system (and you picked the right technology) you will gain the experience necessary to master the technology, and if you planned it right and with a little luck, by the time you are ready to ship, they beta release you were working with go golden so you are set!

Now you are off to your next effort and design and build a project using your newly acquired expertise.  Another 6 month effort, great solution and everyone is happy.  What's happened in the past year?  Well, another new cycle of technology came out requiring even more detailed understanding.  This new technology may be so fundamentally different that your previous experience may now be obsolete.

Let's look at this another way, you know that about 1 year from now a fundamentally new technology is coming out, you need to build something, but you don't want build it off of a technology that will be obsolete when that technology so you hold off for the new technology.  Well your not shipping or even working on your product until you can get a stable CTP, even with that you run the risk of the API's changing by the time your technology goes live.  So you find the right time start constructing your system get a few months into it and -whammo- you see another technology that would be just perfect for your implementation that is really mutually exclusive to the technology you selected.  What do you do?  Just wait another 6 months for that technology to ship?  Probably not...

What are some things we can do to minimize the impact of new technologies?

Keep up with the absolute bleeding edge of technology.  There are many ways to do this.  In the past I only attended one professional conference a year.  Starting last year I attended two conferences www.medc2006.com and www.devconnections.com this year I'll be attending Dev Connections both in the spring and the fall, also MEDC 2007 and MIXX so this year it will be four conferences, with the incredible number of new technologies being release it really only seems like the best way.  With the new technologies coming out there are usually a number of important subjects within that technology.  These conferences aren't really a good way to get a mastery of the technology however it does give a good overview that will let you know the key parts.  These are also good for determining what is real and what isn't.  As to this point, there really isn't a substitute for experience.  How many times have you been to some sort of session or demo where they say "Build an enterprise site within 10 minutes with no lines of code"?  Well I've got news, as Frederick Brooks says in the Mythical Man Month, there's no silver bullet.

Another way that I think we can attempt to isolate ourselves from the rapid change in technology is to focus on the data.  Even if you choose to implement an SOA architecture (what ever you define that to be) when it comes down to it, at some point the rubber is going to meet the road, your going to need some objects with properties and method that actually does the work.  The way you factor these objects may be the biggest factor as to how well you can adopt the latest technology and put the latest and greatest user interface or offer the functionality provided in your objects as services.

Something that may be an option, but I haven't been able to practice is move away from coding.  Even though some people make it look easy building non-trivial software is hard and complex.  Things that look good at 50,000ft start to fall apart if you can't also understand how they work at the 1ft level.  How many times have you worked with the architects in the ivory towers that haven't coded in years and establish the all encompassing architecture that looks good on paper, but when you have to start building those objects with the properties and methods just falls apart or you create way too many lines of code.

On a final note, we need to start thinking about the software develop as business assets, not just lines of codes and assemblies.  What we develop should try to be at the right level of granularity for the task at hand.  If we build our projects where the majority of the business logic is in the UI, well we may have something we can sell and ship (which is by no means a bad thing) but we really don't have something that we can glue together using the latest technologies.

I'm sorry I just can offer any "silver-bullets" here but sometimes recognizing the problem is half the battle.  I think that we as software engineers need do the best we can to keep up with the latest technologies, invest a significant amount of time reading and researching new technologies and last an probably most important keep our customers and end users in mind.  If we do this things will just fall into place, our products will ship and we will start developing the goal of not just developing software assets, but business assets.

-ec