Shaker Philosophy In Software Development

How does the ShakerPhilosophy? apply to software development?

Does it? Is it helpful?

I see strong parallels between the Shaker philosophy and other principles I've learned and used in software engineering, such as "DoOneThingWell?" (many Unix commands follow this principle) and "elegant" designs or code. I personally find simple, clear, focused, well-crafted, and elegant solutions (whether in software or anything else) to be wonderful.

Sure, if you apply the Shaker approach to a drastic degree, you leave out a lot of cool stuff because it isn't "necessary." You can get unhappy results by applying any single principle to the exclusion of all other considerations. But I think we usually err on the side of too complex, too much.

I'd like to see the emergence of more software craftsmanship - "Go see Susan, she makes the best Sensor classes around..." or "You need a good sort? Get one of Doug's, they're the best..." Some software people should be allowed, even encouraged, to spend more than a few fleeting weeks or months on a given problem space, to linger and experiment and refine some generally useful tools, classes, techniques. Perhaps we've gone too far in expecting IT professionals to be generalists and jacks-of-all-trades...

-- AndyMoore

Though it may be useful to draw a distinction between having objects that do one thing well, and people who do one thing well. People aren't objects.

Then what are they? The often utilized class hierarchy Person, Employee, Manager? These are not objects?

Why is it we know at all anything about the Shakers? Doesn't it have something to do with their approach to meaningful, useful, practical stuff. Just how much of the Stuff in your house fits this category? Only about 25% or so in mine. We could all probably be better off with shedding some of the 75%.

To put a positive sense here, Amen.

An example or two for BenKovitz to illustrate the principle:

1) I have used a CD burning program which started off ugly, crude, but stable, and improved over time. However, before they made the core product fully featured and polished, the company started adding stuff that wasn't needed, wasn't wanted, and wasn't part of the core product in principle, e.g.: a crude backup program and a crude media player, both of which were less richly featured than the ones already bundled with Windows, and one of which actually broke things that were already working. It also had it's own crude, utterly useless, built in file system 'Explorer', when it could have instead used the Windows shell, with all its pre-existing refinement and power.

I wouldn't have minded so much if the actual CD burning part had been well done at the time (after all, I didn't have to install those extras), but it still had lots of obvious areas of neglect.

2) Recently I trialled a program (which wasn't offered for cheap) that was supposedly designed to manage SQL Server databases with Visual SourceSafe. However, rather than concentrate on making it do this, the company had been content to do half the job (check a subset of the required objects into VSS but not the rest), effectively making it useless for its intended purpose (what the good of being able retrieve half a database from version control?). Yet, they had obviously spent a lot of time and effort building their own version of the SQL Query Analyzer that comes bundled with SQL Server, presumably so that the feature list for this program could look more impressive (complete waste of time when the core functionality is not fulfilled). It is with some sense of irony that I would add, as a footnote, that I achieved the desired result by spending half an hour writing and testing an 156-line MS-DOS batch file.

So think about the Stake-holders. You can't get them to really give you their "usefulness" criterion, but you can get them to show you how they like to work, tools they like to use, and value propositions they associate with use.

That said, the danger here is that, by focusing on what is necessary, you ignore opportunities for positive change and lateral thought. Doing that you can design yourself right out of the market. As ever, there are tradeoffs to make.

Cf. http://www.chinapage.org/gnl.html#11

-- PeterMerel

Sounds kind of like DoTheSimplestThingThatCouldPossiblyWork maybe?

Gee, I knew some of the XP practices were tried and true, but I had no idea any of them were *this* old! -- PaulChisholm

Look, it's really simple. The quote is simply a sweeping generalization, and as we all know, generalizations are ALWAYS wrong (even this one).

-- Graeme Defty

To the Shakers, it was philosophy: reducing nonessential work gains time for worship. They did essential chores as simply and efficiently as they could (DTSTTCPW) and no more (YAGNI). The beauty that resulted is what we recognize today. -- ChrisFay

AndyMoore, I agree with your sentiments re: SoftwareCraftsmanship. I believe OpenSource, more than any other model, leads directly to this. (Also see: NotInventedHere.) -- TobyThain

(From Yahoo group ExtremeProgramming thread: http://tech.groups.yahoo.com/group/extremeprogramming/message/147894 )

I find myself inspired by Shaker philosophy:

: "Don't make something unless it is both necessary and useful;
: but if it is both necessary and useful,
: don't hesitate to make it beautiful." -- Shaker dictum

"Don't make something unless it is both necessary and useful" = YAGNI.

"beautiful" = code quality. Code quality IS NOT gold plating. Gold plating is adding unnecessary functionality and/or generality.

: "That is best which works best"
: "Beauty rests on utility"
: "Simplicity is the embodiment of purity and unity" -- Shaker Maxims

"simplicity" = Do the simplest thing that could possibly work.

: "Do your work as though you had a thousand years to live and as if you were to die tomorrow." -- http://en.wikipedia.org/wiki/Shakers#Culture_of_work_and_further_extremities

IE: Iterative development. Always ready to release. "Truck Number" issues resolved.

-- JeffGrigg