A worthwhile lesson!

Miscellaneous Forums/General Discussion/A worthwhile lesson!

For anyone who, like me, is maybe a bit too obsessed with soft coding: This article will help.

http://worsethanfailure.com/Articles/Soft_Coding.aspx

Interesting article.

I love hard coding stuff. No-one ever reads it, and to me it's returnable to instantly. I've done some really epic stuff for calculating VAT - of course if the government ever changes the VAT rate, several of my production systems become instantly borked! But that's half the fun.

In fact looking back I should've hardcoded everything - because by the time someone else comes along to maintain that code, they generally do a re-write anyway.

Well it's wrong, but it's interesting none the less.

There are a few things that need to be put into external files with a "let the user worry about it!" idea, like tax rates.
For example, I'm helping someone by trying to hunt down the maker of (or any information on) an ancient accounting program called The BOSS so that its hard-coded tax rates can be adjusted. Alas, it seems unlikely :(

There's 20 years' worth of information in that program and it runs beautifully (it can do a detailed search through all of that data in less than a second)... too much to lose for such a simple problem.
Err, has anyone heard of it by chance?

In lots of ways, the writer is indeed wrong. A program like The BOSS should be built to last forever; it's a darn good program with practically the same capabilities as modern tools for small business. (Maybe better, in fact, since its UI doesn't look stupid :b).
In a case like The BOSS, which is made available to people who do not have the source code, anything that could possibly change needs to be changeable by the user in the event that the developer disappears.

So, yah, soft coding has it's places but that article made me suddenly realize that there is a line and it has been crossed when you start introducing LUA scripting so that you can manage simple game score rules "in a sane manner".

Interesting. I've kinda had a mix between the two for years with the emphasis being on soft-coding as I had to make configurable business software, but I tried to optimise the hell out of it so that the soft coding didn't slow it down too much.

There's 20 years' worth of information in that program and it runs beautifully (it can do a detailed search through all of that data in less than a second)... too much to lose for such a simple problem.
Err, has anyone heard of it by chance?

In lots of ways, the writer is indeed wrong. A program like The BOSS should be built to last forever; it's a darn good program with practically the same capabilities as modern tools for small business. (Maybe better, in fact, since its UI doesn't look stupid :b).


No, I haven't, but I have a great deal of experience of 'fixing' legacy systems without having access to the source code - in the past I've resorted to hex editing to fix stuff like this. Try searching for the current rates - it may take some time to filter out all rubbish but sometimes you can get it!

I think the reason I'm lazy with hardcoding is that I never take ownership of the source code.

Harcoding is evil. Every time I get lazy and do it I get bit in the butt - and deservedly so.

So let me get this straight here...

Harcoding - Code that doesn't make proper use of data files and or variables, and just puts all the information in the source itself, which is non-userfriendly to editing for anyone but the programmer?

yeah. Hardcoding = poop unless you are making a 64K demo or something.

Hardcoding keeps developers in jobs.

It also keeps them out of jobs.

Gah, Hardcoding is indeed a sin, especially in the application world! I've been developing VB / VBA 'software' for a few companies over the last 5 years or so, and my 'admin function' screens tend to end up bigger beasts than the actual tools themselves! So many variables to edit, lists to add / change, settings to tweak. Loads of fun! :)