h1

Discovery vs Invention

August 6, 2011

A dear friend of mine, who I spend a lot of time walking, kayaking and of course talking with comes up with up the occasional gem, a real pearl of wisdom.  For example, in reference to modern surfing competitions, he says ‘In my day, the best surfer out there was the one having the most fun’.  Hmmm not sure if everyone will get that or not.  My favourite of his gems is this, in reference to an unruly or disruptive person: ‘That [person|kid|…] needs a good listening to!’  Instead of ‘sit down and shut up and listen – you need a good talking to‘, it goes ‘sit down and start talking – I’m listening – you must have something on your mind’.  I have had the opportunity to use that a number of times, all with tremendous success.   People generally become disruptive when they are bored or oppressed, when no one will listen to them, when they have no way to vent their thoughts.  The internet, and blogging of course, are modern remedies for that.

I needed that introduction, because, as you will have just guessed, I have something on my mind I need to get out.

In a moment.

First, lets make sure we can discern between discovery and invention.  Discovery is the uncovering of an existing truth, something consistent with the known rules and laws of math, science etc at the time.   Invention is using those known rules and either changing them or adding to them to come up with a new ‘truth’.  Reading between those words is the idea that invention is dynamic and constantly open to reinvention.

OK, onto whats on my mind, right after we answer a quick question.  Was object-oriented software development discovered or invented?  Restated: is OO technology a naturally occurring thing or is it man-made?  If you believe it to be discovered, please leave a comment.

So whats on my mind?  The ardent reader by now will have seen it coming – I have re-invented object-oriented software development methods.  With a little help from my friends of course.  Or maybe de-invented, as it is my opinion that when OO techniques first came to the fore, in the early 90’s, there was great promise that it would revolutionise software development, which it clearly has not.  Those early days were focussed on simplicity – an object is simply data + methods, and that approach to be pervasive throughout – so your analysis and design is done in an object oriented way (OOAD) and then you program that way (OOP).  In those days, tools & technology let us down; there were no useful OOAD capable  modelling tools, nor were there any languages that were capable of properly implementing all of this.  Again, those who will claim that c++, smalltalk, eiffel etc were all capable languages in the early 90’s are welcome to state their case.  The closest IMO was a 3 1/2 GL called Gupta or later Centura SQLWindows.  In 1993, it was a WYSIWYG windows designer and full MI OO language.  Sadly, it was interpreted, not compiled, and more sadly, had no dynamic instantiation  – it was GUI based, so you could create windows objects on the fly, but not abstract classes.  As we moved through the 90’s, we got Delphi, Java and eventually .NET.

And dont forget VB.  Wasn’t exactly object oriented (lacked polymorphism) but it was easy to use and had some good stuff.  It was the beginning of the end.  Back in the 80’s, when we were doing Cobol CICS and IMS on IBM mainframes, we were basically programming abstractly – we were treating streams of bytes from 3270 terminals as formatted data and applying business rules and persisting that data.

Then along VB, Delphi and even good ole Gupta, and suddenly we could code directly against the ‘real’ data – on a form – we could trap on_lostfocus and apply formatting and rules to the contents of a textbox on a screen.  Too cool!  Too easy.  Far too easy in fact.  We had stopped programming abstractly, and coding rules directly in screens.  At the cost of all reusability.  Didnt we hear that its best practice to separate the presentation layer from the functional layer?  Coding on_lostfocus rules on a screen does not abide by that.  But luckily some of us hung on to that abstraction.  It was tough for a while, but we rode it out.  The rest of the world went on to MVC, MVVM, n-tier architectures, SOA and so on.  When .NET came along, we finally had a platform that had fantastic OO features (apart from MI – later on that!) and no real business application development platform or paradigm to cause legacy issues (as Java does with j2EE).  I can see those ‘leave a comment’ buttons clicking furiously now…

Sticking with a model of OO simplicity – data + methods – and focusing on abstraction, leaves you with a very simple 2-tier architecture: the business or model layer and the presentation layer.  The presentation layer can change data or invoke methods of the business layer.  All rules, formatting, persistence, everything happens inside the business layer, in a wonderful world of ultimately reusable components.

OK, here it comes – deep breath – I have invented the software factory pattern, as opposed to the workshop pattern, where the gains are greater than the gains of manufacturing assembly lines vs workshops.

As far as I know, nobody else has.  One of the signs of a true reusable architecture is code normalisation – every rule is embodied in a pattern and that pattern is a reusable component and so every discrete rule is only coded once, and reused.  No ctrl-c/ctrl-v.  Reused by declaration, in a model.  MDD to the max.  DSLs are a wonderful thing, but why not make the DSL based on an extensible set of abstract Types, and why not allow the modeller or studio to fully understand the DSL, to bring it to the domain of the analyst rather than just the developer?  Model Driven Development based on an extensible (uninhibited) DSL with no code gen, only declaration.  With client side agnosticism – strap on a Silverlight, Windows Forms, Android front end without any code changes – the presentation layer is simply a subscriber to various data + methods of the business layer.  Sound too good to be true?  It isn’t, cause I’ve been building systems this way for literally decades.

Good to finally get that off my chest.

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s

%d bloggers like this: