Random Ramblings on LabVIEW Design

I'm very enthusiastic about the subject of the last article and will attempt to flesh out some details in the months to come (sorry but my brain does not work in a linear fashion and neither do my enthusiasms).

I think the combination of OOP, Functional etc etc may be the unified theory of software development!

And these grand statements may be part of another problem, a problem that we have contributed to in our innocence.

In fact we kind of predicted it by using the following quote in our book.

"If this is true, building software will always be hard. There is inherently no silver bullet"

- Frederick P. Brooks, Jr 1987 Computer Vol 20 

And I really want everyone to understand this. Please, please understand it!

We presented LCOD as a method and carefully explained modular design, thinking that by describing the whys and wherefores the job was done. We then went back to our day jobs and didn't really have time or energy to follow it up.

I see all the frameworks, methodologies, processes, techniques and theories enthusiastically evangelized (ours included) and I want to shout "a badly implemented Silver Bullet will still be crap"

What do I mean by badly implemented? Taking LCOD as an example we can separate the techniques of implementation (what we place on the block diagram) and the hard work of design. So we could quite easily create a god component that does everything we want our program to do, but this is obviously a bad design decision. With LVOOP we could similarly have god objects and I expect we could have a god actor (Morgan Freeman).

Someone said the following to me at the CLA summit "OOP is the best way to write software!", it elicited the following slightly snarky response... "Define BEST". Statements like that de-value all the great software written that isn't OOP and doesn't really add anything to the conversation. OOP is a great and valuable tool to be added to your toolbox and used where appropriate. You do not become a great carpenter by using great tools, they help but it's not the full story.

And with all our best intentions you can put the silver bullet in a dirty weapon and have it back-fire on you (as Fab put it). Now I have some bad news for buyers of self-help books, I think good software design comes with hard work, study and experience, and pretty hard won experience at that! Also good software design does not depend on the methodology or process you favor, it depends on using a technique appropriate to the requirements.

"Rules, guidelines, and principles are gems of distilled experience that should be studied and respected. But they’re never a substitute for thinking critically about your work."

Jeff Atwood The Ferengi Programmer

I found this quote from a spat between Joel Spolsky and Uncle Bob Martin, 2 people who are very loud in the software design community and have very differing views on Test Driven Design. Both can't be right, but their opinions are espoused as absolute truth.

And here is an uncomfortable truth: you won't create decent designers by teaching techniques, offering frameworks and imposing rules. Good designers understand their tools, understand design and can assess what they have been told and reject what doesn't work for them. Also they generally get better with each job they do!

Software is a practical subject the best way to learn how to design is to design stuff. (<---Mr Mercer has made me re-evaluate this statement!)

Software is a practical subject the best way to learn how to design is to design stuff, while being taught how to design stuff. (<-- this is how I learnt and it served me pretty well, but I needed the experience of writing lots of code prior to being taught to really hammer home the lessons)

As one of the loudest people in our little community I have one message for you all to take away

Curmudgeonly yours with love.

Steve

I had a go at SMORES a while back in this article

SMORES, SMURF or SCRFFMRDM

(actually it was really an attack on mindlessly following acronymns)

and like most things it's not quite as black and white as I originally put it (time, conversation and thought have added colour and shade).

The conversation on this subject has mostly been with AristosQueue and I think we have stumbled on a point of convergence (I'm only speaking for myself here). Link to one part of the conversation is here

The breakthrough statement is as follows.

You need different design methods for different stages in a project.

To back up my theory I've split a project into 3 stages

In reverse order let's look at the Low Level API/Drivers part. So this would be hardware drivers, reporting, data handling, communications.

Next we come to the framework there are plenty available (Actor Framework, Delacor, JKI, James Powells, TLB, Aloha to name a few), this should handle all the common tasks associated with most applications.

Finally we have the Customer Facing/Final Application software, this is the bit that brings together all of other parts and makes you money.

Here's a table of important considerations for good software design. And as an exercise I've selected 5 of the most important for each stage.

A bit of Acronym/Anagram fun gives us

Low Level API/Driver = STORE

Framework = FRERC

Final Application = FRUMF

It's important to note that the considerations I picked are the ones that are important to me, my company and my customers. They may not be important to you, so pick your bloody own!.

So if the requirements at each stage vary so much it stands to reason that we should apply different design tactics, even different designers.

There is one extra consideration that I would like to put in for frameworks (with thanks to Thoric) and that's Inobtrusive. I want a framework to be visible but not get in the way. I would like to see what it is doing but I don't want it masking the solution to problem I'm solving.

The other aspect to think about is the size of each section, so if you only ever tackle one type of job you may find that the customer facing part is small compared to a big ol' framework. In short they are variable in size.

More questions than answers as usual, but it's food for thought.

And to quote Leslie Lamport for the second time this week "Thinking does not guarantee that you will not make mistakes. But not thinking guarantees that you will."

Lots of Love

Steve