Skip to main content

Lean Team + Agressive Schedule = Possible Software Ghetto

Posted by edburns on July 9, 2010 at 9:15 AM PDT

The original Pragmatic Programmers, Andy Hunt and Dave Thomas, talk about the tragedy of the software ghetto in this 2003 interview with Bill Venners. We all know the story of how unfixed broken windows can cause a nice neighborhood to start looking like a ghetto, and how this analogy is applied to an enterprise software project. While working through my email today, I came across a management pitfall: Agressive Scheduling + Lean Team = Software Ghetto. Here's the story.

My current lean team is dealing with a steady influx of bugs/issues found in the source code, while at the same time having to conform to an agressive schedule with very clearly defined priorities. If an issue doesn't fit within the priorities for the schedule, it's put on the bottom of the list.

As one of the responsible engineers for Oracle's JSF implementation, Mojarra, I have committed to review and evaluate new issues on the issue tracker as quickly as possible after they come in. I try to do this as part of my email reading process. Today's issue: 1729. While using our existing automated test harness to try to reproduce the bug, I made an XML authoring error, but it took a while to diagnose because I found another bug that was masking the exception. The right thing to do would be to file an issue on this other bug and move on. However, our current agressive schedule and lean team would dictate that this issue would certainly not be addressed this calendar year, and would likely never make the cut because such little issues are never high priority enough to be judged important when crafting an agressive schedule. So, I decided to fix the exception masking issue now. Did I make the right choice?

According to the management school of laser focus, schedule at all costs, probably not. According to the school of quality and ghetto avoidance, probably yes. I assert that projects that have agressive schedules with clearly defined priorities combined with a lean team to meet that schedule will tend to generate software ghettos. What do you think? Did I make the right choice?

Technorati Tags:

Comments

The middle path, the middle path...

It depends on how you manage priorities.

It is like 'starvation' in concurrent programming. Having threads greater priority always have precedence over lower priority ones, leads to never executing the latter and generating an undesirable/unexpected effect.

If your priorities' policy say 'priority 1 is always taken before priority 2', you will get into trouble, whatever they are. Even if priority 1 is the so called quality. If you always put quality over, say, (business) value, you'll just deliver useless zero-defect software.

The same way, if you always put your schedule over quality (only worry about the schedule, and never about quality), you'll inevitably get crappy software.