Blue Sky On Mars

Thoughts on Building Software Products
August 18, 2005

A funny thing happened on the way to release…

by Kevin Dangoor

Last week, Ian Landsman wrote about leaving features out in order to get a product out the door, and I promised to write about delaying a product to make it stronger.

One thing about writing a blog is that, as long as you’re honest, you give yourself an automatic history. Something you can look back and reflect on. For example, on May 10th, I wrote that the Zesty News alpha was feature complete, and that there was only bug fixing and interface cleanup to go. And that was true, at that instant. Rich Sheridan is fond of saying “last minute change is a competitive advantage”. If change is necessary to succeed, changing at the last minute is better than not changing at all.

So, a funny thing happened on the way to the alpha release: I decided to make some changes. Two things kicked off what I’m calling my Summer of Refactoring (aka, Thank God for Automated Tests): a desire for better perceived performance and an acknowledgement that plugins are more important to Zesty News than I had first thought.

I’ve been actively using Zesty News for months now. One thing that had bothered me a little bit, but not enough to take immediate action, was that the UI would sometimes pause for a second or two if feeds were being updated while I was reading. On one hand, it was a minor niggle… what’s a second or two, right? But, on the other hand, it breaks the flow of reading and lessens the total experience.

So, I started looking at my options. I ended up concluding that the sqlite database was just not the right database for Zesty News. It’s a great database for a large number of desktop applications. But, Zesty News is almost like a multiuser application in that the feed updating happens right alongside the user’s reading. sqlite is very fast, but Zesty News has a fair bit of bookkeeping to do to work its magic.

At about the same time I came to that conclusion, I also looked at the field of competitors at the time and knew that plugins are going to be an important part of what Zesty News can offer. I’ve been planning all along that the difference between Zesty News Lite, the free version, and the full Zesty News would be completely implemented in plugins. That will greatly ease my maintenance burden, and it will also ensure that others who want to make plugins have a powerful facility to do so.

With a decision to change the database engine already there, I decided that I would open my mind to other changes that would make things easier for people who want to write plugins.

The first couple of weeks of June were lost to a false start on the database change. I liked many aspects of the change, but there was a different performance problem introduced there. One that was just not acceptable to me. Once I discovered that the Firebird database was actually a viable option, I was all set and could proceed forward.

The next step was to put in the best pieces for plugin writers, so that I could make writing plugins easier. I changed around a whole bunch of infrastructure parts that I had chosen. The shape of the Zesty News code changed around the edges, and everything was streamlined a bit and became more pleasant to work with.

The Zesty News of today no longer has the concurrency problem that it had on May 10th. The main interface looks much better (thanks, Kirsten!), there is a smattering of new features, and the infrastructure is fun to work with. I’m exceedingly happy to have changed course, because I know that the Zesty News of today is going to be much better for what comes next: real users.

Sounds like a good time to start the alpha for real! And that’s what I’m doing.

5 comments
August 18, 2005

Joel doesn’t “get” XP

by Kevin Dangoor

Understand up front that I’m not saying that Joel is wrong about how he develops software. Joel’s comment in The Project Aardvark Spec about extreme programming doesn’t seem to fully appreciate what goes on (or is supposed to go on) in an XP project.

As I worked through the screens that would be needed to allow either party to initiate the process, I realized that Aardvark would be just as useful, and radically simpler, if the helper was required to start the whole process. Making this change in the spec took an hour or two. If we had made this change in code, it would have added weeks to the schedule.

Joel is confusing XP with the ad hoc “just dive in and code ’til it’s done” methodology. He uses the statement above to support Big Design Up Front vs. XP. But, this implies that an XP project would have gone and implemented the whole thing before someone finally slapped themselves on the forehead and said “D’oh! We should’ve just made the helper start the process!” Let’s take a look at how a real XP project might have addressed this:

  1. There is up front work in the form of story cards. It’s entirely possible that in creating and estimating the story cards at the beginning of the process, “helper initiates process” and “victim initiates process” may have been two separate cards. They may have had to be two separate cards, since a given story can’t be longer than an iteration. Given that, the “victim initiates process” story just might never have been scheduled in the first place.
  2. Particularly if there are UI questions, it is not unreasonable in an XP project to put some effort into UI mockups in the first iteration. At this point “victim initiates” may suddenly start looking very clumsy, causing the story to get dropped.
  3. Let’s say that the problem was not in the UI, but how the code needs to work in order for the victim to initiate. When going through the story cards at the initial estimation session, one of the programmers might have thought of a potentially tricky aspect of “victim initiates”. If that’s the case, they might get a new card written for a “spike”, which is a brief experiment to test out the potentailly problematic area.
  4. Assuming that “victim initiates” made it all the way through the steps above. It gets scheduled and worked on. Odds are good that the programmers would notice that something’s up mid-iteration. It is legal to change things mid-iteration, if new information arises. Worst case scenario: they go the whole iteration (2 weeks, usually) working on that story before it gets ditched at the next planning session.

    5. XP is not dive in and code. The whole point of XP is written on the cover of Kent Beck’s book: “Embrace Change”. At the beginning of Joel’s Project Aardvark spec, he mentions that the spec is not cast in stone. The problem with many Big Design Up Front (BDUF) projects is not that a spec is written… the problem with many projects is that the spec is cast in stone and requires an elaborate “Change Request” procedure to alter the spec.

    Before you call me an XP lunatic: I don’t think XP is the be-all and end-all development methodology. Different projects need different processes. To me, the biggest thing to come out of XP is not the XP process, but Test Driven Development, which I consider a good thing regardless of how the project itself is planned and run.

4 comments