Slack, Quality, and Automation

I recently finished reading Slack : Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom DeMarco (co-author of Peopleware). This isn't a new book; it was first published in 2001, but I hadn't got around to reading it. (I assumed coming from DeMarco that it would be worth reading.)

I've read a lot of software development management books, so a lot of the book wasn't completely new to me. But there were a few ideas that stood out:

The key role of middle management is reinvention.
Like many people, I bought into the idea that most middle management is unnecessary overhead. DeMarco challenges this, quite convincingly I think.

Product quality has almost nothing to do with defects or their lack.
I'm not sure I agree with him totally on this one. He claims that a product with a lot of defects could still be a high quality product and people would still want to use it. Hmmm. Some defects maybe, but a lot? I'd probably put it less strongly as "a lack of defects is not sufficient for high quality". This wasn't exactly new to me, but it made me think. It's been a while since I read Zen and the Art of Motorcycle Maintenance. (Arguably one of the most profoundly important essays ever written on the nature and significance of "quality" and definitely a necessary anodyne to the consequences of a modern world pathologically obsessed with quantity. - Amazon) It's very easy, in product development, to fall into the trap of thinking that defects are the only factor in quality - and it's just not true.

When you automate the mechanical stuff, what's left is harder.
DeMarco calls this "the paradox of automation" - it makes the work harder, not easier. He's talking about automation in terms of knowledge workers. But what struck me was how this might apply to "automating" application development. As we automate the easy stuff with frameworks, wizards, libraries, and tools, does it end up making our job harder instead of easier? Of course, we're accomplishing more, so it's not pointless. But it's still ironic that in trying to make our jobs easier we're actually making them harder.

I find it frustrating with Suneido that no matter how much it has, people always end up wanting to do something that isn't supported. I thought this was just Murphy's law, but perhaps it's a logical consequence. Everything that's already supported becomes the base that people want to extend from. And because most of the "easy" stuff is handled, the requests tend to be for harder stuff.

I'm not sure how to benefit from this insight, but I'm going to ponder it.