I am a software developer with 14 years of professional experience in IT, as an architect, programmer, designer, analyst, project leader, team leader, project manager, and even as a development department manager. I care about Software Craftsmanship and Domain Design. Practicing Test-driven development and Pair programming since 2005.
User Stories considered harmful
We used to have business and system analysts and the craft of gathering requirements. We used to have Quality Assurance Engineers and the art of writing test scenarios and extensions. We used to have tons of trees die for our software processes. And while we moved away from killing trees or wasting time on extensive documentation, we moved too far in the opposing direction. These days I keep meeting Product Owners, who can communicate beautifully with customers, but cannot write down what needs to be done in any sensible way. User stories brainwashed our analytical skills. Same problem exist on the developer’s side. Test Driven Development was focused on communication, but for most devs couldn’t figure it out above basic “write tests before code”. It went so bad, that a new name had to be invented for the same practice done correctly: Behaviour Driven Development. Spending my time on both sides, I’d like to show how we I’ve tried to reintroduce the lost art of writing analysis, in a simple yet useful form, so that we can finally communicate and estimate in a precise manner, and stop “farting in a general direction”. This is Software ENGINEERING for god’s sake! Not that I have a lot of success with that, mind you, but at least I’m trying.Slides