Lack of Onsite Customer
This is a serious problem. Your project exists to serve somebody, and your success is directly proportional to understanding what they want, so that you can build it. You need as much communication bandwidth between the programmers and those people as possible.
Continue reading “Extreme Programming Experiences: Part 3 of 5: Lack of Onsite Customer”
You Aren’t Gonna Need It can lead to some silly situations if you interpret it too pessimistically. The pessimistic (and wrong) interpretation is that you should pretend that the user story you’re implementing is the only one you know about. This equates to doing zero up-front design, because you’re only concerned with whether the design satisfies the user story you’re currently implementing. The price of making this mistake is design churn: each new requirement may incur a large rewrite of existing code. This is obviously not a recipe for productivity.
Continue reading “Extreme Programming Experiences: Part 2 of 5: “Lazy YAGNI””
Extreme Programming Experiences: Introduction
Over the last six months I’ve had the privilege of working in a software development team that was practicing the closest thing to a full implmentation of XP that I’ve ever seen.
Continue reading “Extreme Programming Experiences: Introduction”
This is a follow up to On Our Project, We’re Always 90% Done.
The coder is the one on the hook for long nights, weekends, and stress-related health problems if the estimates suck. It’s in your interest to exert as much control over estimation and scheduling as you can. If you’re not making the estimate, someone is making it for you.
Continue reading “Software Project Estimation: Inaccurate and Unavoidable”