delphiXtreme

Figuring out what to do next or even where to start is alway a challenge.

Scrum and XP both have an iteration planning method in which the team gives each unit of work (story) an estimation of effort. We typically call these story points. Story points are essentially an order of complexity against a baseline story.

The typical format is the Product Owner brings stories to the Team for estimation. The Product Owner and Team talk about each story until the Team feels comfortable giving an estimate. In the beginning of the iteration the Team decides how many story points they can get done and the Product Owner lines up the stories in priority order/ The team then pulls into the iteration as many stories as will fit based on the sum of the story points.

Teams will carry on like this using the sum of the story points they complete in each iteration as a measure of their productivity. Increasing this measure of productivity, called Velocity, is supposed to be a sign of a team getting better and delivering more business value each iteration. This is where I think we mess up: equating velocity with business value.

Read more…

XP philosophy

Craig Stuntz recently posed the question of how to build hedges into our products and processes.

If I understand the problem correctly what we want is a way to mitigate the risk of choosing the wrong technology or technique. This is to say if we do choose the wrong technology or technique (for whatever reason) how do we recover and change direction with a minimal amount of fuss and cost.

I think the biggest guiding princple we have for this is Deferred Implmentation. Deferred Implementation demands implementation agnosticism from the client code. We’ll use the User Repository code from the post Keep you code lazy and ignorant as an example. When we wrote the code that needed to look up a user by the user name the client code was ignorant of how the data got there. This was good because it meant we could focus on the business logic of logging in and leave the details of how retrieve user information for later. All we needed to supply was an API for the client code to use. Later, in the next post, we wrote the code to retrieve the user data using an ADO connection to a SQL database. The truth is we could have used any storage medium like an XML file or web service. Either way the client code didn’t change because of the implementation details in the User Repository. Doing this created a hedge in both the barrier sense and the risk mitigation sense.

TDD played a big role in getting to the deferred implementation of the User Repository. We were able to quickly put together a test bed for our ideas and keep it to be sure we didn’t inadvertently break anything. TDD also gave us a formula for the incremental improvement of the code.

TDD by itself didn’t get the job done. We needed to be conscious of separation of concerns, not mixing object creation with business logic and design patterns that help us solve these sorts of problems.

I hope this addressed the question Craig posed. If not, I hope this was at least informative.

XP engineering, philosophy, TDD

It’s a strange thing about a big cup … or any large container for that matter. When you see it empty your immediate response is to fill it up. What can I put in here? There’s still some room in here, how can I use it? When you pull out a cup from your cupboard to take a drink you almost always fill it up.

I’ve found myself lately writing code to solve a problem, looking at the volume of code and being upset over how little of it there is. I think, “Wow, I really wanted to solve a big problem. This code works but I can’t use it because there’s not enough here to match up with the magnitude of the problem!”. It’s like buying expensive software that comes in just a CD case. We shell out big bucks and only get a CD in a jewel case? No, no, no; I want to feel like I got my moneys worth!

How often do we do that? We start with this big cup and try to fill it up. We write more code than necessary,more tables than needed, more infrastructure, more text in the blog post, more, more, more.

The problem isn’t the work or the stuff; it’s the cup. We start with a big cup and try to fill it. Start with a small cup. If it overflows then great! Get a bigger cup.

It’s okay to get stuff done with less. Less code, less effort, fewer hours. Scale it back. Pare it down. Do just the bare essentials and do them exceeding well.

Heres to a new year of smaller cups. Happy new year, all!

What we need, XP philosophy

I just encountered a great article on Ward Cummingham’s wiki. It’s called Programming Is Not Fun. The section that I enjoyed is called “Programming Is Not Fun without Philosophy”. You can find it near the bottom of the page.

I’ve always considered programming/engineering/development to be more art than science. I guess you can chalk it up to my background in the arts. What hit home for me was the assertion that any kind of work done without an underlying philosophy is wicked boring and unfulfilling.

The article notes that other arts have established and accepted schools of thought and philosophy. For instance, painting has Cubism, Impressionism, etc. Do we have schools of thought and philosophy? Do we have Waterfall, Agile, Do-Whatever-It-Takes-To-Ship, TDD, BDD?

What about you? Do you employ any sort of philosophy in your work?

XP agile, engineering, philosophy, waterfall