SMORES, SMURF or SCRFFMRDM

[swatts]

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