Making Things Happen

Chapter 7. Writing good specifications

Ionce had an argument with a programmer who believed that we didn’t need to write specs. I walked into his office with this big template I’d been told to use by our boss, and he just laughed at it (and unfortunately, at me as well). His opinion was that if what I wanted to do was so complicated that I needed 50 pages to explain it to the programmers, it wasn’t worth building anyway. He saw the need for all of this process and paperwork as a signal that communication and coordination on the team were failing, and that we weren’t trusted to decide things for ourselves. We shouldn’t need so much overhead and bureaucracy, he said, implying that elaborate planning was never necessary.

Having had this argument before, I smiled. I asked him if he’d make the same claim about the engineering plans for the hi-rise apartment building he lived in or the three-story highway overpass he drove on to get to work. But apparently he had heard this question before, and he smiled right back. He said that while he was glad those things were planned in great detail, he didn’t think working with software was quite the same as working with the laws of physics and construction materials (and he argued in favor of methods with minimal spec writing, such as extreme programming). We quickly agreed on two points. First, that compared to traditional engineering, software is more flexible, easier to change, and rarely has people’s lives at stake. But, we ...