Random Ramblings on LabVIEW Design

Community Browser
Labels
cancel
Showing results for 
Search instead for 
Did you mean: 

SMORES, SMURF or SCRFFMRDM

Active Participant

As most regular readers will know my prime interest is software design and specifically why a design becomes complex. Since becoming a CLA I have had quite a lot of my fellow CLAs stipulate how important SMORES is when judging a good design.

In the interest of foolishness I going to state now that I don't get it!

So the question I throw back is this.

Is SMORES the only tool you use to judge a good design?

First I guess I should describe SMORES


Scalable

Modular

Optimized

Reusable

Extensible

Simplified

I'm going to do my due diligence now and explain each one in turn. Most of this has been stolen from here.

Scalable

For something to be scalable, it must work the same without modification regardless of how much throughput the system has to manage.  In software, scalable software can handle one or many users, one or many channels of data, one or many reports, etc.

Modular

If you use SubVIs you are making modular code, if these modules are designed with some regard to coupling, cohesion and information hiding your code will more pleasant than if you don't.

Optimized

Software, processes, and systems should be reviewed and streamlined to ensure the best possible output has been achieved. 

Reusable

To make something "reusable" refers to the extra investment required to take anything originally designed for a specific purpose and add the input and output definitions and refinements to make the same object attractive for use on another purpose.

Extensible

Extensible refers to the ability to connect new functionality onto an existing system without having to rearchitect whatever you are connecting on to.  A good example of this is a plug-in architecture.

Simplified

Simplified doesn't always mean the object can or should be "simple".  It means that there is value to be had in making the object you are building as simple as possible without sacrificing scalability, extensibility, etc.

I have several issues with these as design considerations in my problem domain, I'll tackle the easy ones first...

Optimized and Simplified - now these seem a little wishy-washy and hard to measure to my engineering brain, who defines simplified for example. As we have seen from our design discussions here simple for me is not necessarily simple for someone else (more likely the other way round in my experience), so how do we judge it?. Similarly at what point are we happy that a system has been optimized to our satisfaction.

Modular - I've whittered on about modular design a lot here and it is kind of an assumption that if you don't use SubVIs you probably shouldn't be worrying about SORES (see what I did there)

Scalable - We've had several interesting conversations about this and my position is this, we write configurable software, this gives us a certain amount scalability. I would also add that LabVIEW is a high level language (definitely 4GL), some might even call it a Rapid Application Development environment. Should we really be applying this amount of importance to scalability for a language so high level?

Extensible - I think the following quote from an excellent article by avilay sums up a lot of the point I'm trying to make.

“but suppose that tomorrow somebody wants to add X here…”. Be wary of this design principle. Be very wary. Unless “tomorrow” is a real date in the future, and “somebody” is a real person, this design principle can lead you down a deep rabbit hole with nothing but dirt at the bottom.

http://avilay.wordpress.com/2012/09/01/what-is-good-software-design/

Re-use - I like re-use, really I do. But I suspect a lot of time is spent polishing code for re-use and it gets stuck away and never touched. There is some very interesting and honest work done on re-use that concludes that the payback of planned re-use is not quite what you would expect.

Arnoud de Kuijper - Test and Measurement Solutions did an excellent presentation at the European CLA Summit, in it he introduced SMURF

A version is linked here

Scalable
Modular

Unique
Reusable
Flexible

I prefer this mainly because I love the little blue fellas. Also Flexible is very very important to me and Unique is actually a grown up way of describing what we do. We have a couple of standard templates but quite a lot of what we do is unique from system to system.

Now I would like to add a few more to the list.

I can't believe Functional and Robust are not on the list. Readable, Debuggable and Maintainable are extremely important design considerations too. Measurable is also an increasingly important design consideration, especially in RT or control systems. As mentioned earlier Configurable as a sub-set of scalable is a very important design criteria for us.

Now how do our customers mark our software if they have to allocate points and how does this compare to our own marks?

James Shore writes about good and great software design in an article titled Quality with a Name. From the article:

A good software design minimizes the time required to create, modify, and maintain the software while achieving acceptable run-time performance.

Also these requirements don't always play nice together, many of the techniques for extensibility seriously affect readability and so it goes on.

So am I dismissing SMORES out of hand?

I think SMORES is useful if you are designing APIs and toolkits, I think it is less useful for projects.

So perhaps we need acronyms for each type of use case.

Or

Perhaps we should not use acronyms blindly.

Lots of Love

S.T.E.V.E

Comments
Knight of NI

When it comes to these types of acronyms, it is really just a mnumonic device.  And if you make a really long acryonym, nobody is going to remember what it means.  I have enough trouble remembering SMORES, and I'm used to the version where the 'O' is part of MOdular.  Now I have another word to remember!!!

My point is, these are good for teaching newbies things to look out for, to help them write better code.  Once they are drilled in just by use, the acronym becomes less and less useful to that person.

And the concepts often work together and agaist each other.  But engineers are taught to do balancing acts.  Can't cut down overshoot without increasing rise time.

As always, great article, Steve.  Always good reading your articles to get my mental juices going.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Active Participant

crossrulz wrote:


                       

And the concepts often work together and agaist each other.  But engineers are taught to do balancing acts.  Can't cut down overshoot without increasing rise time.

Thanks mate, that's a nice analogy.

I'm very interested in these trade-offs and have a feeling that the pendulum has swung too much in 1 direction at the expense of readability and other things that make LabVIEW good to use. Hopefully this type of article is going to form the basis of an NIDays presentation on Design Trade-offs.

I'm also interested in absolutes, so if someone declares something to be absolutely right I have to pick and prod at it. One thing I've learnt from these discussions is to declare a use-case and what is right for a certain use-case is not right for another.

Another interesting aspect is more connected to the type of person writing the code, what is good for one is not necessarily good for another and that's a whole new barrel of monkeys.

Knight of NI

swatts wrote:

I'm very interested in these trade-offs and have a feeling that the pendulum has swung too much in 1 direction at the expense of readability and other things that make LabVIEW good to use. Hopefully this type of article is going to form the basis of an NIDays presentation on Design Trade-offs.


                   

As the single Architect in my group (I have a lot of new-grads), my goal is to make everything as simple as possible for those who will be using/updating/fixing my code.  I will test the crap out of anything that is remotely complicated.  But then I leave a nice API that people just call my code (that I'm 95% is good) and then they can just run with it.  I recently had a project with TestStand where I tried to extrapolate as much reuse code as I could and then they had a nice simple interface to do 98% of the job for them.  I spent an extra dime up front, but it saved a dollar in team execution.  Yes, I had to make some of the reuse code a little more complex, but my team members just say a simple interface that they could quickly use.  So I guess it is more than just say "it is simple".  It goes into "it is simple for XXX", and play the tradeoff game from there.

Now I feel like I'm just rambling.  Maybe I should just go and let my thoughts develop some more...


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Member

A good software design minimizes the time required to create, modify, and maintain the software while achieving acceptable run-time performance.

I like this - why spend 40 hours optimising something so it runs with 1% CPU usage when it only ran at 5% anyway (and in doing so, make it less maintainable and more complex). Usually cheaper to upgrade the PC...

Active Participant

Ditto that, in the world of fixed price work, optimised is an expensive option.

Active Participant

Hi Steve,

Excellent article a usual.

I think Reuse is not focus on reusing a module, it has more to do with not reinventing the wheel everytime. For example, I have a package that I use for most of my projects that deals with configuration files. I just reuse that package everytime and trust that the code works.

I have been to companies where they have 10 different copies of the same instrument driver, where each copy has a slight modification. Most of the time, they don't even bother on renaming the VI that was changed or modifying the icon. So down the line, another developer uses their own version of the instrument driver and things start to fail.

So, when I work on a new project and I start to see a library of VIs take shape that might potentially be used later on for another project, I just make a new project for that, create a VIPM package and start using the built package. Those libraries get improved with each new project that uses them.

crossrulz

As the single Architect in my group (I have a lot of new-grads), my goal is to make everything as simple as possible for those who will be using/updating/fixing my code.

I agree with this statement, the code and the design can not be judged on its own, you need to know your audience. Sometimes as developers/architects we pay attention to the UX (user experience) of the final application and forget about the DX (developer experience). Who is going to be maintaining your code will determine some of the design decissions you make.

Now, I am rambling too...



Get Going with G! at G Central GCentral
DQMH Lead Architect * DQMH Trusted Advisors DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?

Active Participant

We get a great deal of use from re-using domain templates i.e. we export our GenApp template from subversion and it has all the directories, documents, screen handling, config, state machine etc etc already laid on for us. I think rather than picking on the elements of SMORES as having worth it's more a matter of nuance.

So for example I've just finished a project where scalability is extremely important, they wanted 1..n cRIO based logger systems and couldn't define how many upfront. So I used dynamically spawned daemons etc etc. The block diagram was understandable because you could see the problem I was trying to solve. But I wouldn't use these techniques for everything, because there is a readbility trade-off that I don't like.

The not so hidden message is that is for software to be understandable the solution needs to be writ large in the block diagram. so in this case it was.

SMORES.png

If I wanted to use that particular acronym (I crossed out modular because if you can't work out code should be modular I'm not letting you near one of my customers!)

This nuance concept resonates very well with Arnouds kaleidoscope idea, and is also linked to use cases. For me I would like to add weighting to the elements in the kaleidoscope rather than selecting particular elements.

This is the place to ramble and I love the honing of rough ideas that comes out in the comments.

Member

Hi Steve,

 

Ran across this when looking for my old SMORES stuff to pitch to someone this week.  Thanks for the link!  I forgot about that old Google site.

 

Good article :-) 

Even though this article was from 2014, allow me to clarify...

 

Optimized vs Simplified.  Optimized really has to do with taking advantage of parallel processing, order of operations, better algorithms that can accomplish the same functions, reducing the disk writes or other time consuming tasks.  Simplified is really about going back to your finished product and saying, is this this simplest way I could have accomplished this, or is this obtuse or difficult to maintain.  So yes, you are right, there is overlap in my engineering brain too, and for that reason I used SMoRES for many years, making Modular take both the Mo.  But as a memory device, I eventually started using the "O" to remind me about the importance of teaching dOcumentation to newbies while covering these other topics.  Even clean code can be difficult to touch if you are missing the "whys" that go with your VI's.

 

As for Reusable, well, Reuse in the small (small functions) is a well solved problem, and Reuse in the large (entire applications) really comes down to functional design patterns.  So learning to harvest your low level functions, and to work with design patterns, are both critical skills for young (and old) developers.

 

Maintainable really comes from the rest of SMORES in my opinion. 

 

Your acronym (and others) are all helpful.  What I found was that what I found was that SMORES was easy to remember, and each word had for me a unique aspect of programming I wanted to impart - and if I could get someone to do those 6 things, I was WAY ahead of the game ;-)

 

Anyway, glad to see that this concept still has traction all these years later!  I think I shared this with Stormin Normin back in the 2000 timeframe?  And he took it to new heights when he joined NI.  Cool.  Very cool.

 

Tim Jones

 

 

Active Participant

Hey Tim,

Sorry for some reason I didn't get notified by your comment (now I'm running through my old articles!).

You really were ahead of the game! In my scribblings I said that it is very applicable to APIs and you can see the influence writ large through LabVIEW and it's so much better for it!

I come at it from a project bias and as such I was interested in the nuance of applying this to LabVIEW projects rather than LabVIEW tools. It's led me down some very interesting paths, the most interesting/rewarding is applying different techniques at different times in a project.

So I thank you for your input to our world, it's very much appreciated and I'm thrilled about this comment. Will be smiling today!

Love

Steve