There are several signs that make my shoulders sag if I see them when I start working at a new site. These are the obvious errors that there is really no excuse for. If you’re guilty of any of these in your code it’s time to hang your head in shame, pull your finger out and stop it now!
Category Archives: Best Practice
Just Say No to “Magic Numbers”
I’m serious, watch out for Magic Numbers, they will cause you no end of headaches if you don’t get them under control from the start. I’m not talking about the musical brothers and sisters from Hanwell, (although if someone could get them under control and convince them to stop producing bland music I’d be forever grateful). No I’m talking about those mysterious numbers that appear in rules and formulae without any apparent meaning.
Continue reading
Effective Testing Techniques
Last time we talked about the impact leaving testing to chance can have on your implementations (and it’s not good), this week we’re going to look at the different types of testing that you can use to give your testing the best chance of catching the defects it’s supposed to. Continue reading
4 Reasons Why Your Implementations Fail
Testing accounts for a significant part of any development effort. Estimates put this at between 50% – 80% of producing the first working version of an application. If the lifecycle of an application is considered from inception to retirement, then test and quality assurance costs are an even larger part of the total cost. Continue reading
Ten Steps to Make Application Migration Less Painful
Changing your toolset can be a headache at the best of times, but when you have multiple tools and potentially multiple platforms, handling large amounts of critical customer communications getting the migration right can become a juggling act of monumental proportions. Here are ten steps to take away some of the pain. Continue reading
Don’t Just Design Solutions For Clients
One of the first steps in any application design is to work out what functionality is required. Almost always (certainly in document design anyway) the only requirements considered are the client’s requirements, but think about this for a second. Who will be doing most of the maintenance on the application? Who will be investigating any production errors that occur once the application is live? Who is responsible for testing? You’ve got three additional stakeholders in the application straight away right there, how much thought do you generally give to the requirements of maintenance, support and testing? Continue reading