Along with the exciting new world of NoSQL — allowing the universe to deal with unstructured data without constraints, not to mention without restraints — there is a trend in new development to rely as much as possible on “NoProgramming”. I don’t know if that’s a real term, or, if it is, if it’s defined the way I mean it here, so here goes.
In the world of NoProgramming, you should be able to accomplish everything without the need of a programming language or language constructs. You should be able to string blocks together in a visual fashion, whether in an IDE or in a web application, without ever (ew) having to learn any syntax.
This is supposed to promote “ease of use”, to the point where the users of the application, who are supposed to be business users, are supposed to be able to configure everything themselves without the need for any development help. Let’s be fair and say the “power users of the application” are supposed to be able to do this, not every user will be able to do it.
FWIW, Siebel actually called these people “configurators” – god forbid they should think they were “developing” an application.
Take a simple and common reporting need: a “calculated” value or field
Consider the following reporting requirement, expressed as pseudocode:
Take a different action or (in a reporting context)
display a different string, depending on a value:
If Red, StopIf Green, GoIf Yellow or Amber, Go very fast
Doesn’t seem very complicated, right? And if you’ve ever designed a report or an export, you know exactly why you need to be able to do something like this.
How would you do this in any reasonable reporting environment? Doesn’t matter whether it’s VFP, SQL, MDX, DAX, Tableau, Cognos, you name it. You’d write an expression and it would take you about three seconds to do it. Yes, the syntax wouldn’t be English (or whatever your native language is) but it would probably use some English-like keywords such as IF or CASE, etc. The expression might be a little complex if there were a lot of conditions, in which case, if it were a capable environment, you’d probably split it off into a custom function of some type, which would take you two seconds longer to write but would be elegant, maintainable, and re-usable.
Let’s look at how you do this in Workday, instead. Remember, no syntax allowed.
You sit down to create your report. You start to created and realize you need the above behavior in it. You need to create a calculated field, that much is clear. Whoops, there’s no way to do that within the context of Create/Edit Report, no convenient shortcut to build this particular report component at hand while you’re there. You’d better drop what you’re doing and navigate to/drill down through a completely separate set of atomistic screens.
So you start Create Calculated Field, which you start by naming it, hopefully using some naming convention that will help you find it again later. You also need to give it a business object context, and a “function”, Normally, a calculated field in Workday takes a value and applies a function to it, presumably appropriate to the data type of the value For example, you could use some equivalent to Substring on a text string.
What function do we want here? There doesn’t appear to be anything that would correlate to “if” or “test” or “case”. There also doesn’t seem to be any obvious way to apply more than one function or transformation within the build of a single calculated field.
So, here the function is actually called “evaluate expression”. OK, that seems reasonable. We enter a new screen, tuned to our “evaluate expression” function behavior.
We give our “Evaluate Expression” result a data type of Text, there’s a readonly Business Object context of (empty), and we have an opportunity to put in a default value result, which we decide should be Stop. Only thing is, try as we might (with quotes or without) we can’t put the value of Stop in for a default value. This should be a clue that something is wrong.
Undaunted, at this point, we shrug our shoulders and move on to building the conditions which will provide values.
OK, so what do I put in these conditions, so that one can result in “Stop”, etc? I at least know how to press the “+” button so that I have three of them. I know I need three. But what do I put in there?
It turns out I can’t type the name of a Workday function, let alone any other sort of code expression, in there. I need to search for existing constructs of some sort — similarly to what I experienced earlier with Default Value.
OK, I guess I’ll need three additional calculated fields, each appropriately named so I can find them again, each with a boolean data type for its result.
Sigh. So I back out of this again, and start to create the three additional calculated fields I’ll need, one at a time (you can duplicate them, which saves a little time, but there’s still a large minimum number of clicks and decisions for each one). As before, I’d better name them according to some naming convention so I can find them later. The “function” for each of these is called True/False Condition.
Let’s assume that the Field required for each condition is an actual attribute of a Workday business object entity, and the Comparison Value for each condition is a list of values found somewhere in a subset of values for an existing attribute of another Workday business object entity.
In our example, this means that our Field is something like Driver.CurrentAction, and Red, Yellow, Amber, and Green are all values in TrafficLight.Color. If they aren’t, things would get even more tedious, just as they will be for our Return Values, below, but let’s hope for the best case scenario here and try to move along. I’m sure you’re getting the picture, no need to drag this out.
Fine. Now I can go back to creating my original Evaluate Expression calculated field, put in my three conditions, because they’ll appear in a picklist. What about the Return Value if Condition is True?
Whoops. Can’t type a text string in there either (Remember the Default Value? It really should have tipped us off.)
Time to back out again, and create three more calculated fields, this time of Text Constant type. Again, using some naming convention so I can find them later.
And for the life of me I don’t understand why a Text Constant would need a Business Object specified, unless it’s for scope. If it’s for scope, I’m surprised the calculated field names need to be unique across the entire Workday implementation — but that did appear to be the case, although I can’t swear to it.
Now, finally, we have assembled all the building blocks we’ll need to go ahead and create the Calculated Field of Evaluate Expression function type that we needed for our report or extract in the first place. We even have the ability to create the Default Value now.
When is “ease of use” not really ease of use?
If you make syntax verboten, because syntax would be new to the user and therefore, somehow, inherently not “easy”, you’re left with tedium and a zillion steps to do one thing. Sure they’re all things that the user knows how to do (create a name, point and click), but IMHO there’s no real ease involved, even when it’s no longer the first time and the user isn’t scratching his/her head to figure out the process.
If you don’t care about this, when you’re building a development interface, you require the user to take 100 additional steps, because (a) the calculation must be built from the inside out, which is exactly the opposite way the user will have envisioned his/her requirement and (b) there are never any clues or shortcuts at hand to drill down into the “inner” requirements, which must come first, when the user tries to build the “outer” ones.
By the time the user has done this once or twice, s/he is ready to pay some professional consultant $250/hr to take the tiny, tedious, boring, and far-from-intuitive steps it will require to get any real work done. The user will also be paying for the his/her own time to express the simple requirement to get signoff on the need for an outsource
Don’t get me wrong
“NoProgramming” as a concept, extensible SAAS applications, and Workday in particular, all have really good points and deserve their place in the sun. (Just as NoSQL does!)
It’s the cynicism involved in some of the design choices, resulting in a disregard for developer usability, that I’m complaining about.
If I continue having to deal with this, there’s going to be a new category in this blog, probably called something like Curmudgeon Rants, in the near future.