Comment On Soft Coding

The submission behind today's schedule article was withdrawn; instead, I'd like to take this opportunity to present the practice of Soft Coding. [expand full text]
« PrevPage 1 | Page 2 | Page 3 | Page 4 | Page 5Next »

Re: Soft Coding

2009-04-30 03:19 • by corlettk
259042 in reply to 131288
RaspenJho wrote: Someone had to do it....

Oh goodie! Now we've taken the perfectly comprehensible

private void attachSupplementalDocuments()
if (stateCode == "AZ" || stateCode == "TX") {
//SR008-04X/I are always required in these states

if (ledgerAmnt >= 500000) {
//Ledger of 500K or more requires AUTHLDG-1A

if (coInsuredCount >= 5 && orgStatusCode != "CORP") {
//Non-CORP orgs with 5 or more co-ins require AUTHCNS-1A

and turned it into XML... which ain't so comprehensible...



<CONDITION TYPE="ledgerAmnt" VALUE="500000" OPERATION=">=">

<CONDITION TYPE="coInsuredCount" VALUE="5" OPERATION=">=" />

... and we've moved those pesky hardCoded values to a hardcoded mapping method ...

object value =
cond.Type == "stateCode" ? data.StateCode :
cond.Type == "ledgerAmnt" ? data.LedgerAmnt :
cond.Type == "coInsuredCount" ? data.CoInsuredCount :
cond.Type == "orgStatusCode" ? data.OrgStatusCode :

Wonderbar! All we need to do know is write our own XML rules-mapping code-generator! ... and of course we'll need an rules-editor application to make that "XML programming language" look more like Java.

This way lies madness.... Please don't do it, unless you have a requirement to do so, such as maintaining a history of the business-logic, allowing you to repeat a particular process as-per the rules which where in effect at that time.

Signed: The humble maintenance programmer.

Cheers. Keith.

Re: Soft Coding

2009-05-22 14:21 • by David (unregistered)
Hello there,

my colleague always says: "I good developer is a lazy developer". Sure thing from my point of view.

Two examples from two different customers:
1) Customer: "everything has to be parameterizable within the database"- so we coded our solution that way.

First deployment: July 2002
First test if the did it right (customer changing some button texts and stuff): August 2002
Since then? Nothing- a lot of work (development and testing) for nothing- so much for mandatory configuration *gg*

2) Customer: "We want to change the labels and translate them into different languages". Our developers did their best and we ended up in about 2000 lines of xml-config. Guess what- the customer was not able to alter the right entries and therefore _we_ are changing translations and including them into subsequent releases of the software.

The point is- depending on the customer and the size of your project- be reasonable and do not use config because "software is done that way nowadays"- it isn't. Software ist supposed to solve problems, kept simple and mainly cheap (minor changes causing tons of money to be spent will tend to disappear- so there are no changes at the end of the day).

Why do we have that much frameworks, tools and scripting languages? Because writing software without something exciting and new is not interesting for the usual developer ("been there, done that")- so as long as you have this "proud" thing within development ("sure I can use O/R-Mapper X, but I need this and that and can code it in the same amount of time, I have to learn the API"), there won't be any substantial progress.

We are defying the same programming and design errors as our fathers did in the 70s, don't you think so?

At least I have no solution for this- maybe there is not (at least no deterministic ;-))).


Re: Soft Coding

2009-06-05 10:24 • by golddog (unregistered)
I think what Alex is strying to say is a good thing to keep in mind when developing: don't solve problems that don't exist.

For the example he shows, sure, when another state comes on, or we need to change the document type for one state, or something, we might revisit this process and rewrite it. Maybe we configure a list of states that need 048X and 048XI and check against that.

But, the fact is, these are the requirements. Don't make things unnecessarily complicated when there's not a legitimate reason to.

Some of the examples remind me of a developer at a previous employer who wanted to make everything "enterprisy". We used to joke that he would argue we'll probably colonize Mars some day, and since the Martian day is 39.5 minutes longer than the Earth day, we should allow for that difference in our code now. (Not as far from some of his arguments as you might think).

The point is, you make you best guess at the likelihood of change, rather than blindly add complexity. If you find later that these conditions really are pretty dynamic, it's just software, go ahead and refactor at that point.

It's great to anticipate potential problems, but don't assume complexity where there really isn't likely to be any.

Re: Soft Coding

2009-06-06 02:09 • by mzamora (unregistered)
I haven't read the five pages of comment (and I won't), but I'm just going to add how I see the whole hard vs. soft coding through my experience with pretty complicated software: financial services software that encode how to do business with all kinds of weird financial instruments, which are full of arbitrary rules and exceptions, which nevertheless can (mostly) be represented as soft code.

Hard code is OK when the rules are few, they don't change frequently, and the process is OK with involving the developer whenever a rule has to change.

Soft code should be used when any of the above conditions can't be met.

For example, picture the little 300-line hack evolved into the 50-file, 35,000-line monster in the course of four years. In this case, hard code is the main cause of bugs and broken business processes that cause 2:00AM calls to wake the comatose developer sleeping under the desk.

When the business rules in the application reach a certain level of complexity, a new level of abstraction can generally be applied to organize the rules. Then it's time to dump the old app --or the parts of the app that encode those rules-- after developing a new way to soft code the business rules which makes it more maintainable.

90% of the cases can be represented with soft coding without resorting to generalized data structures which are so over-designed that they turn into abstract exercises in intellectual onanism.

The really weird cases must be relegated to hard code, and if possible, should be done with code running in a sandbox that accesses the business data through a strictly defined interface.

Perl comes to mind (using anonymous closures), EJBs, Java stored procedures, etc.

In a nutshell, soft code can take care of the huge majority of rules in an efficient, maintainable manner. Hard code should be used with the exceptions, but that hard code should be isolated both in the build process and at run time, and closely tested and monitored (unit testing, sandboxing, etc.) to ensure correctness because they will be the source of most of the insidious bugs.

Re: Soft Coding

2009-07-20 16:49 • by veggen (unregistered)
Ummm... There's really no "soft/hard code" dilemma here. Have you heard of Drools? Jess?
There are times when you can't avoid changing the code, but this is not one of them.

Re: Soft Coding

2009-09-15 22:51 • by da nigga rie chea (unregistered)
285329 in reply to 131242
does zero really exist? does seven even exist? let me check my bible. . .

Re: Soft Coding

2009-11-19 21:28 • by c2d (unregistered)
291141 in reply to 131283
Actually your comment proves the exact opposite. If there are several definitions for BILLION, using it as a constant would surely create confusion.
Consider x = 60 * ONE_BILLION, what's the answer?
Is it 60 000 000 000 or 60 000 000 000 000?

Now consider x = 60 * 1 000 000 000.
What's the answer here?

So whatever you call that number, we can agree upon it's numeral expression. But if you used a define as suggested, we may expect entirely different answers and just end up talking past each other.

Supra Shoes

2010-06-19 03:09 • by (unregistered)
Supra shoes are so popular all over the world. Whatever you take on Supra being in the Supra Skytop Shoes market. Now Supra Strapped Shoes also very popular attention. It is nice that they actually took the time to make Supra Skate Shoes that work well. Supra shoes is a brand that has been inspired, designed and marketed by passionate individuals. We have brought to you the fullest selection of Supra footwear at cheapest price.

Re: Soft Coding

2010-08-18 14:13 • by xiaokj (unregistered)
Reading the scary full 5 pages, it is quite weird to see that Alex had been mostly absent from this forum debate. I hope to see a follow up.

I belong heavily in the soft-coding side, but I agree that this is in the grey area up for debate. Neither end is worth pursuing to their logical conclusions.

I think it is better to think of development methodologies. Agile methods would prefer hard-coding prototypes, and when the need arises, expand it into soft-code. Some other methods would argue for the other direction.

Although I would very much prefer soft-coding, I can see where the Agile method is hinting at, and I agree with that. However, I will only agree with the prototyping phase (or project is too small to warrant anything other than a prototype). Once the underlying method is working, I think I would rather see it soft-coded, albeit just a little bit.

After this huge amount of unsubstantiated opinion, let me add some meat to my argument.

If you see soft-coding as optimisation in the rule modification process, then you can clearly see how unwarranted huge architectures in soft-coding is premature optimisation. It is more important to make sure that your internal code structure works before you think of constructing your soft-coding behemoth.

Take the case of sendmail. It was born in a time when UUCP was the norm and each pre-network had its own mail syntax (the @ symbol was yet to be). As such, it had to soft-code the network characteristics in its configuration file or hard-code hundreds of cases. Common sense mandated the former, and culminated in the configuration mess. Later, it would be the same configuration mess that would doom the project against rivals -- the @ sign just gained traction.

However, if sendmail were not extensible, the internet would have had trouble forming because mail would not traverse borders. Not to mention that its extensibility allowed for experimentation with design, finally leading to the @ sign standard. The lesson to get is not that soft-coding is bad, but rather that extensibility needs taming, and that standardisation is important.

On the other end of the spectrum, look into the Art of Unix Programming Chapter 9 on Data Driven Programming. The preceding introductory chapters talked about complexity -- humans have trouble with complex algorithms, but are good at handling complex data structures. When the correct data format appears, the problems at coding solve themselves. Then, as promised, it expands on the idea in Chapter 9 with case studies, 2 of concern to the problem at hand are ascii and fetchmail.

Ascii is undoubtedly the most beautiful representation of simplicity in algorithm and code, yet it is entirely soft-coded. And the soft-coded part is entirely compiled and hard-coded into the binary -- the scope for changes is low enough to warrant that.

Fetchmail example, on the other hand, talks about using formal parsers to handle configuration, and the implementation genius is to, instead of copying another instance for the configuration-helper, use the nicely created parser for the main program to dump the parsed config for the helper. Centralised nice code without increasing complexity much.

It is clear that both sides are capable of monstrosities. Sendmail is a real disaster in its early days, but at least the disaster is mandated by necessity. However, it does not mean that soft-coding is inherently more complex than hard-coding -- ascii shows how the opposite can be the case, given clever coding.

I suppose we need to agree, on the other hand, that the example stated by Alex is horrendous. State laws are notorious to political whims and hence tend to be messy. If each state has 2 random demands, 20+(? I am not American, and I cannot be bothered to research minor details) states will mean 40+ overlapping conditions to code for. Slow-moving regulations will make it horrendous to push out changes in hard-coded values. A more sensible approach would be to cleanly separate out the state laws and allow for specialists to formally produce the configurations required, and send that out. Following the ascii example, it can be compiled, albeit into a module/internal state instead of the whole program. Flexibility as is required can be arranged for. Making it part of a database would, in this case, be uncalled for.

Nevertheless, the underlying idea that there is a limit to soft-coding is correct. Sendmail is my replacement example. Too much flexibility is also trouble for testing. Each binary yes/no option doubles the testing load -- exponential increase so that 10 options creates additional 1024 test cases!

As many had already said, we need some form of balance, and I suppose hard-coding a prototype is more than justified. If the prototype is more than satisfactory, there will be no need to soft-code. However, if some internal and variable threshold is overcome, soft-coding is much better. Especially when you find yourself repetitively apply fixes -- the codebase that needs repetitive fixes is more likely the source of the problem itself.

Now for some of my own attempts at the forum digression.

is horrendous-looking, but will save you when you realise that you actually meant WorkDaysInWeek 5 or 5.5 -- a global search and replace DAYSinWEEK to WORKdaysINweek is a lot easier than looking through for 7s all over the place. Happened to me.

is probably sadder than what I propose:
seconds = minutes * 60 // 60 seconds in a minute
i.e. I propose comments for this purpose -- constants extremely unlikely to change at all. This is because you might want to do it with undecipherable variable names as shown above with the object-orientated code -- suddenly you cannot even see that you are dealing with seconds and minutes when you have to navigate through the object structure.

MILLION and BILLION should be 1E6 and so on, with comments on why you are using them that way, as in the case above.

Re: Soft Coding

2010-11-08 16:15 • by x-sol (unregistered)
The Enterprise Rules Engine Revisited

Why does the word RETS keep going through my head?

Re: Soft Coding

2010-11-13 05:07 • by DriverDevel (unregistered)
329187 in reply to 131292

Always program as if the person who will be maintaining your program is a violent psychopath that knows where you live.

If you obfuscate your code to its fullest, then he'll never be able to figure you out anyway ;)

Re: Soft Coding

2010-12-23 22:51 • by anniepoo
One extreme version of this (or perhaps a separate antipattern) is localization.

Instead of the perfectly clear


you get

(I'm not kidding. that was the standard at a certain fortune500 company).

whenever possible I try to get 'stuck' with the job of localization so I can do the obvious thing - write a little preprocessor that replaces "stop\n" with "alto\n" driven by a file.
I've heard the objection that people might want to translate 'stop' into different words by context - in which case make it


and run the american english version through a 'translation' as well.

There's a general tendency for software engineers to be 'pound wise and penny foolish' - looking for optimizations in large and complex cases like needing to change a constant in context while ignoring simple needs like the need for the programmers to understand the code.

Re: Soft Coding

2011-04-05 22:22 • by Anonymous (unregistered)
343394 in reply to 131248
That's actually a really good example.

The simple scripting language in Steam Source games might not even be turing-complete, but the scripts allow a wide variety of customization.

Want to make the game entirely playable without a mouse?

bind j +left
bind l +right
bind i +lookup
bind k +lookdown

Imagine if this philosophy were used for stuff like text editors.

"Hmm, I use double-underline bold font a lot..."

bind "ctrl shift d" "toggle-bold, toggle-underline"

Yes, scripts are ''very'' useful for this sort of thing. They let you change not only a few constants, but the course of the entire program, just by editing a few text files.

Re: Soft Coding

2011-04-05 22:53 • by Anonymous (unregistered)
343395 in reply to 131395
GOF was, and never will be a WTF.

The fact that half of them would be unnecessary with a decent metaclass or prototype system is a WTF.

More related to your comment, the fact that everyone ignores the "drawbacks" section when deciding whether or not to use a GOF pattern, is a major WTF.

Something tells me that IDocumentAttachmentStrategy's implementors would take up way more LoC than a simple if/else chain.

And it still wouldn't be user-customizable. Unless they had a decompiler.

Re: Soft Coding

2011-06-18 23:12 • by JackSchitt (unregistered)
I've had to do something like this previously. The gotcha was that the business logic HAD to be in a separate file (as per the spec) which would be periodically updated by some manager separate from the deployment of the app.

The 1.0 release used windows scripting host. The .rules file was basically a .vbs file with functions that would be called by the app.

They decided (after something like 10 years of use) that editing rules in notepad was unintuitive and error prone. I took this time to migrate everything to .Net and now the .rules files are compiled the first time they are needed. The best part is that you can write the files in the VS IDE with intellisense.

It works, and it works well. If a rule needs some piece of information not provided by the standard params for that function, it can access the database as needed. There was even one case where a rule would consult an email inbox to determine it's course of action (it was for a special promotion where you had to email the company to take part).

Re: Soft Coding

2011-10-11 18:26 • by Susan (unregistered)
362852 in reply to 131242
Yeah, but this is missing the point. I'd prefer to read:

if (x < 7)

because it explains the 7.

You don't just have constants so you can change them, or to help you remember the value. It answers the question "WTF 7?".

Re: Soft Coding

2011-11-12 23:53 • by Powerslave (unregistered)
Yup. And I surely want to rebuild 40k+ file application just to change which particular document is linked with a given state or amount...
So-called configuration files did not emerge without a good reason.
You just need to find the correct balance.

Re: Soft Coding

2011-12-01 13:19 • by Nagesh
This is interesting article

Re: Soft Coding

2011-12-29 07:58 • by Nael Mahfouz (unregistered)
I liked your article very much. I disagree with nearly everything you have said but I think the article shows a lot of evenings trying to figure out bad soft coding.
The example you have provided is very simple and I agree that creating some form of business enterprise rules engine to handle this is overkill.
Your final paragraph is the ultimate in soft-coding. It is all about using metadata to reduce complexity, regression testing and code fragility to programmatically compile solutions.
There are intermediate solutions as well. Any code element executes an input, processing and an output.
If you factorise out the common denominators of these code elements in any given piece of work, normally there are only a few elements.
If sensible rules-driven metadata are used to describe the input, operation and output of the handful of code activities then the code remains relatively static (until new functionality is required) while the metadata changes need only unit/integration testing and automatically regression tests the code.
Finally, "soft-coding" allows you to reduce the amount of development from the product of variables to the sum of variables. If there are ten code elements with three operations each, there are thirty portions of code. With softcoding, there are only three pieces of code and ten pieces of metadata equalling 13 instead of 30 development activities. When you multiply this by several hundred times, the savings become enormous and the quality of the soft-coded codebase becomes impressive.

Where soft-coding falls down is lack of analysis and the use of convoluted and difficult to understand metadata. This is what I believe you are describing. But in this case the map is not the territory.

Re: Soft Coding

2012-05-29 10:25 • by toshir0

(for Akismet, spamming and pointless-thread-rezzing are the same, maybe ?)(if so, -1 shame point for this rotten pile of sh... brilliant software.)

Re: Soft Coding

2012-05-29 11:38 • by Ross Presser (unregistered)
382075 in reply to 131243
The advantage of sticking by rules like "Everything in moderation" is that you get to point your finger at anybody you like, saying they're being immoderate one way or another, without having to back up your statements.

Re: Soft Coding

2012-08-15 04:26 • by TJ Powell (unregistered)
387262 in reply to 131252
Speaking as a requirements expert - that would indicate that the "requirements" were simply not well-thought-out and written correctly to begin with. The current popular paradigm is start coding as quickly as possible, and change things as details emerge. Emergent "engineering". This is like building a house without a firm, well-constructed blue print - and leads to the same result. Chaos.

Re: Soft Coding

2012-08-15 04:31 • by TJ Powell (unregistered)
387263 in reply to 382075
It means, common sense must be deployed with respect to the amount of abstraction. Benefits and expense must be weighed in each case. Sometimes, when reuse is called for - a higher level of abstraction and runtime configurability makes sense. Most often, it is easier to simply write the code. I've worked on EXTREMELY complex space systems - and almost all the code is done inline. For a reason. Because a person can immediately look at the code and determine what it does. Sustaining engineering costs are always higher than original development. So that is where the emphasis in large systems should be. Far above any concern for "elegance" - which is more often than not, a euphemism for convolution. I still believe that many programs enjoy writing code that others have difficulty understanding. I attribute that to an ego malfunction.

Re: Soft Coding

2012-08-15 04:42 • by TJ Powell (unregistered)
387264 in reply to 387263
And I will further comment that most "interfaces" as currently defined, are often useless and indeed, confusing. The assumption of an immutable interface, where only the code changes MIGHT work if the system was well-thought-out, and planned to last for many decades in terms of reuse. But in software, this is almost NEVER the case. I've made a living coming in and cleaning up interfaces that were broken. Broken by inevitable change. (And I'm talking about repeated changes to the interface signatures themselves - See Microsoft). I get paid lots and lots of money to come in and clean up code written by developers who prize academics over productivity. At the end of the day, I actually get paid to throw out lots of unnecessarily abstract code - and write code that is maintainable, meets the requirements and eliminates crazy levels of complexity. Many of the "modern" paradigms have been created in academia by folks trying to sell books, and marketing departments trying to create a "brand".

Re: Soft Coding

2012-08-15 04:50 • by TJ Powell (unregistered)
387265 in reply to 387264
I define my state machines and transitions in a global module, in HARD CODE (so to speak). Not in a config file or database. If the rules change, I rewrite that piece of code and republish. Most of the time the users don't even see the change. It takes 20 minutes to rewrite, test and publish. And everyone who works on the system knows exactly where to go to find the data structure (one!) that defines the legal transitions. Since it is shared code, and it not splattered all over the database, it's simple - not accessible to the user, and we have readable, controllable, affordable and simple code to maintain. That is why one person (me) can write 800K lines of commercial code in less than 3 years, and sell it at a profit.

Re: Soft Coding

2013-07-02 10:34 • by UnkownDev (unregistered)
What I tend to do is hard code stuff that's unlikely to change.
When I'm not sure if it's unlikely to change or when it's not easily understand it I just write a little comment.

Unless I use it several times, then I create a variable with a meaningful name.

I tend to put values into variables instead of soft coding, figuring I will have to change the code anyway but by using variables it's quick and easy.

Soft coding is a great idea when applcicable, e.g. the amount of orders needed for a customer to get bonus points on the other hand things like statecode "AZ" is not likely to change in a long time, so you could just hard code it.

However, things like laws are a grey zone because laws tend to change.

Re: Soft Coding

2013-08-09 10:17 • by John C (unregistered)
This article, seems to me, to be mostly nonsense. If you have a DB, you can create one generic table that has a ElementID in it so that you can softcode all sorts of values that otherwise require coding changes. You can even build a maintenance program to allow admin users to update these values.

Our company has been using this method for decades now, and it continues to be a valid, flexible technique that is good for customers/users & programmers. It indeed, significantly reduces the need for programming changes and additional deployments.

I hope nobody follows this advice.

Re: Soft Coding

2013-11-02 09:46 • by ThunderGr (unregistered)
420392 in reply to 131259
Putting numbers into constants it is, still, hardcoding. Constants are meant to provide readability to the code *and* make it easy to change a value used in several places in the code, without missing any.

Softcoding, as described in this article, is *moving the values from the source code to an external medium(like a file or a database) that will be read from to a variable*.

Re: Soft Coding

2014-02-13 06:46 • by Rob Martins (unregistered)
Argh! I think there is a very careful set of decisions to be made around the creation of supporting sub-systems that handle logic, but the basic strategy is sound and part of an established philosophy of separating concerns.

As a Chief Architect I abhor the notion of cramming everything into one system. Stratify and give clarity to the purpose(s) of the system. We do it all the time. We have a presentation layer, a data layer, a business layer.
Some developers can't handle separation. They think everything should be in one place. If that's the case go back to one project solutions and see how you get on. It's crazy to work that way and smacks of poor experience. I simply can't fathom why anyone would not appreciate the elegance of sub-system that has a clear, central function. This means a developer can focus on the UI or Data without worrying about other parts of the system. It also protects more sensitive or technically complicated areas.

If the intent of a system coalesces into a distinct form, it is sensible to separate. That includes exposing common problems. Therefore if your logic is crammed into page(s) - and it is littered with IF THEN and magic numbers and order precedence is all over the place then you're doing something wrong in my book and ultimately making it harder to maintain. That code will become a mess. It might be easier to cut a first draft but you're kidding yourself in the long-term.

So, whenever I see a mass of logic on a page I cringe (you're right) and I think to myself surely you must have considered a system that does that work for you? Surely you can see that as the system grows, that code will become a mess.

The other factor I see daily is developers who plateau systems out because they either don't know that a supporting system could be created or they if they do, they consider it to be too abstruse to create one - they're not sure how. However, that doesn't mean it's a bad idea. It depends on what that system does in terms of supporting the development. If the end result is reduced effort in creation and maintenance of a system then it is worthwhile. That maybe be hard work but does not mean because you can't do it it's a bad idea. True some can't use the system either but again is that because it's a poor system or simply that they're not experienced to work with a formal logic sub-system. Maybe the sub-system can be made easier to consume.

Ultimately I want a developer to simply write less code and the configuration be as easy to maintain as possible. I don't see that creating a separate system that can handle logic necessarily means these things can't be achieved.

Re: Soft Coding

2014-02-13 06:48 • by Rob Martins (unregistered)
426998 in reply to 414745
I completely agree. I think it was written by someone who doesn't get architecture.

Re: Soft Coding

2014-02-14 05:34 • by Daniel Tress (unregistered)
Possibly the worst message you could give a new developer.

Re: Soft Coding

2014-02-14 16:20 • by Nic Battler (unregistered)
427147 in reply to 426996
I disagree completely.
« PrevPage 1 | Page 2 | Page 3 | Page 4 | Page 5Next »

Add Comment