Guest Opinion

When To Gamble on New Technology

Adopting new technologies can lead to dramatic new opportunities, but tried and true solutions shouldn't be ignored.

• By Billy Hollis
• 09/01/2008

I still sometimes use Datasets and DataTables in .NET, though some believe these technologies represent a simplistic approach to data.

That's OK. This industry has room for lots of viewpoints. Personally, I like proven approaches. Before I'll use something shiny and new, I must be convinced that it's better. Yet I also try to stay close to the leading edge to gain competitive advantage from the latest technologies. The project I'm working on now is based on Windows Presentation Foundation (WPF)/Silverlight, using Windows Communication Foundation (WCF) to transport data.

You might think it odd that I use a combination of such old and new technologies, but to me it's consistent with choosing to use something new only if I see a good cost-benefit ratio. I'm convinced that these new technologies are worth the time and risk involved in applying them to the new project. For example, WPF and Silverlight allow new user interface techniques beyond anything I could do with previous technologies.

I try to balance the tradeoffs between taking advantage of the new and preserving the value of the old. One way I do that is by using the concept of "good enough." For example, Datasets and other lightweight containers are good enough for many of my needs. This isn't always true -- sometimes I need to create complex business data objects for certain systems. But if lightweight data containers will suffice, I use them.

By contrast, the remoting/Web services combo isn't good enough when compared to WCF. I've never liked the programming models for remoting or Web services. WCF has a better model, and it includes many useful innovations.

"Good enough" applies to more than just technologies. I don't use any specific agile methodology either. My own process has similarities to agile, but its main advantage is that I've been using it for years, and it works for me. It's good enough, so I feel no need to change.

You might look at an agile methodology and decide to adopt it because you believe it's better than what you're doing now. But you shouldn't adopt it just because it's trendy.

Surviving as a capable software developer during continuous change requires you to do a balancing act. If you get excited by every shiny new thing that comes along, you'll sometimes fail when that shiny thing shatters into pieces as you put some stress on it. But if you wait too long to adopt useful new technologies or concepts because they're not in your comfort zone, you'll find yourself mired in the past. That's not good for you or your employer.

Here's a tangible example. Have you studied generics yet? You can learn to consume generic collections in an hour or two. From that point, any code you write to manipulate collections will be more concise, easier to read, and less prone to bugs. That's a great cost-benefit ratio for a new technology. Yet I know from interviewing developers that more than three quarters of them have yet to touch generics.

In contrast, Entity Framework (EF) is an interesting technology, but I'm not ready to jump on it. What I'm using for data access is good enough, and EF doesn't yet offer a compelling alternative. Besides, the last half dozen data access technologies from Microsoft have all been interesting. Will EF stick? Will it save you enough time and effort to impact your projects?

You might decide differently because your circumstances are different. Suppose you're starting on a brand-new team, and you don't have a good data access solution in place. In that case, investing more time to look at EF could make a lot of sense.

You'll enhance your value as a software developer if you learn to do cost-benefit analysis when confronted with new technologies. Adopting new technologies can lead to dramatic new opportunities. But never forget to ask: Is your existing technology good enough?