Breathless Development

Breathless Development


As if projects didn’t have enough obstacles to successful completion, the ever-moving technology landscape leaves developers breathless to keep up, often needlessly rebuilding code that hasn’t even made it into production yet.

This article presents some of the reasons for breathless development and some of the things you can do to protect your projects from being damaged or delayed by it. The article is intended for developers and development managers.

Two main factors play into what I call "breathless development:" Hype anxiety and career anxiety. When vendors release new technology, they hype it relentlessly, which makes you feel like you are wasting your time building without it. As the technical journals begin discussing how to use the new technology, you feel that your skills are rusting and that you are being left behind. The difference between these feelings is subtle, but the end result is a rush to always implement the latest and greatest thing, regardless of how useful it really is for the problem at hand.

Hype Anxiety

Vendor hype instills a false sense of urgency. Vendors begin to hype their new creations well in advance of the production release, which starts your mental clock ticking. By the time the product is released into production, you are convinced you are already behind the technology curve because you aren’t using the new tool in your daily development.

Hype anxiety is particularly strong in less experienced developers because they don’t have the perspective that comes from being bitten severely and repeatedly by vendor hype. All too often, developers rush to implement the latest technology in order to "keep up," only to find that the vendor itself has abandoned that technology six months or a year later.

I’m afraid that the Application Blocks of the Enterprise Library is filling that role today. Anyone who implemented the January release had to have been frustrated by the incompatibilities in the June release, and now the next release for .NET 2.0 will drop and change even more features.

The problem is that developers see the Application Blocks as a product with a normal lifecycle, which it is not. The Application Blocks are really just a .NET technology and architecture demonstration. They are well worth perusing, imitating, and even incorporating, but once you integrate them with your project, you have to consider them part of your internal code library that only gets enhanced when you do the enhancing.

One way to avoid hype anxiety is to remember that everything you hear about a product comes from the vendor’s marketing department. Their job is to sell the new technology, and to do it right now, not after it has had time to prove itself. It is all about recovering the truckloads of money they just spent in the development cycle.

Career Anxiety

Career anxiety and hype anxiety are closely related, and they feed off one another. The bottom line with career anxiety is that you feel your skills are becoming obsolete. Well, in a sense, that is true no matter how good a job you do of keeping up. The same snobs that sneer at VB6 applications today will sneer at today’s .NET applications tomorrow. Technical evolution has no end in sight. Get used to it.

The trade rags add to this problem by focusing on new technology to the exclusion of the older technologies. Granted, there’s a lot more discovery to be done and techniques to explore in new environments, but people still need help solving business problems in the older environments. Unfortunately, the trade rags fuel career anxiety by making you feel like everyone is busily using the new technology except you.

Of course, not all career anxiety comes from external sources. Most developers are technologists to one degree or another, and your enthusiasm for learning new tools and environments is one of the characteristics that makes you good at what you do. Impatience with yesterday’s tools is natural, but self-defeating, when it comes to completing projects.

Preventing Breathless Development

After watching breathless development reach a fever pitch as a developer, a manager, and a consultant, I’ve identified a few techniques that can help remove some of the anxiety, at least temporarily:

  • When you define your project requirements, put a stake in the ground regarding the technology you intend to use. Fold new technology into your projects at the beginning of a new project or for a major enhancement only. Changing the underlying technology during development sabotages your architecture and inevitably extends the project schedule dramatically.
  • If you are incorporating new technology, identify areas where your team needs education, and plan for training time in those areas.
  • If your project plan makes assumptions regarding the use of technology that is critical to the success of the project, use prototyping to prove that your assumptions are accurate before you commit resources to development of core functions. Marketers often make it sound like their product solves all problems, and sure, you can drive a nail with a pair of pliers, but it won’t be a very good solution.
  • Closely related to the above recommendation, all new technology should undergo careful architectural analysis and proofing. Don’t believe vendor claims regarding the usefulness or reliability of new features, or you may end up rebuilding your application from scratch when those new features don’t work as advertised.
  • Deliver your project in phases, releasing core functions first and following up with enhancements that deliver important business value. This approach minimizes mid-project "technical obsolescence" and reduces the chances of your project being canceled due to a schedule overrun. Phased releases also give you the opportunity to incorporate new technology incrementally and in a controlled fashion.


Don’t give in to the hype. Remember that marketing drives the release of new technology. Apply technology that makes sense at the beginning of your project and push forward to a point of delivery. Only apply new technology at an opportunity when the value to your project is irrefutable.