The world changes. Any application you build has to cope with change. Future-proofing is a frame of mind that equips your application with the flexibility to cope.
Good, clean design, modularity, separation of concepts, and good quality code, all make applications easy to change when the need arises. But future-proofing aims to reduce the need to change the application in the first place.
The biggest no-no I see, and have campaigned against endlessly, is where data is embedded directly in the code.
Some examples are obvious and clearly the result of short-sighted laziness. A programmer writes a routine to calculate tax, and sticks the tax rate right in the middle of the calculation. Why do that? You know taxes will change. The rate should be stored somewhere where it can be changed without having to delve into the code.
Better still, it should be something that a business user can change without involving application support at all.
Less obvious examples are more difficult to spot. The company name at the top of every screen and report, for example. Honestly, have companies never been know to change names? Make it a variable. It's just as easy. In fact, it's probably easier than typing the same thing over and over.
The real killers, though, are the constants that are so ingrained you don't even mention them in your design at all! For instance, what about all those monetary values with $ signs in front - are you sure that is fixed and forever? Try asking all those European businesses what fun they had when Francs and Deutschmarks and Lira gave way to the Euro.
My advice is to challenge any hard-coded value. Is it really fixed? Can you ever envisage a situation where it could change?
This is easily summed up as ... Constants are best regarded as variables.
Subscribe to:
Post Comments (Atom)
Posts
13 comments:
That's why that happened....every time our rates went up we had to do a fudge around until the system was adjusted. Hah!!!
I don't know much but I do know HTML code isn't something the average Joe usually wants to fiddle around with.
I am not at all computer literate, but dang! Ian, your posts are interesting and you're making it so easy for the non-techy reader to understand them!
Thanks, :-)
Assume noting is constant. :) The way you go about it sounds so much more user friendly. I'm a big fan of user friendly.
The rule I go by is if something can change due to people making decisions tomorrow or ten years from now, that data belongs in a table maintainable by said people, not in the software itself.
Delores, things like rates changing should be an easy-peasy thing to handle. This is what makes me mad, there's no excuse! :)
Nick, but coders are perfectly happy in that world, and they often don't see anything wrong in what they're doing.
Teresa, thanks, that's good to know :)
Jean, exactly!
Diane, as I've noted before, seems like you and I are on the same page here. And I'm a big fan of putting the business people in charge of their own data.
My comment is a little off topic... I read that you were currently living in BC. I grew up there and although it's not perfect, I miss it sometimes. I hope you and your family (including all your pets) enjoy it there.
Have fun with a-z.
I don't know anything about writing code, but you wrote your post in such a clear fashion that I understood the concept perfectly. Thanks.
I'm going to second what Elizabeth said. Well done! :)
Jessica, I guess nowhere is truly perfect, but we are enjoying it.
Elizabeth and Carrie, thanks. That is what I'm trying to do here :)
That all makes perfect sense now that you say it. I would have never thought of the ($) signs.
Dropping in from A to Z. This is my first year participating.
Brett Minor
Transformed Nonconformist
I just wish that people like you were the ones looking after our company systems. They keep promising a cleaner simpler faster way of doing things but the changes just seem to be inconsistant and complicated and slow things down.
What you say makes a lot of sense
Brett, for the Euro countries the problem ran much deeper than what symbol to display. They had to cope with parallel currencies during a transition period, often in systems that had no concept that there could be another currency!
Mynx, we suffer from a lot of that in our organization too. I am prone to comparing today with my previous companies where our internal staff were fully in control. What a difference.
Post a Comment