Application Building Blocks

Brian in Coding | 8 Comments January 22, 2004

Scoble has a great post about a new MVC tool he's seen that takes MVC a few steps further, where an entire application can be built without using code. There is a long comment thread that is a great intresting read. Yes, this has been done before by many tools. Arguments about how well it scales once you leave the demo and start doing real work with it.

Despite all sorts of problems with this model, it fits in really well with reality. Take the creation of anything worthwhile today: a house, a car, a microprocessor, and you have a few very sharp, very focused individuals who spend a lot of time in very narrow niches designing parts of the whole. But, those few individuals aren't the ones stamping out houses and cars. Their designs are carried as blueprints to people with a different set of skills who actually build the stuff.

Software today isn't like that. To build any application everyone on the team has to be a rocket scientist. Even one unchecked return value can spell disaster -- its as if you're buliding a house and you're holding all the walls together by drilling holes and fastening the entire thing together with one very long piece of rope. All you need is one bad knot, or one sharp hole, and the whole house caves in. Sure, software can be designed to be robust, but you've got to have every person on the team highly trained to know what "robust" is.

I believe that in order to evolve software development into something that can reliably produce programs that are, well, reliable, we need to segment the development community just like other disciplines. Visual Basic already did this -- you had to be a rocket scientist to write an ActiveX control, but you could use one pretty easily. But, it doesn't go far enough. As soon as you have to step into writing code, the chances of slipping up increase several fold.

What's worse, with modern frameworks like the Java libraries and the .NET Framework we have, in some ways, erased this barrier to entry. New Windows Forms controls are written in C# or VB, or any language I choose. New Swing components are written in Java. This is great, because it puts everyone on a nice level playing field. Just because I like VB I'm no longer second class citizen. That's great, because my choice of language really shouldn't matter. But it's also bad, because not everyone is cut out to be a rocket scientist.

I'm a firm believer in drag-and-drop application design. You should just have a bag of tricks you can drop and connect together. Those tricks should even connect themselves together as much as possible so there are fewer knobs to fiddle with. Of course, when you do this you always lose flexibility. So be it. When building a house a construction worker uses 2x4 lumber almost exclusively in the United States. It's a standard. It does impose limitations, but those limitations become assets because other things can interoperate (drywall dimensions, standard stud spacing, and even drywall screws all depend on things being a standard size). Writing a modern application today -- one that interoperates with other things on the internet, is self-updating, secure, and all the rest of the lastest buzz-words -- is a damn hard task. I'd be happy to let a few focused people figure out how to create complete building blocks that I then just drop into my application.

The big question, of course, is can you create a set of reusable blocks that are general purpose enough to create a variety of applications, but not so complex that you defeat the purpose of having the blocks in the first place. And, once you create these blocks, how do you create a development tool that shows you the relationships between them without it looking like a nightmarish art project?

What do you think? Is this the future of software or just another demo-ware fad?

Comments (8) -

Frank Hileman, Thursday, January 22, 2004 at 5:16 PM

This is the past of software, and the future of software. The past because it has already been done for 20 years or so in various application domains. Remember NExt? LabView, SimuLink, SoftWire, MAX (in music), function block diagrams in process control -- these all use similar concepts. These ideas work great as long as you are close to the application layer -- as close to the user as possible, or in the best case, you are the user building the app. For low-level, complex, or general purpose things, it is not always so great. This is where the "art project" analogy starts to become painfully real.
As part of VG.net we wanted to add a second window in the designer for graphically connecting real-time data to the graphics. It would consist of a data flow diagram, with "blocks" in the middle that could contain arbitrary code expressions, or conditionals, in whatever language you wish to use. In fact we created a root designer to do this, that works with any object including controls, or custom VG.net "Pictures". This is sort of a cross between function block diagrams and something like Simulink. But instead of creating a simulation, you are creating a real component or application.
The expressions actually get compiled down, not interpreted. No reflection.
Unfortunately we had to abandon that to finish the graphics engine. But I think this is the way to go, to reach closer and closer to the user, by making things easier and more "directly manipulative" -- that is, you change things with the mouse, graphically.
Now that you and your team is making the wonderful design-time transaction and serialization engine available outside of Visual Studio .NET, there is the possibility that we can take this idea to completion, and provide a designer for end-users, that produces exe's and dlls. This would be the fullfillment of our original vision: to create animated graphical components and screens, and bind them directly to real-time data, all with no coding!
It is the restrictions in these tools that make them so useful. But they can never replace general-purpose programming tools, such as languages. They are best as specific-purpose programming tools. It turns out that a lot of database app programming is repetitive and well suited to these types of tools. Designing a "design-time framework" in a graphical language, though, would be a nightmare. I have seen some real messes produced by graphical languages.

Mike Parsons, Friday, January 23, 2004 at 6:01 AM

At the risk of sounding "Alan Cooperish", this will never happen as long as we have Software Engineers Designing AND Building this stuff. I have worked at several large Software Companies and it's amazing the mental distance between the customers and the people designing and building the code ... and to make matters worse, this gap is growing larger.
In spite of all the "cool stuff" that new programming tools bring us (i.e. Visual Studio.Net, Whidbey, etc), you still have to be a rocket scientist to build anything useful. The number of moving parts in a relatively simple web application is mind boggling (to everyone except a Software Engineer). We need to step back from the code and start thinking more about what we build.
But that's just my opinion Smile

Brian Pepin, Friday, January 23, 2004 at 10:12 AM

Mike -- I agree with you completely about the complexity issue.  It is something we're facing ourselves:  even as supposedly "well trained" software engineers we are always swimming in the complexity of our own creations, and barely keeping our heads above water.  In order to create simple to understand systems we need to recognize complexity when we see it, and work to create a simpler solution.  Tools such as Visual Studio help, but only because they either hide or teach you how to deal with an already complex system.  But, the trick, as you say, is that what's simple to us is not necessarially simple to someone else.  
I think we've made progress:  I don't have to know much about OS memory management any longer

Frank Hileman, Friday, January 23, 2004 at 12:15 PM

Mike is right, the new "cool stuff" often just makes things harder for developers, and puts developers that much farther from the end user. But that is the whole point of these graphical programming languages: they bring the final development step, application assembly from component blocks, directly to the end user. That is why these environments have to be very restrictive, specific tools, instead of general purpose tools such as an imperative language. That is why they will never replace the general purpose programming language.
In general, the more declarative the design process, the more it fits in with a graphical programming tool. Except for simple step-by-step pipelines, graphical languages work very poorly for tasks that inherently need an imperative programming language. You end up with all types of hacks in these cases.
Once I saw a demostration of Visio used to write code. Everyone in the audience quickly realized that editing a UML class diagram in Visio is one of the most inefficient ways to write code. Not only that, but looking at the diagram only provides an overview -- to see the details you had to pop open all kinds of dialog boxes. So as a communication tool the UML class diagram was being misused -- the code was more efficient for low-level detail communication as well. For me, this was another example of the advantages of code over graphical tools for general-purpose programming.
There are some types of UML diagrams that work well at both creating code and explaining details (state diagrams or activity diagrams), but the class diagram is not one.

Brian Pepin, Saturday, January 24, 2004 at 11:09 AM

Agreed -- we have had several research projects here trying to move beyond code, and they never work.  Written language (even programming language) is expressive.
As you point out, people today are using drag and drop methodologies in niche markets where the level of expressiveness and customizability of code is just not needed in the application's domain.  I am thinking (perhaps wishfully thinking) that with the right basic archtecture you could build up a 3rd party market for these types of building blocks so that you have a more general purpose tool.  You'd probably always write the building blocks in an imperative language, but you could wire them toegether declaratively.  

Udi Dahan - The Software Simplist, Sunday, February 1, 2004 at 11:27 AM

Would you like to live in a "stamped out" house ?
Although it would be definitely cheaper, would you be willing to give up on your everyday comfort for it ?
At what price would you be willing to give up on comfort, and what level of comfort ?
So every house has doors, drywall, windows, bathtubs, etc. But, have you ever had to build a house ? A house that answers your exact needs, wants, and wishes ? There are SO many decisions to be made - so many ways to combine all the components. What properties each component will have. It's really quite complex.
I think that the whole software as building construction metaphor has pretty much outlived its usefullness.
When normal everyday people will be willing to live in generic stamped out houses, then, maybe, we'll start to see the rise of the stamped out software.

Maxim V. Karpov, Sunday, February 1, 2004 at 2:56 PM

Application Building Blocks approach will fail because:
1. Technology is changing constantly, so implementation of the problem differ from the platform you use at the time.
2. Developer has to aquire knowledge of Application Building Blocks (framework) that is spefic to the X version of its implementation.
Maxim
[www.ipattern.com do you?]

Frank Hileman, Sunday, February 1, 2004 at 6:41 PM

Maxim, your arguments apply to any developer tool. Not all must fail. Often graphical languages are not targeted at pure developers.
Brian, if you have never seen LabView (national instruments) or SimuLink, I suggest looking at them. They are general purpose languages, completely focused on data flow. There are low-level operators, etc, in both.
One thing I prefer, in our own graphical language, is the ability to have arbitrary expressions in a block, instead of having to build them out of many smaller blocks, such as "+". This gets rid of a lot of the wiring mess that builds up when you try to use data flow diagrams.
We spit the expressions out into a helper class so they get compiled. VS is a great platform for visual languages, once you get past the root designer "vertical" learning curve.
Comments are closed