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.