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.

Conclusion

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.

Related Post

Leave a Reply

Comment Policy:

  • You must verify your comment by responding to the automated email that is sent to your email address. Unverified comments will never show.Leave a good comment that adds to the conversation and I'll leave your link in.
  • Leave me pure spam and I'll delete it.
  • Leave a general comment and I'll remove the link but keep the comment.

Notify me of followup comments via e-mail

Bear