June 10, 2012
Late Night Thoughts On "It Works For Me"Before I retire up the Apples & Pears to Bedfordshire, I just wanted to share some thoughts on an ongoing discussion I've been having in That Twitter with Dan North (@tastapod).
Now, I'm aware that I can be overly dismissive of people making claims that aren't supported by evidence, and I feel it's important to go beyond the limitations of 140 characters to try - and probably fail, as usual - to express what I'm really thinking about all this.
To cut a long story short, Dan's been writing and speaking a lot recently about a discovery he's made that involves writing software that is not - GASP! - test-driven. Indeed, there may be no automated tests at all. And he's finding that in the context he and his colleagues are working in, not TDD-ing is sometimes better and faster at delivering value, and, presumably, at sustaining that pace of innovation for business advantage.
Dan, if you're not aware, comes very highly recommended by programmers who also come very highly recommended. If programmer kudos was PageRank, and recommendations were web links, Dan's home page would be bbc.co.uk. So, at a personal level, I'm inclined to just shrug and say "fair enough, what he said".
But I've been at this game a while (and I've even won the odd round), and my two decades programming for shiny objects and sexual favours has taught me that our industry is rife with claims.
Some are out-and-out lies. The people making them know full well it's not true, and what they're saying is designed purely to appeal to the people who are holding the purse strings - a highly suggestible bunch at the best of times.
I think it's very doubtful that Dan doesn't believe what he's telling us, from what I've heard of him. But some very genuine people, with all the best intentions, also make claims that turn out not to be true. Software is a very complicated business, and mirages are not uncommon.
I know how prone I am to succumbing to that feeling of "productivity" I get when I cut corners. It's very seductive.
My Mum used to drive a Citroen 2CV (mint green with stripes on the roof - it looked like a boiled sweet on wheels), and I remember the sheer thrill of us coasting down hills, feeling like the car could take off at any moment. We must have been doing all of 45 miles per hour.
I've discovered, from my own experiments into quality-centred practices that, when I actually look back at what's been achieved objectively, what felt fast while I was doing it can turn out to be slower in real terms.
So, my issue is this: it's not that I think Dan's misleading us, or that he's necessarily misleading himself, either. What he's discovered may well be real, and may even be reproducible.
But, right now, he's that lone parent who didn't vaccinate their children and found that their children got better. Or that they think their children got better, and that it had something to with not vaccinating them. Maybe they did, and maybe it was.
However, before I start advising teams to not bother with the vaccinations - vaccinations whose efficacy is supported by a growing body of evidence in a wide range of situations (everything from embedded software in vending machines to labyrinthine distributed "enterprise" systems via the BBC iPlayer) - I need to see a similar body of evidence to persuade me that in some situations, skipping the jabs will be better for them.
I'd also like to understand why. I'm fairly convinced now of the causal mechanisms that link defect prevention to higher productivity, having seen so many wide studies published by the SEI, IBM, NASA and other august bodies. Taking steps to prevent issues saves more time later than it costs now. Simples.
I'm also aware of the limits of defect prevention on saving us time and money, and why those limits exist (e.g., in safety-critical software).
The same goes for the relationship between our ability to retest our software and systems quickly, frequently and cheaply. I'm not aware of any other way than by automating our tests, and I'm especially aware of the economic value of automated unit tests (or some automated equivalent - e.g., model checkers), having spent very little time in a debugger personally since about 2002.
It's not inconceivable that somewhere in the spectrum of quality vs. cost vs. test automation etc etc, there is an oasis that Dan's discovered of which we're all currently unaware. But if there is, then it's a tropical island in the middle of the Arctic ocean. It runs contrary to the picture that surrounds it - a picture that's still being corroborated as more and more data comes in, and for which no credible data currently exists to contradict it.
Right now, Dan's telling us he's been to this undiscovered island, and is describing it to us in vivid detail - thrilling tales of strange and exotic animals, wierd and wonderful plant life and azure-blue waters lapping at golden sands. But he's yet to give us the photos, videos, or any samples of unique flora and fauna that might convince me that he wasn't actually in Fiji (that's the danger of flying without instruments). Most important of all, he needs to give us the grid reference so we can all go and find this island for ourselves.
He tells me he's in the process of doing this now, so we can try his approach on our own projects and see what we think. This is very encouraging.
My hope is that we'll finally see this mysterious Lost World for ourselves and know that he was right.
Either that or we'll confirm that he is indeed lost in Fiji.
April 19, 2012
Enough With The Movements! Movements Are Stupid.
I've been around the block a few times as a software developer, and as such I've witnessed several movements in the industry come and go.
Each movement (object technology, patterns, component-based, model-driven, Agile, service-oriented, Lean, craftsmanship etc etc) attempts to address a genuine problem, usually. And at the core of every movement, there's a little kernel of almost universal truth that remains true long after the movement that built upon it fell out of favour with the software chattering classes.
The problem I perceive is that this kernel of useful insight tends to become enshrouded in a shitload of meaningless gobbledygook, old wives tales and sales-speak, so that the majority of people jumping on to the bandwagon as the movement gains momentum often miss the underlying point completely (often referred to as "cargo cults").
Along with this kernel of useful insights there also tends to be a small kernel of software developers who actually get it. Object technology is not about SmallTalk. Patterns are not about frameworks. Components are not about COM or CORBA. Model-driven is not about Rational Rose. SOA is not about web services. Agile is not about Scrums. Responsibility-driven Design is not about mock objects. Craftsmanship is not about masters and apprentices or guilds or taking oaths.
In my experience, movements are a hugely inefficient medium for communicating useful insights. They are noisy and lossy.
My question is, do we need movements? When I flick through my textbooks from my physics degree course, they don't read as a series of cultural movements within the physics community. What is true is true. If we keep testing it and it keeps working, then the insights hold.
What is the problem in switching from a model of successive waves of movements, leaving a long trail of people who still don't get it, and possibly never will, to a model that focuses on testable, tested, proven insights into software development?
I feel for the kid who comes into this industry today - or on any other day. I went through the exact same thing before I started reading voraciously to find out what had come before. They may be deluged with wave after wave of meaningless noise, and every year, as more books get published about the latest, greatest shiny thing, it must get harder and harder to pick out the underlying signal from all the branding, posturing and reinvention of the wheel.
You see, it's like this. Two decades of practice and reading has inexorably led me to the understanding that very little of what I've learned that's genuinely important wasn't known about and written about before I was even born. And, just as it it is with physics, once you peel away the layers of all these different kinds of particle, you discover underlying patterns that can be explained surprisingly succinctly.
For those who say "oh, well, software development's much more complicated than that", I call "bullshit". We've made it much more complicated than it needs to be. It's a lot like physics or chess (both set-theoretic constructs where simple rules can give rise to high complexity, just like code): sure, it's hard, but that's not the same as complicated. The end result of what we do as programmers can be massively complicated. But the underlying principles and disciplines are simple. Simple and hard.
We do not master complexity by playing up to it. By making what we do complicated. We master complexity by keeping it simple and mastering how software comes about at the most fundamental level.
Logic is simple, but algorithms can be complex. A Turing Machine is simple, but a multi-core processor is complex. Programming languages are simple, but a program can be highly complex. Programming principles are simple, but can give rise to highly complex endevours.
Complexity theory teaches us that to shape complex systems, we must focus on the simple underlying rules that give rise to them. At its heart, software development has a surprisingly small core of fundamental principles that are easy to understand and hard to master, many of which your average programmer is blissfully unaware.
True evolution and progress in software development, as far as I can see, will require us to drop the brands, dump the fads and the fashions, and focus on what we know - as proven from several decades of experience and several trillion lines of code.
January 15, 2011
Enough With The Software Holy Wars!Religions are funny things.
It turns out the Christians, Jews and Muslims are all worshipping the same god. Where they disagree is on the detail of what that god has for breakfast and what his policy on beards and public holidays is.
We can point and laugh, of course. But we can be just as bad.
You see, it also turns out that "software craftsmen", "software engineers" and "Agile Software Developers" all worship the same god, too. We just disagree on the finer details of precisely how our god expects us to achieve the exact same results we all seem to agree we should be striving for.
There is no disagreement that our mutual god's primary commandment is that Thou Shalt Not Write Software Thy Customer Didn't Want.
Nor do we disagree that we will need to iterate to converge on the most useful, usable software.
We're also in agreement that testing should happen as early as possible and as often as possible if we're to avoid wasting the bulk of our time fixing bugs that slipped through the net.
Indeed, in every important respect, we agree on everything. (Well, anyone whose opinion matters agrees, anyway.)
Where we disagree is on whether we should call them "use cases" or "user stories", and on whether we should write our tests first or write them after the code, or whether we should put aside time to deliberately practice these skills or whether we should join an accredited professional body and get certified on them. And so on.
The underlying beliefs, the foundations of what we do and why we do it, have remained unchanged for decades. The Old Testament of software development is a shared religious text among anyone who does it well.
In case you need reminding, here are the Ten Commandments Of Software Development:
- Thou Shalt Not Write Software Thy Customer Didn't Want
- Thou Shalt Iterate Thy Solutions, Indefinitely If Necessary
- Thou Shalt Test Early & Often
- Thou Shalt Manage Versions and Configurations Of Thy Software, Even When Working Alone
- Thou Shalt Not Jump Straight Into Writing Code If Thou Hast Not Put A Bit Of Thought Into The Design
- Thou Shalt Not Write Code That Is Hard To Change
- Thou Shalt Not Integrate Or Release Untested Code
- Thou Shalt Not Create User Interfaces That Are Hard To Use
- Thou Shalt Treat Functional & Non-Functional Requirements Equally
- Thou Shalt Automate Oft-Repeated Tasks & Share Oft-Repeated Code
Whether we call ourselves "craftsmen", or "engineers", or "artisans", or simply "software developers" or even "computer programmers", we all have to hark back, by necessity, to the basic foundations of writing software professionally.
Each of our commandments implies a discpline, with it's own skillset, it's own practices, it's own standards and it's own body of knowledge. We may disagree on the detail of exactly how to follow each commandment, but fundamentally, underneath it all, we're all worshipping the same god.
So, enough with the Holy Wars! Let's get on and get better at delivering working software that will satisfy, maybe even delight, our customers.
November 22, 2010
Nothing Killed Waterfall. It Evolved Into Half-Arsed Agile.Robert Martin has posted a very interesting article warning of the dangers of elitism in Agile; in particular the elitism of Scrum Masters as project managers or team leaders, which was never what was intended for the role of a "coach" or "process champion" in those early days of Agile.
Quite rightly, Uncle Bob warns that the elitism that killed Waterfall could kill Agile. Organisations have replaced architects and analysts with Scrum Masters, and another revolt from the people who actually write the software and test the software is fermenting.
I'm not convinced that anything killed Waterfall, though. Like the dinosaurs, there could be another explanation for their extinction. Agile isn't the asteroid that wiped out the Big Process and Big Architecture elite. It's the disruptive influence that forced them to adapt in order to retain their authority under the nuclear winter of an increasingly "agile" and "self-organising" world.
The reality many of us talk about is that teams that are genuinely self-organising and that genuinely respond to feedback are few and far between. As Brian Marick put it, only the word "Agile" may have crossed the chasm.
They say that many a true word is said in gest. I'm sure many of us have first-hand experience of the kind of nonsense described in the Half-Arsed Manifesto. This is real enough, sadly. Too many teams are wearing Agile clothes, but underneath they are something very different, and quite familiar.
Most "Agile" teams I come into contact with are recognisably the direct descendents of Waterfall. They retain the vestigial limbs and organs of command-and-control and of plan-driven software development and Big Design Up-Front. Just as birds are really dinosaurs with feathers, many Agile teams are just Waterfall teams with stand-ups and Scrum Masters.
I've seen this first-hand. A project manager fiercely defended her Waterfall process, so the developers defied her and did XP anyway. And they succeeded. The bosses ears pricked up and suddenly Agile was something they wanted to see more of. Seeing the writing on the wall, she went and got certified in Scrum. And now she fiercely defends Agile, or at least, her version of it. She still demands schedule commitments. She still demands the complete UI design and thick requirements document before coding begins. She still demands that developers do what she tells them to do. It's the same old song, but she's singing it in the key of Scrum. We all saw a way to deliver more value, she saw a way to retain her control. Such leopards will never change their spots.
Deep inside the rational, modern Agile brain pulses the irrational, neanderthal limbic system of Waterfall. And while we may be consciously aware of a logical and progressive thought process that drives our projects, it's quite possible that most teams only become aware of that after their fearful and superstitious Waterfall subconscious has already made the decisions for them.
The elite of 90's Big Process Software Engineering never went away. Many of them got certified and are still up to their old tricks. Most of us are still staying at Hotel Waterfall, under the same old management, getting the same poor service from the same haughty and unhelpful staff. Check under the chic, minimalist new wallpaper and you'll find that familiar old over-elaborate floral print.
February 15, 2010
Wheel-driven ReinventionOne aspect of software development which is at once both amusing and troubling is the ability of us young whippersnappers to completely ignore what's gone before and reinvent established wisdom in our own image - often stealing the credit.
Take testing as an example. What do we know about testing software today that we didn't know, say, thirty years ago? Sure, we have new tools and testing has to fit within new approaches to the process of writing software as a whole, but fundamentally what have we discovered in the last decade or so?
Testing behaviour still works, by necessity, much as it has always worked by necessity. We must put the system under test in some desired initial state, then we must provide some stimulus to the system to trigger the behaviour we wish to test, then we must make observations about the final state of the system or about any behaviours that should have been invoked (e.g., a remote procedure call or a database request) in response to the combination of our stimulus and the initial conditions. And this process must be repeatable and predictable, like any good scientific test.
Though the culture of testing software may have evolved, much of it for the better, and the technology may have improved (though that is questionable), and though there are undoubtedly more people testing their systems today, when it comes to the business of writing and executing tests, there's really nothing new under the sun.
The same is true of many aspects of contemporary software development. Like it or nay, iterative and incremental development is older than C. We just weren't doing it back then, in the main.
Indeed, pick any "new" aspect of development and trace it back to its roots, and we discover that most novelties are actually much older than many of us thought. Objects are an invention from the sixties. Use cases hail from the seventies. Responsibility-driven design was being practiced before Frankie told us to Relax. UML existed in a fragmentary form before the Berlin Wall came down. People were writing code to satisfy tests back when those tests were stored on magnetic tape. Indeed, some of the descriptions of programming that was done for the very first computers rings bells with those of us who practice that black art today.
Younger developers like me, though, seem to readily believe that our time around is the first time around and feel no compunction to educate ourselves about the achievements of "old-timers", preferring instead to invent things anew - with sexier names and shinier tools, admittedly.
Our desire to reinvent goes as far as redefining words that already have a well-established definition. "Agile" no longer means "nimble" , "quick" or "spry". Today it apparantly means "communication, feedback, simplicity and courage". Or "iterative and incremental". Or "evolutionary". Or "Scrum-Certified". I caught someone the other day proferring their definition of "testable", which apparantly now requires us to go through "public interfaces". This is bad news for many scientists, who must now rewrite their peer-reviewed papers to incorporate the appropriate programming language with which to express the "testability" of their theories.
If software development was physics, we might expect newcomers to work through and understand the current body of knowledge before they start adding to it. That way, at the very least, we could avoid a great deal of duplication of effort. We may also avoid the tendency of our industry to throw "old-timers" on the scrapheap just because, even though they are probably just as current in their practical ability to deliver working software, they're not "down with the kids" on all the latest street slang for concepts that have been kicking around the block for decades.
The thinking of our elders and betters is far from irrelevent and outmoded. We can still learn a thing or two from the likes of Jacobson, Knuth and Hoare, should we choose to reject fashion in favour of substance in the approach we take to our work.
March 22, 2009
Physicist Tests Journal of Cultural Studies - Finds Relativism Gone Mad!Alan D. Sokal, a physicist at NYU, submitted a wordy article to a leading journal of cultural studies packed full of outrageous and totally unsupported claims suggesting that physical reality is a social construct and even that science should be led by a political agenda. And it got published. Without any corrections.
As Sokal puts it:
"What concerns me is the proliferation, not just of nonsense and sloppy thinking per se, but of a particular kind of nonsense and sloppy thinking: one that denies the existence of objective realities, or (when challenged) admits their existence but downplays their practical relevance. At its best, a journal like Social Text raises important questions that no scientist should ignore -- questions, for example, about how corporate and government funding influence scientific work. Unfortunately, epistemic relativism does little to further the discussion of these matters.
In short, my concern over the spread of subjectivist thinking is both intellectual and political. Intellectually, the problem with such doctrines is that they are false (when not simply meaningless). There IS a real world; its properties are not merely social constructions; facts and evidence DO matter. What sane person would contend otherwise? And yet, much contemporary academic theorizing consists precisely of attempts to blur these obvious truths -- the utter absurdity of it all being concealed through obscure and pretentious language."
One can't help wondering if many of our leading professional publications would be just as easily bamboozled by relativist nonsense. I have read articles that, at the time, I thought must surely be spoofs.
Software development abounds with outrageous and totally unsupported claims and the "epistemic relativism" Sokal accuses Social Text of championing. Most specifically, the pernicious and ultimately disastrous notion that your way is as good as my way is as good as their ways (so everybody gets to be right - hoorah for everybody!) and that, in software projects, there is no objective reality and all that matters is perspective and discourse. In less fancy language, we get to sit around yapping all day and everybody's opinion is equally valid - and evidence doesn't matter.
Indeed, as critics of metrics are fond of pointing out, reliance on evidence leads to oppression. I would argue that misinterpretation and/or misapplication of - often poor quality - evidence can and does lead to bad things in all kinds of organisational life. But I don't infer from this that seeking evidence is therefore always wrong (far from it), or that the reality of software and software development itself is somehow beyond empiricial understanding in certain key respects.
This is currently a very unfashionable view, and one for which I'm often chided by my peers. But I increasingly believe it to be important, and see a dark future for our profession if we continue down the slippery slope of woolly thinking that we're on.
March 18, 2009
The Movement Formerly Known As "Software Craftsmanship"As with all intellectual movements, it seems the mere act of choosing a name is enough to stoke up heated debate.
It's actually not possible to use words currently in existence because they all have some kind of semantic baggage, and someone, somewhere is going to take offence somehow.
One possible solution is to take a leaf out of pop singer Prince's book and adopt an abstract symbol that's currently not in use.
The Movement Formerly Known As "Software Craftsmanship"
But then again, if you've ever taken the ink blot experiment, you'll know that even abstract shapes can get people hot under the collar.
On a related note, while some argue over the name, others continue to argue over what it is we actually believe in. Already there's a manifesto that's generating fun and games on discussion groups and blogs around and about the countryside. Meanwhile, a few folk seem to be venturing out into the Cursed Earth to preach the good word of Software Craftsmanship - from what bible I do not know, because we're still writing the outline.
Certainly, there seem to be different schools of emerging. Some, for example, see apprenticeship as a key requirement. I don't. Don't get me wrong, I think apprenticeships is a potentially great way to learn and improve. No argument there. But are there other ways? And are the people who tread that other path really "software craftsman"? (Sorry, are they really ...) Yes, I rather think they probably are.
Which all brings me to the conclusion that we may be overthinking things. Again. Because we're like that.
March 6, 2009
My Lovely But Still Overdue SC2009 SummarySo I finally got around to following up on last week's amazing Software Craftsmanship conference. With the formalities out of the way, I just wanted to add some personal notes about the experience, because that - apparantly - is what blogs are for.
First of all, I just want to go on record and say that I got a real kick out of organising this conference. I had some great help from Peter Camfield, Kerry Jones, Robin Doran and many others that meant that pretty much everything went smoothly on the day. It was an absolute pleasure to put together, and hearing the very positive - some might even dare to say "gushing" feedback on and after the day was the icing on the cake.
I was really chuffed with the programme we ended up with, and - contrary to how it almost always works - doubly chuffed to see expectations being exceeded in the execution of those sessions. I think we got a kick-arse, A1 bunch of sessions and session leaders, personally. I couldn't have wished for a better start to what may well turn into a new series of conferences and other related events.
Talking of feedback, I really, really think we're on to something here. Software craftsmanship is not a flash in the pan, I suspect. It's not just Le Fad De Jeur. Being surrounded by 100 committed professionals who genuinely care about what they're doing and who are 100% dedicated to learning and improving has been one of the highlights of my checkered programming career. I want more!
And I'm going to get it! SC2010 is definitely on the cards now, and I'm feeling very confident about pushing the envelope next year and taking this conference boldy to places where no conference has been before.
But 2010 is still a loooooong way aways yet. SC2009 had a palpable energy and momentum. You can feel it when you watch the Vox Pops video. And a sentiment that came out in much of the feedback I heard on the day is "let's make sure this doesn't fizzle out". So I'm looking with some urgency into setting up a regular get-together here in London where we can get hands on together, run dojos and katas over a coffee or a beer. Frankly there's been too much lips-flapping and not enough key-bashing of late, and we need more opportunities to - as Frank Zappa so eloquently put it - Shut Up And Play Our Guitars!
But London's just one little part of the world where craftsmanship has caught fire. There are other flames being fanned in far-flung places like Chicago, for example. Ironic that in a city named after their politician's empty rhetoric (the "windy city") we have a strong and rapidly maturing tradition of software craftsmanship growing thanks to folk like Micah Martin at 8th Light, Dave Hoover at Obtiva and - lest we forget - Uncle Bob Martin and Mike Feathers at Object Mentor. Micah crossed the pond especially for SC2009, I'm told, keen to see what's going down here in London. I'm equally keen to forge links with craftsman in Chicago and wherever else in the world they may be found.
In these days of global warming and rising fuel costs, though, we should look for ways to achieve rich international collaboration and sharing through technologies like Skype, desktop sharing, videoconferencing and atomic carrier pigeons (okay, I may have made that last one up). Hopping on planes and seeing folk in the flesh is going to be a necessity, I'm sure. But it's not a scalable or sustainable route to the level of sharing that I think we're going to need to really drive craftsmanship forward across borders.
On a totally personal note, it was very refreshing to see the "A" word taking a back seat at a conference for once. sure, lots of Agile folk there and lots of Agile practices, but the word that dominated the day was "craftsmanship" - which is as it should be now.
So, my summary summarised - By Jingo, I Think We May Be On To Something, Here!
Well, that's enough superlatives for one day. I'm off to read a whitepaper on some Model-driven Architecture nonsense.
Until next week, toodle pip!
Software Craftsmanship 2009 Follow-UpThis went out as an email to delegates, but is reproduced here for completeness
First of all, if you made it to SC2009 on Feb 26th then a big hearty thanks for helping to make the day the success that your generous feedback suggests it was.
An especially big thanks goes to everyone who ran the sessions. Your hard work is much appreciated.
Also, many, many thanks to Robin Doran from BBC Backstage, Peter Camfield from BBC Worldwide and Kerry Jones from BBC Future Media & Technology for all your invaluable assistance in putting the event together. Thanks, too, to all the BBC delegates who helped out on the day. You did a sterling job.
The event was very generously sponsored by BBC Worldwide and BBC Backstage. You should check them out, 'cause they're doing some pretty cool stuff these days:
A few announcements:
* Were you at Keith Braithwaite's excellent TDD As If You Meant It? session? Do you still have a copy of the code you worked on? If the answer is Yes, then you might want to consider donating it to science! Please send zipped-up copies of your code to Dr Sue Black from University of Westminster so she and Steve Counsell from Brunel University can perform deranged experiments on it that hopefully will produce further insights into software maintainability.
* Don't forget to pay a visit to Sue's website dedicated to Saving Bletchley Park and see if you can help.
* A reminder about the upcoming Software Practice Advancement conference, which is being held in London this year at the BCS offices in Covent Garden starting on April 5th. I'm running a session on scaling up design reviews using automated code analysis. Apart from that, the rest of the programme looks pretty good, though ;-)
* Another reminder about Rachel Davies' Agile coaches gathering event which is being held at Bletchley Park on 22-23rd May
Immo Huneke has posted the outputs from his excellent and intimate session on My Favourite Keyboard Shortcuts on the - now publicly accessible - conference Wiki:
Gojko Adzic has posted slides and related material from his well-received session on Specification Workshops:
Nat Pryce's notes for his fascinating session on Testing Asynchronous Systems can be find here:
Ivan Sanchez posts his session materials for 5 Reasons To Have Coding Dojo here:
Feedback from the Blogosphere
Kerry Buckley very nicely summarises some of the sessions:
Gojko Adzic's great write-up of TDD As If You Meant It:
Markus Gaertner's summary of the conference:
Diego Pino shares his thoughts here:
Richard Fennell gets his thoughts down on virtual paper:
BBC Worldwide's Rob Bowley blogs about SC2009 and posts a great pic that illustrates how busy lunch was!
.NET journeyman Tim Ross posts:
SC2009 Vox Pops video
Will there be a Software Craftsmanship 2010 conference? Very probably, yes. Watch my blog for developments, and get your thinking caps on for session ideas.
Where do we continue this dialogue? A good start would be to sign up for the Software Craftsmanship Google Group. Many of the folk you might have met on feb 26th are known to frequent the Extreme Tuesday Club in London. Also, you'll find us at Software Practice Advancement, XPDay and many other Agile-leaning events.
What about a specific regular meet-up on Software Craftsmanship? Bingo! Great idea. What a clever fellow you are for suggesting it :-) Yes, we shouldn't let the energy and momentum we gathered at SC2009 fixxle out, so I'm going to propose a regular meeting that will be a sort of mini-SC2009 where we specifically meet-up with our laptops for hands-on learning, sharing, practice and alcohol. (The four major food groups, I think you'll find.) The XTC venue is too noisy, really. So I'll be seeking out a friendly venue with a decent-sized function room and maybe even a projector and screen. I'm also leaning very heavily towards a weekend timeslot, because my brain is usually pretty frazzled by 7pm on a weekday! Keep an eye on my blog, and on the Google group, for announcements very soon.
I'm sure I've forgotten something, but isn't that always the way. Drop me a line with any thoughts, complaints or offers of easy money.
February 17, 2009
Are We No Better Than Those UFO Nuts? The Case for a Software "Enlightenment"Back to the subject of UFOs and the paranormal...
One thing that I find very entertaining about the UFO community is how authoratitive they manage to sound whilst piling speculation on top of conjecture on top of supposition on top of a very shaky bedrock of fundamental assumptions.
While less colourful students of the phenomenon dare only to ask "are THEY here?", many UFO "researchers" settled that debate decades ago in their own minds and are now preoccupied with more advanced questions like "are the small grey insect-like aliens at war with the tall lizard-like ones?" and "what does the High President of the Galactic Federation think about this whole Isreal/Palestine thing?"
Check out this classic example of the ouvre from self-styled (and what a style that is!) UFO expert Ed Komarek. How many totally unsupported claims did you count?
It's easy to laugh, of course. And, yes, I do think these folk are either completely ga-ga, or just plain crooked and they know they're making it up. The poor, ignorant saps who eat this stuff up from UFO fanzines ('cause that's what they are, folks - it's a cult of personality) and blogs and discussion groups are being led down a very long and windy garden path by charletans and nutcases who are every bit as screwy as astrologers and mediums - and priests, let's not forget.
At best we get pseudoscience. At worst, just plain drivel without even the shallowest attempt to justify it scientifically. UFO lore is 99% "he said, she said", with researchers relying mostly on anecdotes and spurious official memos to back up their outrageous claims.
But when I read the books, magazines, blogs and message boards of our illustrious software development community, I'm ashamed to say that we are equally piling speculation upon conjecture upon supposition on top of a very, very shaky foundation of assumptions. Pseudoscience is rampant in software development. Long-since debunked (if they ever were talen seriously) pop psychology and sociology, and totally antiquated or beyond-the-edge-of-the-fringe management theories abound. Everything from Myers-Briggs Types to the masterpiece of pseudoscience that is the Theory of Constraints - our profession is stuffed to the gills with unproven management theories that are actually nothing more than old wives tales and voodoo.
And it doesn't stop there: alarmingly, much - actually most - of what we say about writing software itself is also just a load of old mumbo-jumbo when you scratch beneath the thin veneer. A lot of the received wisdom about software design has not been validated by experiment, and the causal mechanisms behind so much of what we consider to be good or bad design choices are simply not understood.
And for every one of us who seeks empirical answers through some kind of testable theory of "code mechanics", there are 100 more who are quite happy to believe that you should not use the Singleton Pattern simply because "the book said so".
Just as for every person who seeks scientific proof of alien visitation there are 100 more who are happy to accept that they're here - or, indeed, not here (because both positions are unscientific if they're based only on faith) - purely because Stanton T Friedman or Nick Pope says they are.
As software developers, we are living in a dark age of ignorance and superstition, and one of my great hopes for the next decade is a resurgence in interest in the science of software (as well as a surge in practice of the craft of software development - because the two are by no means mutually exclusive) and perhaps one day we'll look back and call this transitional period the software industry's very own Enlightenment.