Get the developer out of the way!

The ambitious-yet-easily-perplexed black ops site director begs his technical wizard to make everything easy to understand

I’d be so much more productive if I could get rid of this other person who keeps asking hard questions about exactly what I mean and exactly what I expect! Just make the spaceship go to Mars, okay?!

Remember when the thing that was going to dis-intermediate software developers was visual IDEs? With XML data modeling and object oriented programming techniques, solving your business problems is as easy as dragging and dropping boxes on a flow chart!

Remember the last wave of NLP (natural language processing) interfaces?

Pepperidge Farm remembers. I’ve sold both technologies and worked with customers with real problems to find where they worked and didn’t work in production.

The answer is that they can work, but that they did not dis-intermediate the professional. At best, they moved problems from the domain of developers required to professional services engineers required. That’s not nothing! Getting a task done by hiring PS for a week is better than getting a task done by filing a ticket and waiting for a release. But the promise of truly empowering the user was not met. Why did those technologies fail to change the world?

Visual programming failed because the “non-technical” people were unable to construct the boxes necessary, leaving them reliant on libraries of premade boxes that couldn’t fit the need. The fuel versus engines problem and the open source content problem combined to prevent takeoff, because really using the product still meant hiring expert help. Less expensive help, and possibly less of it, but hardly self-serve.

NLP also has a content problem, which some vendors attempted to solve with abstraction models. That again relies on domain experts to suss out information from data and therefore isolates the user from the data pipeline. There’s lots of scenarios where that’s the best available way to do things, but “best available” can be far from “good”.

The current wave of SALAMI-based excitement has changed the game by using the internet as feedstock. The library is much larger, and based on the resources that real developers and domain experts use as reference. That seems likely to have all sorts of cache-poisoning, GIGO, and causality problems, but for the moment let’s just look at one problem: asking the right question.

In order to make a thing the creator has to:

  • understand the materials. Trying to make a marble sculpture with the technology of Lego won’t work, or vice versa.
  • comprehend the strategy and tactics together. Asking the system to do statistical modeling of data without specifying how is probably going to produce a Pandas result, because that’s the best example on Stack Overflow — which won’t work if your production environment isn’t able to use Python. Asking for a Stonehenge model without being clear what the use case is won’t work.
    It’s cool that there are common flows which will work, like “draw an owl”. That said, there were compelling demos for visual process automation and NLP too.

A developer (or pro services engineer, or sales engineer, or product manager) can help the user come to those understandings from an incomplete or misdirected prompt. A SALAMI requires the user to determine that its answers are incorrect, self-tune their prompts, and otherwise help themselves. So, is this going to be the technology that dis-intermediates the expert from the user and their solution? Possibly, for users who are willing to do a lot of typing instead of talking.


%d bloggers like this: