• (cs)

    Business rule values are always inevitably bound to their behavior. Configuration options don't do here. Best thing maintainability-wise is probably to separate the entire set of business rules into it's own set of files, values and code included. Maybe one can call it some sort of layer... A tier, even. I'm a genius.

  • Brendan Dowling (unregistered)

    This is the best article yet. Seriously. A set of resources that define the runtime behavior of the program is basically another set of code, only one that is written in a weird application-specific language. Deploying an EXE is exactly the same amount of work as deploying a new set of data files. Generally you're going to distribute them together because otherwise the number of combinations will explode (imagine v1.0 exe with v1.2 data). Testing the application is the same amount of work whether or not the code exists in the EXE or in data files. Debugging is harder because there is code that comes from configuration files and chances are you didn't build a debugger for your homegrown data language. As others have said, using a dynamic language like Perl, Ruby, Tcl, Lisp, Scheme, can allow you to easily have runtime loadable code if you think you might want it. But implementing functions that execute data based on rules is a huge waste of time.

  • Eanna Butler (unregistered)

    A set of "config files" can also be used to generate code. The code then doesn't interpret the config files at runtime, rather source files are generated from the "config files", compiled, and deployed. I like that idea. Works for lots of things, but obviously not everything! Makes repetitive tasks easy, makes for standardised source code adhering to a predicatable style and pattern, can make debugging of the generated source simpler, can make for highly-performing code, or rather code that doesn't run like a dog, and often makes for simpler deployment processes. An obvious shortcoming of generated code is the maintenance of:

    • generated code (generation is rarely round-trip - i.e. to edit generated source rarely will alter the config that generated the source. If Debugging is (a) finding bugs, and (b) fixing bugs, then code generation will make finding bugs easier, but fixing the bug harder)
    • the generator(s) (often means lots of effort, or effort by a team of well-established developers) While the author proposes that Soft Coding doesn't suit Business Rules at all, the use of configuration outside of source when it may be a customer requirement is then .. a requirement. This typically holds when
    • the software is a product that is delivered to multiple customers, rather than being a bespoke development
    • the software release cycles are long
    • the target industry is fast-moving Fundamentalism, and hard-and-fast rules, are both designed to sate the uninterested, the thoughtless, the inexperienced, and the unintelligent. Much of the articles on the web about programming take the fundamentalist route, which demands criticism that extends beyond the content and into the philosophy that drives the content. I like the author's viewpoint, that programming languages are business-rule containers. However, I find the idealism presented within misleading to those who aren't practised. In an ideal world, one single approach would work for everything. We do not exist either in an ideal world, or in a world of idealism, and while we attempt to control the microcosm of our software world, idealism unfortunately does not work in this context.
  • JM (unregistered) in reply to mav

    Funny you bring this one up. I had this exact example on a project (COBOL based) about 20 years ago where the requirement was to process payruns on Tuesdays until the end of time.

    The developers refused to do this even though it was a legal requirement because they'd have to "hard code" all future dates which were Tuesdays into their module (there was only one affected), and the Team Lead came over to gently put me right about modern development techniques.

    After I pointed out the mod-7 trick above, he went off perfectly happy - "chuffed" actually, because it was a neat trick he hadn't seen before.

    They still hard-coded the '7' and the '2' (the week begins on Sunday) though.

  • Jones (unregistered)

    Very, very good article indeed. I used to be responsible for maintaining and debugging a platform that could have been simply implemented with Java, but no, of course it also included all kinds of differently formatted config files, XML files and also some configs in database. It really made me think about the correct level of abstraction. And yes, it is not an easy puzzle to solve!

  • bRain Man (unregistered) in reply to Therac-25
    Therac-25:
    Oh yeah, this was covered 26 years ago:

    The only way to implement an extensible system using an unsuitable language, is to write an interpreter for a suitable language and then use that one. -- rms, 1981

    That's neatly rephrased in Greenspun's Tenth Rule: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

    And of course, due to Zawinski's Law, it will also read your mail.

    I think I might like to try a different approach for my next application. Start with an MUA written in Common Lisp and hack it until it also does whatever else I need.

    -L

  • tastey (unregistered) in reply to Ebs2002
    Ebs2002:
    I always cringe when OTHERS cringe #DEFINE NUM_DAYS_IN_WEEK 7

    This has nothing to do with the value changing, but about readability.

    Ebs2002:
    #DEFINE ONE_MILLION 1000000

    Agreed, silly.

    Ebs2002:
    #DEFINE NUM_SECONDS_IN_MINUTE 60

    This has nothing to do with the value changing, but about readability.

  • bcammack (unregistered)

    I think it's safe to say that the lesson is to know why you are coding what you are coding the way you are coding it and have captured all of the necessary information to make an itelligent decision on how to do so.

  • (cs)

    I had an intro programming professor who preached what he called "the rule of three":

    If you use a value more than three times across your module(s), it should become a named constant; if you use a section of code three or more times, it should become a function. That seemed to strike a balance against overly generalizing into "soft coding" while realizing some of the performance benefits of "hard coding".

  • Not Dorothy (unregistered) in reply to Chris
    Chris:
    The equation for the area of a circle is not subject to change. So that would be like a business rule that would be hard coded. Maybe which documents to attach or whatnot are not business rules but business variables. Worse are config files that aren't documented and then it's like the whole freaking app is one gigantic linear doomafalache.

    If I remember there were some Christian fuckwits in Kansas (it's always Kansas) that wanted pi to be 3 because of something in the bible, so no you couldn't hardcode this, in fact you couldn't use the constant PI in your calculation.

  • Asd (unregistered)

    Most readers seem to be missing the point: this is not about defined or inline constants, it is about configuration/overly data driven apps.

  • foobish (unregistered)

    I just can't get myself to agree with this article.

  • B. K. Oxley (binkley) (unregistered)

    A beautifully written article.

  • sionide21 (unregistered) in reply to Justin Buist
    Justin Buist:
    Ebs2002:
    #DEFINE NUM_DAYS_IN_WEEK 7
    If you're counting from 0 it could be 6.
    No it would still be 7. 0 to 6 still spans seven numbers.
  • (cs) in reply to gerrr
    gerrr:
    Some people do take their anti-hard-coding bent too far.

    /snip Things that are only being used within a small scope, or only used once, usually do not need to be constants.

    I wish you were the one I inherited code from instead of the person I really did. :-)

    The (Delphi) code is full of things like:

    const bUsePrinter = True; bUseScreen = False;

    procedure DoReport(Data: Whatever; Destination: boolean);

    And in the calling code:

    Res := MessageBox('Click OK to print, or Cancel to preview', mtConfirmation, [mbYes, mbNo], 0); if Res = mbYes then DoReport(intData, bUsePrinter) else DoReport(intData, bNoPrinter);

    I really, really hate it! :-)

    (And yes, the other WTF-worthy stuff is really there too.)

  • Therac-25 (unregistered) in reply to sionide21
    sionide21:
    Justin Buist:
    Ebs2002:
    #DEFINE NUM_DAYS_IN_WEEK 7
    If you're counting from 0 it could be 6.
    No it would still be 7. 0 to 6 still spans seven numbers.

    This whole conversation deserves to be a WTF of it's own.

  • Glazius (unregistered)

    Hmm.

    This looks like a job for an IDocumentAttachmentStrategy.

    Or has GOF stuff become WTF now?

    --GF

  • JTK (unregistered) in reply to Not Dorothy
    Not Dorothy:
    Chris:
    The equation for the area of a circle is not subject to change. So that would be like a business rule that would be hard coded. Maybe which documents to attach or whatnot are not business rules but business variables. Worse are config files that aren't documented and then it's like the whole freaking app is one gigantic linear doomafalache.

    If I remember there were some Christian fuckwits in Kansas (it's always Kansas) that wanted pi to be 3 because of something in the bible, so no you couldn't hardcode this, in fact you couldn't use the constant PI in your calculation.

    Actually, it was Indiana, and it had to do with bad and lazy mathematicians, not Christians, no matter what your opinion of them.

    See http://www.straightdope.com/classics/a3_341.html

  • (cs) in reply to brazzy
    brazzy:
    Designing and implementing programming languages isn't really something most coders have a lot of experience in.

    which is a shame, because what do you think you are doing when you do any (non-trivial) programming? People have mentioned Greenspun's Tenth Rule, which I actually have never heard of. What I have heard of is the saying 'Ask a computer scientist to solve a problem, and he will come back with a language perfectly designed for solving your problem in'. Ok its probably an old maxim, which probably felt more true back when you had to have a high level degree to even look at a computer. However both sayings are really trying to say the same thing. This is not meant as a bad thing either.

    However, I can't really back the main article. Many people have allready pointed out the problems in coding. Really there is never an excuse to not put that hardcoded value into a constant defined at the top of your file. However, the article does seem to imply that it has more to do with configuration files. Yes, there is such a thing as having to many config files spread over to many places. In fact, you're config file will probably be defined in a config file if you're not carefull. This tells you that you probably have a bad design. probably.

    However, there is almost never an excuse for hardcoding. Certainly not 'my app won't be used more than once' (or any small number). How many legacy apps/scripts exist that were only meant to be used once?

    What it all comes down to is good design. Seperate your business logic from your presentation, etc., etc.. Avoid use of modern design and patterns simply to be using modern designs and patterns. Not everything needs to be in a config file, but unless its 0, put constants where they belong. It improves readability and maintainability. Yes, even if you use them only once, because maybe you only thought that when you started. No to mention that if you have to change the value of Pi, it's easier to do it in a defined consant the searching your file for it. Maybe not much easier, but still.

    Oh, and all rules have exceptions. except this one ;}

    Just one more thing. If your system, designed to make life easier, requires an expert to use it, maybe it's because the subject matter is difficult enough to warrant an expert. Otherwise you did something wrong.

  • JTK (unregistered)

    I remember a class with Marshall Kline (of the C++ FAQ) who recommended a serious soft-coding approach for certain types of problems. But, he also offered this line of wisdom: Look at how the Good Lord designed your arm. It only has three well-engineered joints, which still offer an almost complete range of flexibility and movement. If you were missing an elbow, say, then your arm would be almost useless. But, if you added a couple more joints, then you wouldn' have an arm -- you would have a noodle.

    Only add flexibility exactly where you need it.

  • (cs) in reply to Hardy
    Hardy:
    qbolec:
    I've once worked for a company, where the Q&A complained about the use of 'magical constant' 0 in the for loop:

    As if your QA dept actually looks at code!?

    Some QA departments actually take their task seriously and try to Assure the Quality of the product. That includes doing both black- and white-box testing and their own code reviews. Not very damn common, but it does happen.

  • brey (unregistered)

    What these people fail to realize is that they just moved the code into the database, so they were writing a compiler to execute the code in this database. I've seen this before and it failed miserably (except for my company which was billing by the hour to create this monstrosity). What a mess!

  • Corporate Cog (unregistered)

    Holy moly, let the worms proceed forth from the can. My code base used to have the exact same lines (obj.stateCode == "TX"). I centralized all the instances of states into one unit and added a function so that the calls changed to stateOf(TEXAS).

    I suppose that's too soft...

  • Loren Pechtel (unregistered)

    Count me in the group that favors constants.

    The ONE_MILLION one is garbage--no constant should be named like that, one million isn't meaningful. Rather, it should be named what it's for.

    Yes, you can do the same thing with comments. Think the comments will be up to date, though? My philosophy is that in almost all cases the only thing to comment should be algorithms or externals. If you need any other sort of comment the code isn't clear enough. Note that this occasionally means moving code into a procedure just to put a name on it but so what?

  • eyrieowl (unregistered) in reply to brazzy
    brazzy:
    No. The point is that if you really do a good implementation and follow through to the logical conclusion, you end up where you started: you're writing your logic in a fully-fledged programming language, changes need to be tested and you probably have a non-trivial deployment process.

    That's an unsupported assertion, one that I think is provably false. If you follow your logic to it's "logical conclusion", there is no point to any language other than machine language. After all, they're all just languages sitting on top of that. Clearly, though, higher levels of abstraction do have value and even you likely don't code machine code by hand. The point to any language that sits on top of a lower level of abstraction should be to provide useful abstractions that make doing common tasks easier. That's the fundamental reason why programming languages exist. It is definitely not the case that every problem requires a full-fledged programming language to solve. My example of computing an IRS 1040 is a perfect case in point. Externalizing the logic of the 1040 to a document that is read by a processor in no way requires a full programming language. The set of operations required is much more limited and specialized. So making an assertion that externaling logic leads inevitably to full-fledged-language-horror is just wrongheaded.

    brazzy:
    And if you DON'T do it well, you end up with a hideous monstrosity of a language. Designing and implementing programming languages isn't really something most coders have a lot of experience in.

    Which entirely misses the point I made -- just because something can or has been done badly doesn't mean it shouldn't be done. You or someone you know might not be the best person to solve a particular problem, but that doesn't mean no one is qualified and should attempt the task. Most coders I've met are terrible system architects, but that doesn't mean there aren't good architects that you should have designing your system. Likewise, externalizing logic requires a certain skill and has an art to it--if you lack that art, don't assume everyone else does and that the approach is therefore flawed.

  • Greg (unregistered)

    You're thinking inside the box. There is a middle ground between a general purpose language (i.e. hard-coding) and throwing stuff in config files (i.e. soft-coding). That middle ground is a domain-specific language (DSL) which is used to generate code. You make it easy to write the business rules in a reasonably straightforward and natural way and make generating the code (and compiling it) part of the build system. As long as you don't try to make your DSL too big or your generator too smart, you're in good shape. It's still code, but it's code in a higher level language.

  • Elsp (unregistered) in reply to joe_bruin

    http://en.wikipedia.org/wiki/French_Republican_Calendar#Ten_days_of_the_week http://en.wikipedia.org/wiki/Discordian_calendar

    Perhaps you should rephrase that:

    "There are always seven days a week when I choose which calendar to use"

  • (cs)

    I use "soft coding" to create a framework for simple web forms. Let's say you are writing survey software and you have three clients. Each client will want different questions. So you have to create "components" for them to administer. You give them the textbox, radio, checkbox, textarea, dropdown, etc. components and they can all add/remove their own questions from their own surveys. This can all be database driven to store the type of component, some unique name, and possible answers.

    I would think most web programmers have done something like this or toyed with the idea. It's quite useful and not very complicated. You aren't rewriting a programming language. Instead of editing the code, typing a new question, creating a new <select> box, and adding a column to the database you can just have an admin page to update the database.

  • Corporate Cog (unregistered) in reply to kanna
    kanna:
    Put a 60 in the code and comment it.

    Come on, who can seriously deny that the code itself should act as the comments as much as possible?

    Strange that such a comment would be posted.

  • James Taylor (unregistered)

    Wow - where to start. An article that asserts that because something can be done in a stupid way it must be a stupid thing! If it was really easy to just change the code when the business rules changed, no IT department would have a maintenance backlog (and, in case Alex hasn't noticed, most do). Ask not if you can code it but if you should! Longer reponses on my ebizQ blog. JT www.edmblog.com

  • lackluster (unregistered)

    I'm a little surprised no one has brought up the Model-View-Controller methodology and the multitude of frameworks that use XML config files to establish that methodology. Personally I'm all for the separation of business logic, and have reaped the benefits numerous times when redeploying existing applications for businesses sharing few similarities. They typically merge both hard-coding and soft-coding techniques together quite nicely. For instance rather than defining DAYS_IN_WEEK, you would call a function to return that number for you, and the function that was called would be defined in the configuration file. This is handled quite nicely through event-based implicit invocation, a hallmark of several MVC-based frameworks.

    An Introduction to Software Architecture

  • Rexxar (unregistered) in reply to Elsp

    At work, we use a time tracking software in which a day has eight hours and a week has five days. In the previous version it was "one day = 24 hours" and "one week = 7 days" and it was unusable.

  • Zygo (unregistered) in reply to tster
    tster:
    Boolean Check_AZ_TX(string stateCode)
{
    if (stateCode == "AZ" || stateCode == "TX") return true;
    else return false;
}

    First off, this isn't object orientation and it has nothing to do with it. Secondly, I can only hope and pray that you aren't serious.

    1. If you are going down this road you have set yourself up for MASSIVE code duplication. If you don't want code duplication you can do the following:
    boolean check_TX_AZ(String state)
{
    return(check_TX(state) || check_AZ(state));
}

    otherwise you can end up having duplicated code literally hundreds of times.

    That's silly. You don't want to know about which state you're in at all. You want to know which states have some requirement that requires different business logic. So name the function after that requirement:

    boolean state_has_Smarmy_Bletcher_law(String state)
{
    return state == "TX" || state == "AZ";
}

    If a new state implements this law, you change the above method. If the forms required change, you implement change the below method:

    String[] forms_for_Smarmy_Bletcher_law()
{
    return [ "SBL-2003-1", "SBL-2003-2" ];
}

    and most likely you'll immediately want to write:

    void attach_Smarmy_Bletcher_forms(Document d, Context c)
{
    if (state_has_Smarmy_Bletcher_law(c.getState())) {
        d.attach(forms_for_Smarmy_Bletcher_law());
    }
}
  • Zygo (unregistered) in reply to JM
    JM:
    Funny you bring this one up. I had this *exact* example on a project (COBOL based) about 20 years ago where the requirement was to process payruns on Tuesdays until the end of time.

    The developers refused to do this even though it was a legal requirement

    Who or what, by an act of legislature, must be paid on Tuesdays?

  • Zygo (unregistered) in reply to CrazyOnYou
    CrazyOnYou:
    I had an intro programming professor who preached what he called "the rule of three":

    If you use a value more than three times across your module(s), it should become a named constant; if you use a section of code three or more times, it should become a function. That seemed to strike a balance against overly generalizing into "soft coding" while realizing some of the performance benefits of "hard coding".

    #define three 2 #include "parent"

    There, I agree now.

  • (cs)

    I've worked in more than one industry in which code changes require a great deal of regulatory approval, but configuration changes don't. Part of the "Hard Coding" versus "Soft Coding" evaluation involves the consideration of those kind of constraints (or the lack thereof). So the "best" answer for the same functionality in different industries may be different, even if the language is the same.

  • Dirge (unregistered) in reply to Zygo

    This article really made me lose a lot of respect for Alex, and question the quality of the other writing on the site (which I've been reading for quite some time).

    I'm sure it's often possible to get away with the sort of hackish, fast-but-crappy coding he promotes when it's internal to a company. It's still terrible.

    End users of a program should never have to change the source code and recompile just because data (like which states require a particular form) has changed. Source code gets lost. If you buy a product, you probably don't even have the source code.

    Oh, wait, maybe the end users should agree to disassemble and hex edit the program because that would save the developers from actually having to do their job and develop the program properly.

    What a bunch of lazy, poor developers in this thread. If you want to be a crappy hack that writes unmaintainable code, at least have the decency to acknowledge it and use a scripting language instead so that people can clean up your mess when (not if) it becomes a problem.

  • (cs) in reply to tster
    tster:
    wrong, There are 7 days in a week if you are using a calendar that specifies that there are 7 days in a week. Indeed, calendars besides Gregorian calendar exist.

    And all of the ones still in use (I refuse to count the Discordian) have either no week at all or a 7-day week. The last one to survive more than a year that used any other week was the French Revolutionary.

  • Marginal (unregistered) in reply to Elsp
    Elsp:
    http://en.wikipedia.org/wiki/French_Republican_Calendar#Ten_days_of_the_week http://en.wikipedia.org/wiki/Discordian_calendar

    Perhaps you should rephrase that:

    "There are always seven days a week when I choose which calendar to use"

    Fine. When you find an organisation that does business on either of those calendars you can come after me with a big pointy stick. Until then I'll continue to assume that there are 7 days in a week.

  • Marginal (unregistered) in reply to Dirge
    Dirge:
    End users of a program should **never** have to change the source code and recompile just because data (like which states require a particular form) has changed. Source code gets lost. If you buy a product, you probably don't even *have* the source code.
    Straw man. No-one is suggesting that the customer recompile.
    brazzy:
    chrismcb:
    What is easier to deploy, a new set of dlls or a new database file?

    What is easier to test a new dll or a new database file?

    What is easier for the customer? Update thier data, or wait for the vendor to release the new version

    Your deployment process must really suck if you see a big difference here.
    This is the key point. Move some logic out of "code" and in to a "data" file (or domain-specific scripting language) if you like - but when you come to change that logic you're still changing the behaviour of the program. So you need to test the change with the same degree of thoroughness irrespective of whether the change is encoded in code or in data.

    The difference is that when the logic is encoded in a data file you are implicitly encouraging your customer to change that data file - so multiplying your testing by n.

  • barf coding (unregistered)

    I always felt that code should be something that looks nice, and not only to you, but to another developer. Not only that, it should do what it was meant to without kludge. There should be no excessive use of complex coding concepts when they are not needed. A lot of people want to flex their programming muscles, and therefore misuse code all over the place in order to feel superior and show off their elite knowledge. Soft coding is a wonderful example of that, but I can't say that I am exempt from misuse... It's a constant process trying to find a happy medium, or a constant process to understand the tools you have been dealt. With new development abilities on the rise (such as LINQ) people are bound to abuse and misuse, and to further progress ways of doing things efficiently and eloquently as well. I have a feeling we all generally end up on both ends of the stick!

    In the end though, if I can't clearly communicate to another developer what my code is supposed to do, then I might of failed in the process of what I was trying to accomplish. I want to write something, that when read by another, they can relate.

    And then the process of passing the torch becomes less painful. Frameworks, patterns, and the such help to eliminate it a little, I guess. But in the end, I think we want something that most eloquently states what we were trying to accomplish, and sometimes too much hardcoding can turn a good idea that might of made a good short story into a burdensome repetitive novel. Happy balance, hard to find.

  • barf coding (unregistered)

    oh, and business requirements. A lot boils down to business requirements.

  • Stevenovitch (unregistered)

    Uh huh, if anything this post and it's comments prove that a lot of you need to be a bit more open minded, as half of you vigorously claim to have the one true answer and manage to be more righteous than the other half with the other one true answer.

    Confucious says: be liberal in the input you accept and conservative in the output you emit.

    Also, if you really have a way to know the "one true answer" for every situation regardless of exterior considerations then please write me a book, as I'm tired of weighing the endless number of contextual factors that go into producing this code crap.

  • Mandor (unregistered)

    As someone who both admins and codes, I find this article horrifying. It sounds like it was written by someone who has the luxury of writing code and not actually maintaining systems and code over the long term.

    First off, making everything configurable should be really "cheap." Most languages have some sort of framework for making things easily configurable. Even if your language doesn't have such, you will have to develop one for the cases that are inarguably hardcoding. Once you have an infrastructure for easy configuration, it should be really cheap to make everything configurable.

    Secondly, from a full lifecycle perspective, often the things that change are not the things that you anticipated upfront. The more things that are configurable, the easier it is to make changes during the lifecycle of the program. Sure, some changes will require a recompile, but by putting as much as is reasonable in a configuration file, you minimize this.

    Also, as others have observed, in many environments, it's a lot easier to get permission to change a configuration than to change code. Code changes require careful testing, since coders tend to break things; config changes also require testing, but can be more easily backed out.

    And also, "recompiling" is not always a simple matter. After N years, the compilers, tools, and platforms might themselves have changed, such that even recompiling original source might not produce new binaries that behave identically to the original binaries.

  • Beltira (unregistered) in reply to Ebs2002

    NUM_DAYS_IN_WEEK, ONE_MILLION, and NUM_SECONDS_IN_MINUTE will yield better results when grep'ed on as well as the first reply points out that it avoids typos and adds clarity to hard values.

  • Watson (unregistered) in reply to Therac-25
    Therac-25:
    These discussions about date constants are rather odd -- does anyone still do date math themselves? Aren't there solid date and time libraries in every language? I haven't used anything except Date::Manip in Perl and the forest of inheritance trees of objects in Java to do this stuff since I was bitten the first time (there are at least two days in the year (in my locale) that aren't 86400 seconds long....)

    Date/time arithmetic is merely the canonical example; the problem domain is widely recognised; there's the potential for lots of magic numbers (like 60, and 146097) that are either not obvious, or ambiguous; and calculations that it's easy to botch. Which is why there are libraries. Written by alien civilisations far superior to ours. Thank goodness we humans never have to write libraries.

  • Anonymous (unregistered) in reply to gerrr
    gerrr:
    Some people do take their anti-hard-coding bent too far.

    I have worked on programs where everything that would be a string literal or number in a formula is turned into a constant. It makes it ridiculously difficult to figure out what is going on because you have to constantly search and hunt for where the constants are defined. (because there are several hundred)

    You don't use 'ctags' or 'etags'?
  • Rhialto (unregistered) in reply to cparker
    cparker:
    One billion could equal either of the following:

    1 000 000 000 1 000 000 000 000

    Conversely, 1 000 000 000 could be read as "one billion", "one thousand million", "one megamillion", or "one milliard".

    Yes, for instance in Dutch,

    1E06 = miljoen 1E09 = miljard 1E12 = biljoen 1E15 = biljard 1E18 = triljoen 1E21 = triljard etc

    although such large numbers are not usually pronounced :-)

  • pb (unregistered) in reply to Justin Buist

    It doesn't matter where you start counting. Even if you start from 42, the number of days in a week will still be 7.

  • speaking of wtf's (unregistered)

    ok thats enough. To imagine that users of software cannot "change business rules" is just indicative of how out of touch Alex is with real use of real software. Alex is truly his own web page, "worse than failure."

    Moron. And your forum software sucks.

Leave a comment on “Soft Coding”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article