Symphonious

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↩