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 ...
Get Making Things Happen now with the O’Reilly learning platform.
O’Reilly members experience live online training, plus books, videos, and digital content from nearly 200 publishers.