Excellent workflow




  • The last article on the front page, which shows
    what basically amounts to assembly written over VBA, reminded me of this story
    from my first job.

    The project we were working on involved validating insurance forms and checking which the available products were available to the, erm, "insuree" (my English is failing me here), along with doing some risk assessment calculations and stuff.

    These were complex business rules I mostly tried to avoid thinking about because a) they were completely out of my field of expertise, b) they were meant to be changeable, as the experts should be able to adapt them as they see fit, and c) the person on our team who was collecting the rules from the experts and turning them into something we could use, wasn't me.

    We used a visual programming language which looked like this:

    In case you've never used a visual programming language, it's pretty simple. There is a bunch of icons on the left you can drag to define your workflow ("If", "Switch", "Query", etc.).

    You can use those user-created orange balls on the right. They are called "actions" and they correspond to functions/procedures on a traditional language. They can be configured with their input/output/local variables, you can specify if these variable contain a string, a record or a record list, etc.

    In short, it's nothing you wouldn't figure out on your own the first time you saw it.

    You'll also note there is an "Excel to Record List" icon on the left. This loads an Excel file and returns a record list. You can iterate over record lists using a "For each" icon.


    Now, cutting short what is becoming a long post, what happened was this: the girl who was dealing with the business rules figured it would be impractical to hardcode the rules and have to recompiled and redeploy the project every time there was a small change (this was a sloow process).

    So instead, she put all the rules in an Excel spreadsheet. She made it so that in her workflow she would iterate over every row and, switching on the value of the second column (the "Action"), she would either set a "Row" variable and restart iteration until she found a row with a value on the first column matching the "Row" variable, or call the action matching that name. Each action would be passed the appropriate values from either the spreadsheet columns, local variables from the main workflow, and/or variables from the insurance form. It could also return any values to be set back in any variables outside of it.

    In other words, she had created her own opcode interpreter, with the opcodes coming from an Excel sheet. And to boot, the implementation was well structured and used sensible actions too!

    All in all, I don't really think I could do any better than she did, given the limitations of the platform, but I must say: this was a brilliant example of ingenuity, coming from a person who - to my knowledge - had zero education of computer science.



  • Marry her.



  • @Daid said:

    Marry her.
     

     

    And breed with her.



  •  Meh, she's probably a horse.



  • @Zecc said:

    In case you've never used a visual programming language, it's pretty simple.

    @Zecc said:
    So instead, she put all the rules in an Excel spreadsheet. She made it so that
    in her workflow she would iterate over every row and, switching on the value of
    the second column (the "Action"), she would either set a "Row" variable and
    restart iteration until she found a row with a value on the first column
    matching the "Row" variable, or call the action matching that name. Each action
    would be passed the appropriate values from either the spreadsheet columns,
    local variables from the main workflow, and/or variables from the insurance
    form. It could also return any values to be set back in any variables outside of
    it.

    Doesn't that defeat the purpose of using a visual programming language? She went from something every business user could simply use, to a new programming language in Excel. What's wrong with using C# then? It's more visual than Excel because it is included in Visual Studio.



  • @bjolling said:

    Doesn't that defeat the purpose of using a visual programming language? She went from something every business user could simply use, to a new programming language in Excel. What's wrong with using C# then? It's more visual than Excel because it is included in Visual Studio.
     

    I agree. She may have used the tools well, but she still managed to surpass the Second System Syndrome and discovered the Third System Syndrome.

    Having the "redeployment" of a rules system made explicitely for end users buried under The Processs seems like the Real WTF to me here. Isn't the whole point of visual programming languages that small changes can be done quickly, even by people with zero expertise?



  • @bjolling said:

    @Zecc said:
    In case you've never used a visual programming language, it's pretty simple.

    @Zecc said:
    So instead, she put all the rules in an Excel spreadsheet. She made it so that
    in her workflow she would iterate over every row and, switching on the value of
    the second column (the "Action"), she would either set a "Row" variable and
    restart iteration until she found a row with a value on the first column
    matching the "Row" variable, or call the action matching that name. Each action
    would be passed the appropriate values from either the spreadsheet columns,
    local variables from the main workflow, and/or variables from the insurance
    form. It could also return any values to be set back in any variables outside of
    it.

    Doesn't that defeat the purpose of using a visual programming language? She went from something every business user could simply use, to a new programming language in Excel. What's wrong with using C# then? It's more visual than Excel because it is included in Visual Studio.

    I believe the purpose of anything done in a visual programming language is to defeat the purpose of the visual programming language. A worse idea I cannot think of.

    Kudos to the non programmer who created a CPU emulator in excel and the vpl. Now all we need to do is implement a C compiler to run on her emulator and we'll be all set!



  • @PSWorx said:

    @bjolling said:

    Doesn't that defeat the purpose of using a visual programming language? She went from something every business user could simply use, to a new programming language in Excel. What's wrong with using C# then? It's more visual than Excel because it is included in Visual Studio.
     

    I agree. She may have used the tools well, but she still managed to surpass the Second System Syndrome and discovered the Third System Syndrome.

    Having the "redeployment" of a rules system made explicitely for end users buried under The Processs seems like the Real WTF to me here. Isn't the whole point of visual programming languages that small changes can be done quickly, even by people with zero expertise?

    I would infer, given the hint of "recompiling" being a real sloooooow process, that the girl arrived to the same conclusion some Unix and Perl devs have arrived: text & CLIs are quicker to compile, modify and maintain than GUI-driven stuff.

    Of course, there are a couple of GUI-driven languages that are fast on the compile side (last one I remember is Authorware) so it may not be always the case. But nice to see that someone not skilled in the dark arts of compilers can come up with an opcode interpreter!



  • @danixdefcon5 said:

    @PSWorx said:

    @bjolling said:

    Doesn't that defeat the purpose of using a visual programming language? She went from something every business user could simply use, to a new programming language in Excel. What's wrong with using C# then? It's more visual than Excel because it is included in Visual Studio.
     

    I agree. She may have used the tools well, but she still managed to surpass the Second System Syndrome and discovered the Third System Syndrome.

    Having the "redeployment" of a rules system made explicitely for end users buried under The Processs seems like the Real WTF to me here. Isn't the whole point of visual programming languages that small changes can be done quickly, even by people with zero expertise?

    I would infer, given the hint of "recompiling" being a real sloooooow process, that the girl arrived to the same conclusion some Unix and Perl devs have arrived: text & CLIs are quicker to compile, modify and maintain than GUI-driven stuff.

    Of course, there are a couple of GUI-driven languages that are fast on the compile side (last one I remember is Authorware) so it may not be always the case. But nice to see that someone not skilled in the dark arts of compilers can come up with an opcode interpreter!

    Well, Graphical programming languages, perhaps, but GUI applications written in proper programming languages don't take a significantly longer time to do properly than CLI apps.



  • @danixdefcon5 said:

    @PSWorx said:

    @bjolling said:

    Doesn't that defeat the purpose of using a visual programming language? She went from something every business user could simply use, to a new programming language in Excel. What's wrong with using C# then? It's more visual than Excel because it is included in Visual Studio.
     

    I agree. She may have used the tools well, but she still managed to surpass the Second System Syndrome and discovered the Third System Syndrome.

    Having the "redeployment" of a rules system made explicitely for end users buried under The Processs seems like the Real WTF to me here. Isn't the whole point of visual programming languages that small changes can be done quickly, even by people with zero expertise?

    I would infer, given the hint of "recompiling" being a real sloooooow process, that the girl arrived to the same conclusion some Unix and Perl devs have arrived: text & CLIs are quicker to compile, modify and maintain than GUI-driven stuff.

    Of course, there are a couple of GUI-driven languages that are fast on the compile side (last one I remember is Authorware) so it may not be always the case. But nice to see that someone not skilled in the dark arts of compilers can come up with an opcode interpreter!

    How do you think projects built with GUI-driven tools are compiled?  Every one I've used serializes the designer surface and runs it through a compiler.  GUI-driven tools don't categorically suffer from long compile times.  A GUI designer isn't very different from a folding and syntax highlighting text editor.

    Also, are you suggesting that maintaining Perl is easy? (In my head this reads similar to "Are you suggesting coconuts migrate?")



  • @Jaime said:

    Also, are you suggesting that maintaining Perl is easy? (In my head this reads similar to "Are you suggesting coconuts migrate?")

    Why did you shoot down your own rethorical question in the parantheses?



  • @Faxmachinen said:

    @Jaime said:

    Also, are you suggesting that maintaining Perl is easy? (In my head this reads similar to "Are you suggesting coconuts migrate?")

    Why did you shoot down your own rethorical question in the parantheses?

    Because I think Monty Python is funny.


  • @Zecc said:

    The project we were working on involved validating insurance forms and checking
    which the available products were available to the, erm, "insuree" (my English
    is failing me here)
    ,
     

    "Insured" or "policyholder".



  • @Someone You Know said:

    @Zecc said:

    The project we were working on involved validating insurance forms and checking
    which the available products were available to the, erm, "insuree" (my English
    is failing me here)
    ,
     

    "Insured" or "policyholder".

    Thanks. I thought it should be something retrospectively obvious.



    <font size="1">That's right: I couldn't remember the word "insured" by I just used the word "retrospectively".</font>



  • @Zecc said:

    That's right: I couldn't remember the word "insured" by I just used the word "retrospectively".
    Consequently, I am forced to conclude you must be the Architect from the Matrix.



  • @Zecc said:

    @Someone You Know said:

    @Zecc said:

    The project we were working on involved validating insurance forms and checking
    which the available products were available to the, erm, "insuree" (my English
    is failing me here)
    ,
     

    "Insured" or "policyholder".

    Thanks. I thought it should be something retrospectively obvious.



    <font size="1">That's right: I couldn't remember the word "insured" by I just used the word "retrospectively".</font>
     

    Actually "insuree" is sometimes used by insurance companies (of course that doesn't mean its actually correct, just that their employees think it is).



  •  @locallunatic said:

    @Zecc said:

    @Someone You Know said:

    @Zecc said:

    The project we were working on involved validating insurance forms and checking
    which the available products were available to the, erm, "insuree" (my English
    is failing me here)
    ,
     

    "Insured" or "policyholder".

    Thanks. I thought it should be something retrospectively obvious.



    <font size="1">That's right: I couldn't remember the word "insured" by I just used the word "retrospectively".</font>
     

    Actually "insuree" is sometimes used by insurance companies (of course that doesn't mean its actually correct, just that their employees think it is).

    As far as correctness goes, "insuree" is a perfectly logical formation, given how the -ee suffix generally works in English. The insurance companies I work with (admittedly, only a dozen or so) seem to prefer "insured", but I'm sure there's a lot of variation throughout the industry. Either way, it's the term for the entity whose potential loss is being insured against, while policyholder refers to the entity who actually owns the policy. I'm not sure which role Zecc was referring to; usually they end up being the same person or organization, but not always.

    A far more irritating grammatical oddity in the insurance industry (possibly the wider legal profession as well) is the use of the word timely as an adverb, rather than an adjective. For example, in common usage one might say that "the claim was not registered in a timely fashion", but it's common insurance jargon to say "the claim was not registered timely" instead.



  • @Jaime said:

    Because I think Monty Python is funny.

    Ofcourse you do. I'm just baffled as to why you would make a non-statement in order to include an otherwise completely unrelated joke.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.