Damn! My Silver Bullet Appears To Be Made of Crap

[swatts]

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