Xp Code

The remark about gold plating on YouDontNeedItAnymore is interesting. Presumably, XP code doesn't have any such useless beauty; so, does XP code actually look different to conventional code? Can you see the XPness just by reading the source?

XpCode? looks like it was written by someone who knew what he was doing and didn't waste any time getting it done. The surprising fact is that it is written by a team, the team didn't start knowing what they were doing and they probably "wasted" some time getting done.

Two examples: one micro, one macro. Micro first.

Just recently we were doing a proof of concept to do with implementing sprites in Java 2 ME (answer: it is a silly concept, unsurprisingly enough). A pair had put together the collision rectangle code, and another pair refactored it before doing something else. To be honest, the first pair had fallen down on the refactoring a little, though they had been writing tests, so the next pair could happily tidy up. The first cut was full of x1s and y2s and two line long boolean expressions, you know the sort of thing. The refactored code made liberal use of final local data to cache reused subexpressions. The difference between the two was astonishing. The first cut was exciting and mysterious, and a little frightening. The second was frankly rather dull, at first sight. The first cut looked like the product of a fiendish genius going at full steam ahead (even though what it did was quite simple), the refactored code looked, well, like "anyone could have done it", since it was ScreechinglyObviousCode. Except that it couldn't have been done by anybody. What seemed at first to be boring, at the second glance seemed restful. What seemed at first verbose, at the second glance seemed transparent. What seemed almost unskilled in its straight ahead plodding to the answer soon began to look like a statement of breathtaking professional self-belief. That was a good day.

On the macro side, we had the task of producing a program (in Java/JNI/C++) that would show off the capabilties of a new industrial hand-held. The program also had to be an exemplar of good Java programming for the population of C++ programmers who'd used the previous generation of hardware and would want to learn java to write for the new one. So we set to and wrote the first demo screen, then wrote the second one and refactored, and then wrote the third one and refactored, and so on. Two interesting things happened. Firstly, we developed a nice little framework (yes, "framework", let's not be squeamish) full of classes called things like FixedSizeModalPopup?, as used by DemoFrame? to implement its Help and About dialogs. This made each successive demo quicker and easier to implement that the one before. Secondly, by the time the client had run out of demos they hadn't thought of at first to ask for, there was quite a respectable hierarchy below DemoFrame?. A hierarchy that had arrived exactly where you would have expected it to be had we had the total, final requirement to start with, and had we done a full blown analysis on it as to the different kinds of demo to be written: asynchronous operations or synchronous, long duration or short, requiring the user simply to click a button to set it off, or requiring fuller interaction. Except that I'll bet money that we wouldn't, in fact, have got that partition right, if we'd gone by the analysis route. Wheras, by listening to the code as we added new demos, a very effective (I'd wager, near optimal) partition came to us for free.

That's what XpCode is like.