Home » Archive

Articles in the process Category

process »

[13 Aug 2008 | Comments Off on Technical Tasks vs. Stories | ]
Technical Tasks vs. Stories

A lot of teams have trouble deciding whether a task should be declared as a technical task or a story. The simple answer here is that if a customer can ask for it, it should be a story.
For example, the following should be stories:
– Creating an installer – “As a customer, I want an easier way to install the application”
– Supporting an incremental DB tool (such as Liquibase) – “As a customer, I want an easier way to the application database when upgrading software releases”
– Supporting a new deployment environment …

process »

[28 Sep 2007 | Comments Off on You know you’re not agile when… | ]

… you have a job description like this:
DESCRIPTION:Career Growth! Terrific opportunity in a growing software company for a Java Developer. Must have experience with the design, documentation and implementation of Java 142. Must be strong with implementation of Java. Must also have experience with Spring or Struts. Any experience with Eclipse, Hibernate or Oracle is a great plus. Job duties will include taking a 220 page document of specs and implementing them accurately and efficiently. Will travel to various local client sites. Interviews are taking place right away.
Man am …

process »

[9 Aug 2007 | One Comment | ]

If you’ve ever been to a vineyard, you’ve probably seen that they plant rose bushes at the end of each row of grape vines. These rose bushes indicate if there is going to be a problem with the grape vines because the roses are generally weaker than the grape vines, yet have almost the same genetic make-up. The roses will die first if there is a pH-imbalance, insufficient water, too much water, too much sun, or other issues with the environment. The viticulturalists can then react before the …

process »

[15 Apr 2007 | One Comment | ]

I’ve heard that about 45% of features and functions in software go unused. As a developer, I have control over removing unused functions and I do so quite diligently through refactoring and the courage that I have to modify my code through the practice of test-driven development.
But I believe that unused features can have a significantly worse effect on the quality of a software system than unused functions. The more code you have in your system, the more complicated your architecture becomes and the harder it is to maintain. But …

design, process »

[23 Jan 2007 | One Comment | ]

I didn’t find one that I liked exactly, so I just thought I’d post an image that represents the flow of the TDD process.
[click on image to enlarge]

process »

[15 Jan 2007 | One Comment | ]

Martin Fowlers discusses the term Technical Debt as what is introduced into your code when you take a quick, yet messy approach to developing something. Another way to think about technical debt is as the inverse of quality; in other words:
technical debt = 1 / quality
A word that I’ve often heard used to describe the action of incurring technical debt is sprinting (not to be confused with a sprint in Scrum). This is an analogy to sprint running (in the track-and-field sense) where developers are rushing to write code, often …

process »

[15 Dec 2006 | Comments Off on Pair Programming Etiquette | ]
Pair Programming Etiquette

I’ve often felt that there should be an etiquette guide for pair programming. Here is a first stab. I’ll update this list as I think of more.
Navigator:

Wait until the test is passing to nitpick on coding standards.
Ask nicely for the keyboard to “show” what you mean.
After “showing” what you mean, offer the keyboard back.
If they don’t take your advice, let them finish doing the task their way and then show them after they’re done.
It is good to inform the driver of keyboard shortcuts and refactorings but don’t interrupt the programming …

process, tools »

[11 Aug 2006 | One Comment | ]

Marcus Ahnve recently wrote about why he doesn’t like FIT.
Here are my thoughts:
When I first started doing customer specified integration (“story”) testing on enterprise Java projects, JUnit was the tool choice. It was just as simple to program and maintain integration tests as it was to write and maintain unit tests. Because the developers were responsible for translating the test plans into their executable form, it was an obvious and simple choice. It enabled us to run a debugger when we needed to, the tests ran fast, and we didn’t …

process »

[10 Aug 2006 | Comments Off on A brief post-mortem of my first XP project | ]

My first (real) XP project was on a team of 9 developers back in 2001. There was a technical architect/lead, 4 senior developers (one of which was me), and 4 junior developers. We also had two “customers”, one of whom was also the project manager. The project was a commission calculation system for a large insurance company. The senior developers and the technical architect on the project were all consultants and the junior developers and customers were all full-time employees of the company.
The idea was that we were coaching the …

process »

[3 Feb 2006 | Comments Off on Depth of scope | ]

When having a discussion about the negotiable-scope nature of some Agile processes (XP for example) an inevitable discussion about the “variables” of a software project arises. I usually abbreviate the “variables” as Q R S and T: quality, resources (a.k.a. cost), scope, and time. Many projects try to fix all of these variables and are subsequently shocked that they failed to meet their estimates on one of them. Something has to give, many Agile proponents argue that it should be scope.
Many business stakeholders are uncomfortable with negotiable …