Convergence

[swatts]

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.

Consideration	Low Level API/Driver	Framework	Customer Facing Final Application
Scalable	X
Optimized	X
Reusable	X	X
Extensible	X	X
Flexible		X	X
Configurable		X
Readable			X
Measurable
Functional			X
Robust		X
Maintainable			X
Testable	X
Unique			X

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