Greg picks up on my previous post about XP principles and how it helps avoid rewrites. I thought I should explain in more detail why rewrites are a bad thing and my thoughts about when and how you should do them anyway.

Programmers for some reason seem to think any code they didn’t write, and often any code they wrote some time ago, is poor quality, misguided and generally crap. Often this is quite true, but the degree to which the code is bad is usually significantly less than the initial impression it gives. That is, when you first look at a piece of code and start working your way through it, you feel as if the programmer was completely brain-dead and it’s amazing the software worked at all.  Except in very rare occasions the code does work with just minor bugs or even no bugs (at least that have been discovered) so the inclination to think that it can’t possibly work is just a form of panic reaction from your brain while it struggles to comprehend the new code. It’s very easy to condemn a piece of code in those first few moments when you don’t actually understand it and are just seeing a mess of symbols and a bunch of bad coding practices, but doing so condemns your rewrite.

Sometimes you write code that is really important, sometimes you write code that is not and other times you write code that is somewhere in between. Should you apply the same quality standards to all of that code?

It really comes down to a question of value – code that you write once, run and then throw away obviously doesn’t need to be pretty and certainly doesn’t need any documentation. What about code that you keep around, make the odd change to and run regularly but is of low importance? What if it just doesn’t matter if the code breaks? Where is the value in making the code robust and easy to maintain?

Well maybe not so much “killer”… Anyway, Scoble mentions the return of SmartTags due to bloggers choosing to add them to their site. I pretty much never actually go to bloggers sites unless I want to write a blog post about them in which case I open a new tab in NetNewsWire to remind me for later, so I don’t notice them much. When I do see them though they really annoy me – they look far too much like hyperlinks and distract far too much from the content.

A while back Ben Hyde wrote his thoughts on the key XP principles in What every you doing, it’s wrong! I’m not sure I fully comprehend exactly what Ben is trying to say but a lot of it seems opposed to the way I see XP in theory and to the experience I’ve had in implementing XP.

I’ll start with Ben’s rewording of the summary of Extreme Programming (see also James Mead’s original):

I realized today that I hadn’t made explicit the difference in my mind between features and stories and it’s an important difference. Essentially, a feature is a group of stories that are related and deliver a package of functionality that end users would generally expect to get all at once. For instance, inline table resizing is a feature (note: this is the ability to drag to resize tables, rows and columns – try it in Word). In the first pass, you’d probably have a single story for inline resizing of tables, but it would be too big to estimate. So you break it down into three stories, resize columns, resize rows and resize the table itself.

XP has the concept of keeping the code base in a state that you can ship at any time. That seems like a good idea as it allows you to quickly ship a new version to preempt a competitor’s release or when marketing suddenly wants to attend a trade show and have something new to talk about. In other words, allow the business requirements to drive the release schedule instead of it being purely driven by the engineering team’s schedule.

Pages created on .Mac however are the source of a never-ending headache. Indeed, whenever one requests a page on an account that no longer exists (such as the former .Mac FJZone account), the Apple servers dutifully serve a tri-lingual error page… all the while returning a “200 Found” code. In other words, as far as robots are concerned, .Mac pages live forever.

— Francois Joseph de Kermadec

This has to be my single most hated server misconfiguration. The problem is much more serious than unwanted pages turning up in Google searches – any program that tries to download resources from the server without explicit user interaction gets bitten because the server delivers a 404 page instead of the expected file without warning. The client side program can then only assume the file is corrupt on the server and give up.

I stumbled across the article This Is What You See, This Is What You Get the other day and it points out a number of common pitfalls for HTML editors that have relatively simple solutions, as well as repeating a number of common misconceptions about WYSIWYG editors – primarily that Word or Outlook should be considered good examples of how to do it.

Perhaps an obvious point. At least, the web is not WYSIWIG. What you see on your browser is almost certainly not what I see on mine due to many factors. Differing font sets, typographic capabilities of the OS, use of subpixel rendering, browser rendering engine/version, user display preferences such as screen resolution/depth, display gamma, as so on.

We’ve adopted a point based estimating system as part of rolling out XP, with 1 point being simple, 2 moderate, 3 difficult and 5 meaning too hard to estimate (either too big or too technically difficult). One large feature for the next release has been plagued with 5 ratings, both because the feature is big and hard to break down and because it’s technically very difficult so we’re not always sure parts are possible, let alone how long they’ll take.

A while back I commented that I should look into the Delta Web project – I’m doing some work in this area now but nothing more seems to have happened. The mock schema for tracking deltas only works on an element level so is useless for describing changes to XHTML documents which is a shame.

Anyone know of any further progress or other related projects in this area?

Oops, forgot the direct link to the Delta Web proposal by Andy Roberts.

We’ve been switching pairs a lot in an effort to try to share knowledge between team members before and it’s been working really well. The downside to it though is that since the team owns the tasks and people swap between tasks so much (which is what gives the shared knowledge), there’s always the danger that you will get off track and start wasting time writing code that isn’t actually needed for the user story.

In order to write atomic tests for classes I’ve gotten into the habit of injecting dependencies instead of creating them inside the class. This makes it simple to mock the dependencies but means that those dependencies are now externally visible instead of being neatly encapsulated and it means that somewhere in your code, there has to be a place that actually creates all these instances and passes them in.

I have no idea how to test that bit of code.