Home » none » How to evaluate technology choices

How to evaluate technology choices

H02C0011 My post yesterday about an easy way of implementing templated e-mail was met by a comment suggesting that using XSLT would allow for more flexibility.  Which is true.  Once it was suggested, I started asking myself, “but is it the BEST method of implementing templated e-mail?”

I think, as programmers, we tend to think that having more options, having more flexibility, using the latest and greatest technology, is always best.  But is it?

Here are a few reasons why it might not be:

Time to market

This is probably the overarching reason why choosing an option that allows for more options might not be the best choice.  As technology people, I think we tend to forget why we exist.  If you are getting paid to program, the point is to help your employer make money.  You have two ways of doing that: producing something with as few bugs as possible so that the customer won’t be put off by the failure of your program to perform, and spending the least amount of time on your code possible.  If your choices of technology, methodologies, and practices don’t achieve either of those goals, you are doing your employer a disservice.  If you have a choice between two ways of doing something and one way clearly meets the goal with less cost, that is the choice you should take.

Increased Risk of Bugs

Strongly tied to time to market is the increased risk of bugs.  If you’ve been programming longer than 3 years, you should know by now that more complex code increases the chance that more bugs will be introduced into the application.  This will increase the cost to maintain the system and may delay the release to production.

Increased End User Training

Think about who is going to use the system.  In the case of templated email, I need to consider who is going to be editing the email.  Will it be someone who knows XSLT?  How long will it take to train them?  Those were both significant reasons for not using XSLT and relying on something more straightforward that did the job equally well.  This is not to say XSLT is a bad choice.  You might answer the questions differently for your organization and end up using XSLT.  There are some strong benefits for using it and if the people who will need to make the edits already know it, it may be foolish to not use it.

Does more than what is required

When I was a young programmer, I always programmed for the future.  Having managed a few young programmers, I’ve found that this is common.

Trying to program for every possible bug is good.  Programming extra code to support a future feature is just plain dumb.

If a more simple approach achieves the current goals, use the simple approach.


The problem with these tests is that a technology that is “best” for me and my organization might not be the best for you and your organization.  Programming and the technologies and methodologies need as much thought as to what we will choose to use as the thought we put into the code we end up writing.

Programming is fun.  New technologies are fun.  But if we forget why we exist and write only for ourselves, we may find ourselves looking for new employment.

Like this Article? Subscribe to get every article sent to your email.

Related Post

  • Some days, technology is more trouble than it’s worth.Some days, technology is more trouble than it’s worth. As I sit down to write this morning, thinking about what I could write that would be valuable to you, the only thing I can think is, “Blah, I have nothing in me.” But why is this?  […]
  • Renaming Properties, Methods and VariablesRenaming Properties, Methods and Variables Have you ever written some code and named something one thing only to realize that it should be named something else?If you haven't you haven't been programming for very long.  Maybe […]
  • Reflecting ParametersReflecting Parameters I got a question last week from a gentleman asking how to tell what parameters were available for a particular method.  This is useful when you know that a method will be available on […]
  • Copy And Paste And BugsCopy And Paste And Bugs We all do it.  I’m sure of it.  It’s too easy. I need code that looks almost like something else I wrote so I just copy and paste it over to the new code.  Done. But at […]
  • DotNetNuke Modules – Creating Base ModulesDotNetNuke Modules – Creating Base Modules Now that we have DotNetNuke installed into Visual Studio we can go ahead and create our first modules. Actually, creating the modules is pretty simple. But it is even easier to do it […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer. His commitment to quality through test driven development, vast knowledge of C#, HTML, CSS and JavaScript as well as his ability to mentor younger programmers and his passion for Agile/Scrum as defined by the Agile Manifesto and the Scrum Alliance will certainly be an asset to your organization.