Why most visual development / 4GL tools fail? – Part 1

[tweetmeme source=”sureshsambandam” only_single=false]Part 1 : Top down vs Bottom Up

There are quite a few visual development tools that have failed in the past. When I say past, I meant the pre-cloud era. The commercially successful ones are Visual Basic, PowerBuilder (just googled and found out that PowerBuilder still exists under Sybase) and Oracle Forms 4.5. Although, popularity and merits of the language need not co-relate.  :-) !

And, there are quite few that have come up in the current cloud paradigm. Few Examples : Coghead (already in dead pool), VisualForce of Force.comWaveMaker, Zoho Creator. My POV is on the approach taken to  solve the problem (of visual development) rather than any of the companies/products itself.

If you take a closer look at most of the visual products one subtle but startling similarity is: Most of them take a Top-Down approach for developing the application.

Square peg in a round hole

Image Credit: casa.pokayoke @ Flickr.com

In my opinion, the problem lies here! If you want to know why see this Article on Wikipedia and Paul Graham‘s blog post on ‘Programming Bottom Up‘. While Paul’s article goes into a little tangential context of enriching Lisp, leading to a richer dialect – the essence of ‘Bottom Up’ comes out when you read between the lines. Also check out this thread Top Down vs Bottom Up on TheServerSide.com

It is natural for human comprehension to think of a system’s high level design and functional use cases in a ‘Top Down’ style. However, when it comes to implementation, ‘bottom up’ approach has to be followed. The shortcoming with most of the visual development tools is that they have extended the natural human comprehension far too much into the implementation. To the extend that, most of these tools start with a visual canvas where the user starts painting the application by ‘drag and drop’-ing widgets from the palette box. While I understand that this is easy for business users and analysts to start off quickly – there can be no compromise on the abstraction that is required to build good software.

The approach of starting from the page or a canvas can accomplish simpler – situational applications (use and throw). However,  it will be close to impossible to build industrial strength SaaS Business Application like an Insurance Underwriting System or an Automobile Dealer Management System. Also, the applications built using these tools will be little more than a ‘data entry’ / ‘book keeping’ system with very little capability to support sophisticated business logic (more on this in Part 2 of this series). In fact, when prospects approach us for simpler situational apps that doesn’t involve heavy duty business logic we have recommended ‘Zoho Creator‘ – another ‘Made In India, Made for the World‘ product. In fact, unlike other products Zoho Creator clearly mentions in their home page ‘Build Your own online Database’.

So, what is the correct approach solution? Just like in OOP, implementation has to be bottom up. You define the object model  for small components and start relating them with other components. An object model or data model, we use both these terms  inter-changeably at OrangeScape, contains how an object is represented in an optimized / co-related fashion in conjunction with other objects in the system. Again, just like in OOP, the object is an encapsulated atomic unit that represent data + business logic (How do we deal with logic in Part 2). Many such fine grained objects together make up the data model of a logical business component. Putting all these logical business component model together in perspective gives the developer the full picture of the software –  I call this macro-model for want of better term.

All of this is not some theoretical rant! One Example. OrangeScape’s SI Partner Wipro – using their development team – with consulting from OrangeScape has implemented a very large ERP for a  government organization where the ERP is being rolled out across 743 office locations in India. Each office location is a Tenant in this huge multi-tenant ERP. This project (I can’t name it yet, due to confidentiality clauses) is a prestigious project similar to the Citizen UID Project. We haven’t gone outside of OrangeScape’s Studio to build anything in this huge ERP implementation. The success of this project is a ‘proof point’  for my argument on ‘bottom-up’ approach supported by the OrangeScape PaaS Platform among many other capabilities.

Finally, in my view, starting from ‘Object Model / Data Model’ is closer to OOP and starting from UI Pages takes us back to days of  ‘Procedural Coding’!  After all these advancements in programming, why go back in time?

I see you asking:  ‘How does one or OrangeScape for that matter bring out object modeling in a non-intrusive visual manner?” Will talk about that in an another post.

[tweetmeme source=”sureshsambandam” only_single=false]

Share

This entry was posted in Cloud, Enterprise Application, OrangeScape, Visual Development and tagged , , , , , , , , , , , , , , , . Bookmark the permalink.

5 Responses to Why most visual development / 4GL tools fail? – Part 1

  1. Pingback: Why most visual development / 4GL tools fail? – Part 1

  2. Pingback: Why most visual development / 4GL tools fail? – Part 1 | OrangeScape Blog

  3. Pingback: It Box @ All Around the World News

  4. labsji says:

    Visual is a way to get the high-level (Big)picture. Actual code is a way to get the details. Learning( rather Familiarity) plays an important role in getting the intended functionality done. In a way, a visual development tools are like a zoom lens that can handle different level of detail as per the developers wish.
    Obviously, developers would wish to switch level of detail seamlessly. And they naturally expect to be in familiar terrain at each level of detail. This is a big challenge for the visual tools. Understandably, the visual tools were able to address only limited portions of the challenge.

    Your suggested approach of modeling( a flavor of Object and Data) as the solution is interesting, but Modeling can happen only at one level of detail. And requires a lot of learning/Familiarity. Are you solving the challenge by creating a bigger challenge?

    -Balaji S.

    • Hmm, I don’t know how I missed this comment.

      Every time I board a plane and happen to see the cockpit through the occasionally open pilot cabin – I always get intimidated by all the different controls, indicators and gadgets. I am no pilot and I have no clue. I am curious – but that is a different matter.

      Working with non-trivial enterprise class business applications is lot like that. It is not a car with a just brake and accelerator (remember most cars in the US don’t have gear and clutch) – equivalent of a blog. But for a well a trained pilot, the cockpit is much like a regular tool.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s