Making the code generic can make it easier to tweak things.
For example, if your footer includes a copyright and the year, then you can either hard code the year, and change it every January, or you can write some code to calculate the year, or you can have the code retrieve the year from some properties file.
Here the solution seems obvious; write some code to calculate the year, and never worry about it again. However, debugging this code may be more time consuming than a yearly trivial update.
If you want to be able to control the amount of ads on each section of the page, it's easiest to control this from a properties file. Then you do not need an engineer to update the code!
This seems obvious, but not always feasible. Sometimes the ads have some business logic behind them that would require huge amounts of code to handle a generic solution.
Another problem could be error handling. Do you assume the values entered in the properties file will always be there and will always be correct? What happens if somebody enters a capital-Oh instead of a Zero? (Is this 2O or 20?)
Adding error handling has its own challenges. If the values are wrong, what values do you use? Who does the code inform and how? (You cannot show an error on the page; imagine thousand of users seeing "Bill, there's an error in the x value". Chances are that everybody but Bill will see this.)
In the mid-1990's setups went from being written in Microsoft's Setup-Basic to becoming sophisticated in order to handle the requirements of Windows-95; uninstall.
Since we created a new SKU almost daily, it made sense to create the new setup system as generically as possible.
The result was the following:
- A code base that was too big for the debugger; so we could no longer "see" what the program was doing, and finding bugs became really difficult. This was because retrieving each value from a properties file requires many lines of code, to ensure it was fail-safe.
- A properties file that was over 1,000 lines long. That's a lot of control over the minor details! But it's also impossible to control; fine tuning setups via the properties file was very tricky and error-prone.
- Since Product Management and Marketing were very creative, they demanded new twists we had not thought of. Once they would decide on a 3rd party disk we should install, another time they added a registration screen and then it would be a registration code or a "time limited" edition. Each of these great ideas required writing new generic code and adding more lines to our properties file.
- Once we had the templates for all our products, setups for similar SKU's became trivial. Adding or removing a language was easy. The engineers in certain groups took care of the own setups.
As Project Manager, I always ask the engineers to write code keeping in mind that it may be need to be changed regularly.
- If it's something we know we want to test all the time, (like the number and placement of ads) then it should go into a properties file.
- If it's something we will tweak once or twice (like a font size or color, and an experimental object that we want to test and either keep or discard) then it should be easy to find and easy to change. Don't make this particular object dependent on others, don't make other object depend on it - and put some comment in the code to make it easy to locate, even in 6 months time when you no longer remember the code.
This creates some balance between the joys and pains of being generic and being hard coded.
And this is another example of the advantages of having Project Managers who used to be techies.
- Danny Schoemann
No comments:
Post a Comment