Posted by Robert Merrill on November 28, 2008 under uFunctional Values | 
Be the First to Comment
I sort things out. I make do with what you have. I get something done.
I sort things out. From our first no-cost meeting, I’ll be sorting things out, in a curious, non-judgmental way. How does your business work? What software are you running, and where did it come from? Read more of this article »
Posted by Robert Merrill on November 22, 2008 under Uncategorized | Be the First to Comment
(I wrote this back in Summer 2007, but since I went all WordPress all the time, I had to recreate it as a blog post and the date changed).
Nothing I read in Report 07-5 surprised me at all. The problems are well known.
None of these things surprise or frustrate me any more. Nor do I expect they surprise most software-development professionals.
What frustrates me are the proposed remedies.
Like the problems,they don’t surprise me. To quote the American novelist Willa Cather, “There are only two or three human stories, but they go on repeating themselves as fiercely as if they had never happened before.” Calls for better planning and more oversight don’t surprise me. They just frustrate me.
The first one is less frustrating. I’m not against planning. I do it all the time. It helps me focus on the objective, gather my thoughts, and take the first few steps with confidence. But plans do not determine the future. The future just isn’t very cooperative.
The second one frustrates me more. Apparently, Kate Nolan had plenty of oversight. On the same day that the Wisconsin State Journal reported on the audit findings, it also reported that Ms. Nolan, a project manager on one of the few large projects praised by the audit, was taking early retirement because she was “very, very tired” of fighting “patently ridiculous ideas” from superiors. By and large, software projects don’t need more oversight. They need better oversight. Overseers need to find the trustworthy and the competent like Ms. Nolan, listen to them, and empower them, not burn them out and run them off. And they need to understand and accept that
You can succeed despite these things, but only if your recipe and criteria for success don’t depend on their not being true.
Software project success, failure, estimation, and methodology are fascinating topics, and it’s surprising how little people who ought to know about them, don’t. Here are my top picks:
Lean Software Development: An Agile Toolkit by Mary Poppendieck. Lean manufacturing and product development (think Toyota) applied to software, by someone who’s actually done both software and product development. It’s even a short book!
Software Estimation: Demystifying the Black Art by Steve McConnell. Chapters 8 and 9 of Steve’s Rapid Development are also an excellent introduction to the estimation problem.
Posted by Robert Merrill on under Software-Intensive Businesses | Be the First to Comment
I coined the phrase “Software-Intensive Business” after three decades as employee, contractor, and consultant. I found myself saying, “These folks have backed into the software business, and they don’t know it.”
I think a list of attributes is easier to understand than a formal definition. Read more of this article »