Extreme Programming Experiences: Part 2 of 5: “Lazy YAGNI”

30 05 2009

“Lazy YAGNI”

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.
Read the rest of this entry »



Extreme Programming Experiences: Part 1 of 5: Do The Simplest Thing That Could Possibly Work

30 05 2009

Do The Simplest Thing That Could Possibly Work

This does not mean “do the least work possible”. Doing the least possible is not XP, it is hackery, which is the methodology that leads to a Big Ball of Mud.
Read the rest of this entry »



Extreme Programming Experiences: Introduction

30 05 2009

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.
Read the rest of this entry »



Software Project Estimation: Inaccurate and Unavoidable

6 08 2008

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.

Read the rest of this entry »



Thoughts about using Git for closed source projects

14 04 2008

Git is getting a lot of press in the open source world lately, but hasn’t got much traction in the closed source corporate development world. There’s a reason for this, and it’s more than conservatism on the part of the corporate developers. Git (or any DVCS, really) embodies a development culture that isn’t very enterprise-y.
Read the rest of this entry »