Symphonious

I've found that doing TDD causes me to use, or perhaps just be more aware of using, some useful debugging and programming techniques. As a side note, it occurs to me that debugging and programming in TDD are essentially the same - in either case you're trying to fix the failing test.

So while TDDing, I find myself asking "What's different about this case?" in a way that I can't ever recall before. It's easier to think like this with TDD because you have a documented, repeatable set of situations to compare between. Sometimes a change you make to fix the latest test will cause others to break and it's then that you need to determine what's different about the new case that needs special handling. Developing without TDD, the question I'd tend to ask is "how should this work?" which is a lot broader and harder to comprehend. I still ask, "how should this work", but it's usually at the start of a story where I need to get my head around what needs to be done and get an overall view of the problem. Finding the answer usually means a bunch of scribbling on notepads or whiteboards going through the possible scenarios and determining what should happen. While programming, the scope is usually reduced enough that you don't need to scribble on whiteboards, but I do find myself going over the various cases to narrow the question down to "what's different about this case?".
In the end, what it means is that TDD is documenting a lot of what I would otherwise do over and over in my head and getting me to the more narrowly focussed question more quickly. It doesn't eliminate that mental process, but it does make it easier and provides a safety net for it if I miss a case.

For the record, finding what's different doesn't always mean a new case altogether, usually it's just a relaxation or restriction on the criteria for an existing code path. It's also potentially far more useful in "soft" areas like text where there isn't a simple rule book or process definition that you can look up to determine what should happen.

More and more I'm seeing ways that TDD makes me go faster even ignoring whether or not it leads to better code quality.

We're looking to move most of our servers into VMWare so that we can easily back up the entire system and restore it in case of hardware failure. We've moved our Jabber server and now buzilla into VMWare and the next most likely candidate is our Subversion server. I'm wondering if it makes sense to store large amounts of data in the VM directly or if we should look at putting the actual data store on the host machine, but all the configuration stuff in the VM.

Should I just not worry about it and put it all in the VM or is there a benefit to avoiding the extra file system layer that the VM disk image adds? I wouldn't expect performance to be a problem, it's reliability I'm concerned with.

Obviously in either case we should be backing up the actual data separately to the disk image in case the disk image has subtle corruption problems.

One of the really core principles of XP is the idea of small, frequent releases. The most obvious benefit of this is that it allows users to see the product and provide feedback about what could be done to improve it. What's not so obvious, but is part of the reasoning behind a number of XP principles, is that the developers benefit from this just as much, if not more than the users. Being couped up in an office somewhere slaving away creating software that no one's using just isn't fun. Getting your software out to users and having the feeling that you've achieved something is a big feel-good moment and it energizes the development team, allowing them to keep going full pace instead of getting tired and stressed.

This feeling of accomplishment doesn't just come from an actual release though - even completing a story makes you feel like you've added value. The last few weeks I've experienced first hand how deflated you get without those little wins. I've been focussed on a big complex area that was too experimental and unknown to break down into small user stories with any real success. It really felt like a death-march - I had no idea how much further I had to go before I finished and as each day passed I felt more and more like I wasn't making any progress at all. Today I suddenly reached the end, the feature was done. Although it's overly dramatic, it reminds me of a single passage about stepping onto the summit of Everest for the first time: after weeks of looking up at the slope ahead of them, for the first time they were looking down. I'm going to have to find a way to avoid such long hauls in the future.

According to XP, what I should have done at the start was a spike to find out what the major obstacles were and find a way to break the story down into something manageable. We did in fact have the story broken down into smaller sections, but it didn't reflect the actual work and I wound up with a pile of six or seven cards that I felt I had to work on simultaneously. Perhaps I could have been more focussed on a single story and just done what was required for it, but looking back at what was required, I don't see that being a much more successful approach. The simplest approach that would have worked for some of the stories would have had to be rewritten to work for the later stories. I also don't know how I could have approached a spike to identify the problems that I ran into, most of them came completely out of the blue.

In the end, I really don't know how I'd do it differently next time, I just know that I want to do it differently because it made me feel bad. It may turn out to be the quickest way to get that particular feature done, but the fact that it made me feel bad feels like a warning sign that it's not a sustainable pace. Perhaps next time we'll be in a better position and be able to share the work around the team more so it doesn't feel like a burden on one person's shoulders. I'd certainly feel better with that if only because it didn't make me feel like a prima donna - I've been so focussed on this one task that I've been delegating pretty much everything else to other people. Fortunately, my colleagues have been fantastic at doing what needed to be done. Thanks guys.

In a comment on Software Teams Must Gel, James C. McPherson asks:

Given your brief description of the Ephox interview process, it would appear that you're not in favour of people who work from home or are even more remote from your office. I've spent a long time working with remote management and geographically distributed teams.

There is, of course, no solitary correct solution, attitude or approach to building and gelling a successful software engineering or development team. I would be interested to find out what the Ephox perspective in on remoteness.

 Ephox has actually had to deal with remoteness for quite some time since we have an office here in Brisbane Australia and one in San Mateo, California. We also have a number of people who regularly work from home. So Ephox has a lot of experience with distributed collaboration, but out development team all work from in the Brisbane office.

There's a number of reasons for this, being able to get to know your work mates and have social contact, simpler administration of tools and infrastructure, but mostly because sitting together makes you more productive. James Shore and chromatic provides a good explanation of this in the Sit Together chapter of their upcoming book, but it applies even outside of XP. In non-agile environments it's often better to have private offices rather than an open space, but being able to quickly get in touch with a work mate and work together on a tough problem is a major productivity advantage.

Beyond productivity, being in the same place means that knowledge sharing happens faster, easier and more effectively. It allows shared ownership of the code and enables us to switch engineers from one product to another as timelines require instead of only knowing about specific areas of a particular product. We get a huge benefit from that knowledge sharing. Being close to the product manager helps to so that we can quickly get clarification of how new features should work etc. It's how our team works and I've never seen a team work as well when they weren't at least in the same building. Even open source projects have get togethers, hackathons and contributors from the same company talking in hallways - and it's those events that often move things forward faster than anything else.

That said, there's no reason in the future that Ephox won't have development offices outside of Brisbane, in fact it's very likely that we will, but we won't be working on the same things in each office. Brisbane might develop EditLive! for Java and the mythical new London office develops EditLive! for XML. In fact, the most likely thing a new development office would be doing is probably professional services work, integrations and other technical tasks around the core products.

We do from time to time have engineers heading off to the US, Sydney or other places to work more closely with a client and when that happens often they do development work on our core products from outside of the office, but it's the exception rather than the norm and nowhere near as productive as being here in the office.

Fortunately, since we have a team that gets on really well, it's actually far nicer to come into the office to work than to work from home in solitary confinement.

One of my keyword watch-lists pointed me to Matthias Ernst's entry, A long term suspicion:

An observation: almost all WYSIWIG text editors suck at some point. We've been beaten up repeatedly for our CMS's text editor but in comparison we're actually doing pretty well.

Writing a good WYSIWYG editor is hard. Most people think it's a trivial task until they actually try it and start getting user feedback about a million different things that they never thought about. That's also why there are so many bad WYSIWYG editors out there - people start them thinking it will be easy and then find themselves in over their head, unable to keep up with the flow of bug reports, or simply sticking their head in the sand and complaining that the users just don't get how to use the product.

The writely complaint that Matthias mentions is a good example of blaming the users. Pressing backspace at the start of a paragraph changes it to use a BR instead of creating a new paragraph. This is great if you understand what's going on because it provides a simple way to choose between a new paragraph and a BR. The problem is that it doesn't match the user's expectations - they wanted to merge the two paragraphs. It doesn't have to be that way though, you just have to focus on what the user's intention was for each and every action they perform.

As for Matthias' suspicion:

Which leads me back to a long-term suspicion of mine: the base abstraction is wrong. A long time ago computer science decided that documents shall be trees. Things started to go down after that…

Not so. In fact, the Swing text APIs are far more based on an attributed text array than on a tree structure (as I've previously noted). There is a tree structure present, but it's a secondary structure to the text array which brings it much closer to the user's mental model of the document.

The bottom line is that if users are complaining about your editor, then your editors sucks and it's probably costing you sales or at least making the sales cycle much longer and more difficult. You need to invest a lot more in your editor, either more developers on your own in-house editor or by spending more on a better 3rd party editor. Either way, you owe it to your users to make the editor in your product pleasant to use - in most products, it's the place where users spend most of their time1. If your editor is painful to use, your product is painful to use. Don't let the fact that most WYSIWYG text editors suck as an excuse for yours sucking too.

1 - most products revolve around some kind of editor, even if it's not a text editor↩