As I start to post more here, some if it may seem like I’m full of rhetorical antipatterns about my beliefs in software development and the analysis process. I want to make my context clear, in advance.
The ideas here are predominantly about building business software in a large organization. That’s the hear of my experience. A lot of the observations will be anecdotal, because it’s very, very, very hard to accurately measure productivity. Not only is it almost impossible to measure in the absolute, even relative measures can be suspect (Robert Austin covers this much better than I could in Measuring and Managing Performance in Organizations.
So I’ll be the first to admit, there’s not a lot of science here. Some would argue it’s sloppiness, some would argue that it’s just inherent to the task. What is there is just my personal experiences, observations, and thoughts after years of building software in this context. When I say something inflammatory like “traditional requirements specifications suck,” I mean in the context of a rapidly changing business environment at a large organization consisting mostly of non-software professionals. I am not claiming that any such assertions then apply equally to other fields, like shrink-wrapped software, or military radar systems. They may apply, but I have no idea.
