Reflections on the possibilities and realities of the Software game, and the need to say No.
No is a useful word. In child rearing, it sets boundaries for the child. Boundaries that are desparately needed by a toddler who is trying to assert his independence in a huge scary world, and who needs you to set some protective barriers.
No is also valuable to the teenager, who needs to be protected from his or her own urges and needs, and who needs to know that you value her so highly that you will fight her to keep her safe.
And No is an essential component of a software product strategy. I read Susan Mernit’s Post on no the other day, and was struck by her insightful comments.
As we all know, you can do anything with software, given enough time and money. But that’s the rub, isn’t it – we need to function in a time and resources bounded world. So we need to say No to everything in the universe of possibility in order to accomplish our small thing.
I typically rage against the No. In my passion to deliver great software to my customers, I want to give them features that they need. And I’m all too aware of the long slow delivery cycles, and the possibility of not getting another chance. I typically go the “make the pie bigger” route – looking for ways to improve productivity and/or cycle time to deliver more. Or to be smarter about prototyping and cycles so that the application delivered is its lapidary best. (characterized by an exactitude and extreme refinement that suggests gem cutting: a lapidary style; lapidary verse).
But, even I give way to the need to exclude in order to include, the need to say no. Susan cites some common reasons for this in product development:
These are all good reasons. In the face of cool features and impassioned supporters, it is hard to sort out. But sort we must, because we have to say no a hundred times for every yes.