Symphonious

Recently there was a security flaw introduced by a security patch for IE, this obviously is a really bad thing and something the IE team1 have received a lot of criticism about for some time. Obviously, the IE team took it seriously and tried to find ways to make sure it didn't happen again. One thing that really bothered me though was a statement in the IEBlog:

In parallel with making the right fix, we have been working through how we prevent similar mistakes from happening again. For instance, we have code-reviewed the past ten months of code check-ins from the developer responsible for this issue.

I can't really imagine anything more demoralizing than having the past 10 months of your work reviewed because you made one mistake. It just says to me that the team considers that programmer incompetent all of a sudden2, rather than seeing the bug as the teams mistake and focussing on how to improve the way the team works to make sure it doesn't happen again.

Maybe I'm just spoilt because I get to work with a really fantastic team that treats issues as a team problem and works together to fix it instead of finding a scapegoat. I just don't see how you expect people to do great work when you demoralize them like that - developers do better work when they enjoy their work.

Now, I'm sure the team didn't mean for it to come out like this, and maybe inside the team the perception is completely different - this is just a one-line example of the measures they've taken, possibly just made up or exaggerated to try to make people feel safer. I certainly hope so, because otherwise there's someone on that team that probably feels like crap right now and isn't concentrating on their work like they should be.

1 - and Microsoft in general↩

2 - despite the fact that they were considered competent enough to work on a critical security fix↩

I'm glad Andy side-tracked into talking about us temporarily dropping pair programming - I've been considering the same kind of things but want to see what the rest of the team thinks about it before I say too much.

Slightly off topic, the development speed we’re achieving now is making me wonder if the tradeoffs when developing purely under Pair Programming are actually worth it.

There's a lot more that has changed recently that has led to our sudden improvement in velocity - not just pair programming. For a start, we're more focussed on the task because we're not sharing the support load around the entire team. Plus, the business has really started to understand how difficult it will be for us to get things done so they've gotten off our backs about everything else and really focussed on hitting this big scary deadline. We were splitting our development efforts between two or three products and the context switching was killing us.

Another thing to remember is that right now the two most experienced people with the codebase are doing the development and the other two are handling the support and other miscellaneous support tasks.

Even the features we're working on have probably contributed. Andy has been starting the work on the UI - a well known area that requires attention to detail but doesn't tend to ambush you with unexpected challenges all the time. Meanwhile, I'm finishing off a section that we've spent the past couple of months laying the ground work for. I suspect that much of the high velocity I'm seeing at the moment can be attributed to the hard work we put in earlier to keep the code quality up and stay code debt free. All of a sudden instead of working in a big scary area with no tests and any change might be your last - I'm working in a nice safe harbor where there's a ton of tests to tell me if things go wrong at both the acceptance and atomic levels.

So there's a bunch of things that have fallen into place nicely, but that's not to say that pair programming wasn't impacting our velocity. The problem we are going to run into soon, is that we're going to have Doug and Jack back on the core development as we bring in new support resources and get them trained up. Then all of a sudden half the team is fairly new to the code base and that lack of knowledge sharing is really going to start hurting.

Even more short term, we have the challenge of bringing the new engineers up to speed on the products, the code bases, company policies and all the rest of the training and mentoring that new recruits need. That work starts on Monday and the faster we can get them up and running to handle support, the better our chances of making that big scary deadline.

As a team, we need to develop our training and mentoring skills so that we can knowledge share - either through pair programming or some other means, far more effectively. Before we were doing pair programming, I was spending a huge amount of my time helping other people learn about our code base - that cost can't be ignored either.

The advantage we have is that by the end of the quarter, all going well, we'll have gotten rid of this big scary research feature and moved onto work that we better understand, can better estimate and doesn't require a PhD1 to understand the details of. We should also have support under control and we can start focussing our attention back on adopting XP and improving our practices. The big problem we've had for the past couple of months is trying to do too many hard things at once and burning out - support, the big scary feature and adopting XP. That's why XP has sustainable pace as a key ideal - we're currently focussing on getting that practice right in difficult times.

1 - or reading PhD dissertations↩

As part of the process to open source Java, Sun have switched from using codenames for Java releases to just using the actual name. Thank goodness for that. I'm not sure I know of anything more frustrating than attempting to have a conversation with someone using code names instead of actual versions. Was Dolphin before or after Mustang? Which Tiger do you mean, Mac OS Tiger, Java Tiger or Tiger Direct? How hard is it to just pick a version number and use it? Does marketing really need to mess around with that number at all, and even if they do, do they really have to wait until the very end of development to pick a number?

Ephox has for some reason decided that code names are absolutely essential to have and that we couldn't possibly refer to projects by the version numbers that engineering and product management have been referring to them as for the past year or more. Nope, got to pick a new name and then remind everyone what version number that maps to every time you use it.

I don't complain much about Ephox and it's probably a good sign that all I'm complaining about is the use of code names - apart from causing confusion at the start of every meeting it's really not that big a deal.

On the plus side, sanity reigns in the engineering department - we just focus on the story cards and get stuff done, the rest of the company can worry about what cards make up the Harrison release and which are part of Moreton. Bonus points to any Ephox employee that knows what the Buzz Lightyear release was. Of course, anytime I have to pick a project code name you can bet it'll be really memorable…

Sam Ruby - Time for a new HTML Validator?:

If people feel that HTML 5 deserves a better validator, I’m willing to invest some time into coding. Are there others interesting in contributing to the coding, the writing up of test cases, or the authoring of documentation?

 Is there a reason we need a new validator instead of just improving the existing one? The source code is available in CVS and there's some brief instructions on how to contribute. Admittedly it doesn't look like the easiest project on earth to jump into but it looks possible to do so. Is noone around to accept and apply patches?

There does seem to be quite a long bug list that people could sink their teeth into if they wanted a better validator.

So, is there a reason we need to start again from scratch that I'm missing?

Okay, so I've converted my WordPress install to use Atom 1.0 and (I think) made using it as the default1, but I've got one warning left that I just don't get:

line 8, column 86: Same-document reference: http://www.symphonious.net/2006/08/13/those-who-still-need-classic/ [help]

... /08/13/those-who-still-need-classic/" />

Now I get that the two URLs are pointing to the same place, but why exactly is this a problem and what URL am I supposed to put in there? Should I just make up a new base URL so that it's clearly not the same document? The URL is absolute so the xml:base shouldn't affect it.

It would be really nice if the help pages for the validator actually explained why it was a problem rather than just what the problem is, at least for warnings.

1 - existing subscribers aren't being redirected - but you can resubscribe to the Atom feed if for some reason you feel it's superior.↩