I understand the 10 frustrations listed in this article. I’ve programmed for a long time…and I’ve experienced all of them.
But in the world of business software, this article completely misses the biggest frustration: changing specifications. I’m not talking about feature creep, that insidious disease that has killed many software projects by bloating them with features that aren’t needed and won’t be used. I’m talking about a very specific agreed upon description of a program feature that changes after the software is written.
A professor in
college suggested to our class that the right way to do a specification for a software project was to write the manual for the software in advance. Great idea, I thought. So I tried it early after I started Data Guidance Group. I wrote the manual; the client approved it. We wrote the software, and we delivered it.
The software was a piece of billing software that calculated some key Section 8 housing limits. The client loaded the information into the software and my phone rang. “These calculations are wrong,” he said.
“Ok,” I said. “I’ll come by tomorrow morning and we’ll look at the numbers.” The next morning, I showed up bright and early to check the numbers. On one particular calculation, the computer came up with $320.00. I pulled out the software manual and got a piece of paper. After a few minutes of figuring, I came up with the answer. “Are these the right numbers from the software?” I asked. They were.
“Well,” I said, “I came up with $320.00.”
“The formula is wrong,” he said.
“But I followed the formula in the manual we wrote and you checked,” I said.
“Formula is wrong,” he said.
That’s what I mean by changing specifications: it’s not a matter of miscommunication. It’s a matter of changes to agreed specification. It’s an old saw in the software development industry: the user never knows what they want until you give them what they asked for.
We finally figured out how to solve the problem. But that’s another post.