LightSwitch Frameworkonomics

Introduction

Do you know Freakonomics?

It’s making economics more fun, in the same way LightSwitch is making programming line of business apps more fun. Maybe we should try to apply some economic thinking on LightSwitch.

What’s the point with Line of Business Frameworks?

Basically, and maybe we sometimes forget: a framework should provide comfort. Comfort, in the sense that things can be done faster and in a more reliable way. On the other hand, framework tend to reduce the amount of what I would like to call: “degrees of freedom”. Frameworks often introduce things like “conventions” and tend to make simplifications in such way you loose possibilities you would have without using the framework.

We could try to depict the above as follows:

FrameworkComfort

The point is course, that a good framework should provide as much as possible comfort without losing too many degrees of freedom.

The ultimate “God” framework would be a horizontal line: how many comfort the framework adds, we keep the same amount of degrees of framework. That would be the real Nirvana or Walhalla.

Often home-brewed frameworks tend to give in very soon on degrees of freedom when trying to add “comfort”.

 

I believe that LightSwitch deserves an  excellent score on this metric.

Of course, I’m not familiar with all “home breweries”, so I can’t estimate the slope of the home-brewed framework line in a statistically significant way.

When do we get diminishing returns or even negative returns when we increase application complexity?

This question needs closer clarification. Let’s start with the following question: what types of applications tend to give the highest productivity gains in the the context of application complexity?

LightSwitch application development exhibits extremely high productivity gains for simple, CRUD-based applications.

 

That’s great, but what when complexity grows?  Definitely, when complexity increases, there are diminishing returns. Where you can build a complete CRUD application with 30 screens in a few hours when you encounter the need for UI tweaks, side-effect processing, validation logic and more complex business logic, you might need several days or even weeks to complete such a 30 screen more complex application. That’s common sense. My point is rather how fast will get on the point of negative returns. Following example can illustrate.

If I have a customer who really is very choosy on let’s say screen design, I might need to fall back in specific situations to a custom control and inject this in my LightSwitch project.  Now, the question is not really how much time the development of my custom silverlight screen is taking, but rather : is the injection of such a custom control taking more time compared to the situation where I would develop a custom control without LightSwitch?

The answer (at least: my answer) is that it would exactly the same. That’s great news, but look to the red line in following diagram.

complexity

The red line would be the situation where at a certain point of complexity (where we reach the x-axis), our framework is giving negative returns: so we would be better off without framework. Currently, I have never encountered this situation with LightSwitch.

Has LightSwitch as a framework “positive externalities” to other phases in the software life cycle?

We understand that LightSwitch is giving productivity gains. Great, but are we seeing some effect from this, apart from the phase where we actually program the line of business app? In my view: yes.

Usually, at least in enterprise context, the build phase of our software is preceded by some form of analysis or envisioning phase. This activity exists in quite a lot of flavors: analysts make fancy UML diagrams, others draw wireframes or write, in an agile context,  user stories.  In a non-LightSwitch context, all these activities happens in the mind of people and the eventual customer (you know, the guy who pays the bill in the end) is supposed to all understand this. All this, means that customers are often very long in state of uncertainty of what they will actually see: a working piece of software.

Now, it’s my personal experience that customers tend to over complicate software requirements when they are kept too long in a state of uncertainty about the eventual piece of software.

Why would you spend too much time on fancy analysis docs? Simply sit together with your customer and elaborate the data model directly in LightSwitch, generate some default screens and annotate (in OneNote) the business logic or screen customizations you come across.  You can provide in a few days (or maybe hours) a first rough view on what the eventual software will become. Since you work in process of very fast iterations (let’s call it micro iterations), there is less uncertainty. Since the customer can express business logic in terms of software she can see in front of her, there is less room for interpretation, errors and frustration…

 

Conclusion

Some first attempts to apply economic thinking on LightSwitch. I’m not yet finished with this, but for now, I call it a day.

A votre santé.