Haacked, but not content; agile still treats the disease

Phil Haack wrote a
thoughtful, insightful and absolutely correct response to my
earlier blog post. But he's still missing the point.

The short version: Phil's right when he says, "Agile is less about managing
the complexity of an application itself and more about managing the complexity of
building an application." Agile is by far the best approach to take
when building complex software.

But that's not where I'm going with this.

As a starting point in the discussion, I'd like to call attention to one of Phil's
sidebars: I find it curious (and indicative of the larger point) his earlier comment
about "I have to wonder, why is that little school district in western Pennsylvania
engaging in custom software development in the first place?" At what point
does standing a small Access database up qualify as "custom software development"?
And I take huge issue with Phil's comment immediately thereafter: ""
That's totally untrue, Phil—you are, in fact, creating custom educational curricula,
for your children at home. Not for popular usage, not for commercial use, but clearly
you're educating your children at home, because you'd be a pretty crappy parent if
you didn't. You also practice an informal form of medicine ("Let me kiss the
boo-boo"), psychology ("Now, come on, share the truck"), culinary arts
("Would you like mac and cheese tonight?"), acting ("Aaar! I'm the
Tickle Monster!") and a vastly larger array of "professional" skills
that any of the "professionals" will do vastly better than you.

In other words, you're not a professional actor/chef/shrink/doctor, you're an amateur
one, and you want tools that let you practice your amateur "professions"
as you wish, without requiring the skills and trappings (and overhead) of a professional
in the same arena.

Consider this, Phil: your child decides it's time to have a puppy. (We all know the
kids are the ones who make these choices, not us, right?) So, being the conscientious
parent that you are, you decide to build a doghouse for the new puppy to use to sleep
outdoors (forgetting, as all parents do, that the puppy will actually end up sleeping
in the bed with your child, but that's another discussion for another day). So immediately
you head on down to Home Depot, grab some lumber, some nails, maybe a hammer and a
screwdriver, some paint, and head on home.

Whoa, there, turbo. Aren't you forgetting a few things? For starters, you need to
get the concrete for the foundation, rebar to support the concrete in the event of
a bad earthquake, drywall, fire extinguishers, sirens for the emergency exit doors...
And of course, you'll need a foreman to coordinate all the work, to make sure the
foundation is poured before the carpenters show up to put up the trusses, which in
turn has to happen before the drywall can go up...

We in this industry have a jealous and irrational attitude towards the amateur software
developer. This was even apparent in the Twitter comments that accompanied the conversation
around my blog post: "@tedneward treating
the disease would mean... have the client have all their ideas correct from the start"
(from @kelps).
In other words, "bad client! No biscuit!"?

Why is it that we, IT professionals, consider anything that involves doing something
other than simply putting content into an application to be "custom software
development"? Why can't end-users create tools of their own to solve their own
problems at a scale appropriate to their local problem?

Phil offers a few examples of why end-users creating their own tools is a Bad Idea:

I remember one rescue operation for a company drowning in the complexity of a “simple”
Access application they used to run their business. It was simple until they started
adding new business processes they needed to track. It was simple until they started emailing
copies around and were unsure which was the “master copy”. Not to mention all
the data integrity issues and difficulty in changing the monolithic procedural application
code.

I also remember helping a teachers union who started off with a simple attendance
tracker style app (to use an example Ted mentions) and just scaled it up to an atrociously
complex Access database with stranded data and manual processes where they printed
excel spreadsheets to paper, then manually entered it into another application.

And you know what?

This is not a bad state of affairs.

Oh, of course, we, the IT professionals, will immediately pounce on all the things
wrong with their attempts to extend the once-simple application/solution in ways beyond
its capabilities, and we will scoff at their solutions, but you know what? That just
speaks to our insecurities, not the effort expended. You think Wolfgang Puck isn't
going to throw back his head and roar at my lame attempts at culinary experimentation?
You think Frank Lloyd Wright wouldn't cringe in horror at my cobbled-together doghouse?
And I'll bet Maya Angelou will be so shocked at the ugliness of my poetry that she'll
post it somewhere on the "So You Think You're A Poet" website.

Does that mean I need to abandon my efforts to all of these things?

The agilists' community reaction to my post would seem to imply so. "If you aren't
a professional, don't even attempt this?" Really? Is that the message we're preaching
these days?

End users have just as much a desire and right to be amateur software developers as
we do at being amateur cooks, photographers, poets, construction foremen, and musicians.
And what do you do when you want to add an addition to your house instead of just
building a doghouse? Or when you want to cook for several hundred people instead of
just your family?

You hire a professional, and let them do the project professionally.

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services.
1-day or multi-day workshops available. Contact
me for details.