Fog Creek Software
Discussion Board

good design for geographically dispersed team

Joel wrote
"There just isn't enough bandwidth to do good design when a team is geographically dispersed. I'm not saying it can't be done at all, but the results are vastly better when the entire team is physically in the same location. I'm convinced of this, and will never agree to do software development with a dispersed team"

What about if one person (or people at one location) manage or have the final say on design - and people in other locations do the back-end stuff - I would be interested to hear your thoughts on this situation.  Or do you think that most development is so tied to UI design that it is difficult to achieve this seperation?

Monday, August 26, 2002

Distributed dev is a superset of the close teams that Joel favors.  At any point, you can develop the way you want, and ultimately fork if conflicting goals get too hairy.  In fact, the fear of forks might eventually be considered immature.

Very productive, tight teams can do well in distributed environments.

A hybrid approach for large opensource projects is common.  Huge Linux get-togethers and Python conferences.

Monday, August 26, 2002

I believe Joel always refers to "software development" as in "commercial software development." In that context, I agree with Joel.

I've seen many times when a discussion of certain aspects of software development only get finished when someone walks to the whiteboard and draw some boxes with arrows on it.

Leonardo Herrera
Monday, August 26, 2002

It's not just geographically dispersed teams that have this problem.  The same thing can happen with in a single office.  Consistency is one of the most important things for a UI.  And it won't happen if twelve different people (with different skill levels, interests, and language ability) are all doing UI.

At least within a single office you can have those five-second whiteboard discussions to argue out some UI issue.  But a better way is to have one person do the UI and everyone else just expose a Model (as in MVC) for items needing a UI. 

Another way to do this is generating UI automatically from XML descriptions.  Each feature developer submits the XML, and a separate UI group writes the UI generator.

Monday, August 26, 2002

Is UI design and implementation unique in this way?  I'm not sure.  I've never been involved with a truly distributed team like the Mozilla project.  I'm likely not going to make any decisions about working in a distributed team until I've actually done it myself, either.  Learn from others' mistakes, you say?  Well, maybe... 

But Mozilla is unique in too many ways, the most obvious is that Mozilla is HUGE.  The code base for Mozilla is a monster.  So large that I'm amazed that anything ever came of it.  Yet, the Mozilla browser, which I'm using right now, is arguably the best in the industry.  It beats IE in speed and usablility (I don't know how Windoes users tolerate all that popup nonsense).  Certainly to ciriticize Mozilla for it's results would be wrong.  Despite its size, it did not go the way of the dino, and in the end, it is a thing of beauty.

Back to projects...  I'd say this, any project I've been on needed a strong product definition.  Projects that failed to communicate the product definition to its implementors failed.  New ideas, coool as they may be, should always be pushed off to version 2.  Version 1 should ship, keeping to schedule and be stable.  Having UI designers making decisions in real time is a nightmare.  Been there once before.  If there is one thing I'll never do again, its having UI designers unbound by the same schedule and process as the rest of the team.  One other thing I'll never do again:  I'll never work on a project that had a weak definition and/or questionable support from the company.  In fact, one can guage corporate support based on the strength of the product definition.  If its poorly defined, then someone doesn't know what they want - and truly has not thought through the business case for the product.  They're making it up as they go along - in my experience, that ususally spells failure.

Nat Ersoz
Monday, August 26, 2002

I think the wrong lesson is being drawn from Mozilla's UI woes. There are two major problems (IMO, as a Mozilla QA-type person) that are particularly crippling to Mozilla, and I don't think either of them are inherently problems with the distributed model (or even, necessarily, likely to happen with it).

1) The "chain of command" for the UI is confused and non-existent. For the backend code, there's a "module owner" for everything, who has the final say on whether or not a patch gets in. There's nothing like this for UI: I think Peter Trudelle may be *Netscape's* official UI lead, but I don't know what status, if any, he has under *Mozilla*. mpt is the "default assignee" for UI bugs, which doesn't really mean anything, but he has a certain amount of unofficial authority due to a good reputation for UI decisions and availability. Because there's no clear chain of command, people end up feuding over decisions, and if mpt and the NS people take opposite sides, the deadlock is likely to be broken by whoever produces a patch...or someone tries to placate everyone by making it a preference. This also leads to the "Slashdot"-like Bugzilla discussions Joel mentions: when it's never clear that there *will* be a final decision on an issue, people are always tempted to whine to try to get it reversed.

2) No formal standards for UI review. Code review is a well-entrenched practice: things could be better (the pool of second-level reviewers could stand to be larger), but by and large, code going into the tree meets certain standards of correctness. There's no such control over the quality of UI. Hypothetically, someone could decide that, say, the preferences for setting languages need to be more baroque, and write a patch complicating that function. It goes through code review by the people who own the appropriate backend code, who perhaps have reservations but don't feel competent to comment on UI (and who have a high understanding of ISO language codes, etc., and are unlikely to be daunted by the new UI)...and UI people may not even discover this until the next time they look at this preferences panel.

Not surprisingly, there's a great deal of discontent within the Mozilla community about the lack of polish & so forth that's resulted from this, and there are a number of UI forks underway both within Netscape and as external projects; what, if anything, this will lead to, is uncertain. However, I feel reasonably confident in predicting that the only way for the mainstream project to get a UI that doesn't suck is to treat UI as it does code:
make it clear that there is a place where the buck stops for design decisions (whether that's a Supreme UI Tyrant-Dictator or UI owner committee or a magic 8-ball), and to impose standards of review on UI changes. The first change is probably the most important: once a UI spec is composed and implemented, defending it is reasonably easy, but see$162 for the rather surreal tale of what happens when there's no one with authority to issue a definitive spec. But if these deficiencies of organization are corrected, I don't think there's any reason Mozilla can't have a satisfying and polished UI.

Chris Hoess
Tuesday, August 27, 2002

Thanks for that!  So, if you had your way, what would have the Mozilla UI look like, function?  We ship Mozilla in our set top box product with a small amount of custom "chrome".  We're very satisfied with it, and honestly except for the tremendous size of the thing, would not change much.

Nat Ersoz
Tuesday, August 27, 2002

Well, personally I'm not unhappy with the UI in general, but I'm a sometime Linux user and a "technocrat" and whatever else, so I'm not very sensitive to UI quality. One thing I do find annoying is the inability to delete bookmarks right in the menu; I have to go to "Manage Bookmarks", open up a window, and find the bookmark again before I can delete it. Viewing frame and page source in context menus also seems to be handled badly; in a frame, people almost always want to see the frame source, but it's stuck off in a second-level menu.

But, there's still a lot of people who feel that Mozilla isn't as "polished" as IE, even post-1.0. (Unfortunately, I've mislaid the URL of the latest blog where I saw this.) For that matter, while mpt is occasionally flaky (endless complaints about tabbed browsing, which people seem to eat up, number 9 on his list of UI problems at$35 , trying to impose Mac platform-specific oddities on everyone), I think his advice is often on-target, and not necessarily that difficult to implement. Having a solid organization and enforceable UI specs would, I think, make the UI a good deal "crisper", if only because UI people's time wasn't taken up by feuding and justifying changes.

I'm glad to hear at least one embedder likes us, though; when I'm feeling uncharitable, I'm occasionally inclined to believe that all embedders do is try to break down our standards support in the name of compatibility ;-) (But it's actually a developer from an embedder who's been responsible for a great deal of the performance increases in the past year, so I should be nice.)

Chris Hoess
Wednesday, August 28, 2002

> What about if one person (or people at one location)
> manage or have the final say on design - and people in
> other locations do the back-end stuff

To be on-topic for once in my life, I don't think it's easy for a team of coders to want to be at the mercy of some guru in a far-off world.  Not a theoretical problem, but a practical one.

I take it that your envisioned guru is someone who understands the domain-specific field, and also has a feel for what is practical to implement.  I think that sometimes many developers are not bright or versatile enough to "get it" when something is explained in email or over the phone.  Oftentimes we need another human in front of us to take users' pain seriously and see through their eyes.

That said, I'm a great fan of any form of dev that allows you to work with only the people you want. ;-)

Thursday, August 29, 2002

BTW, you probably want to ask people who haven't had their minds messed up with programming conventionally all the time.  Sure, distributed programming doesn't have enough bandwidth to support developing in the old style.  But you're talking to people who've lived their lives going to centralized schools and the like...  No wonder that we're probably being very inefficient when working with geographically dispersed teams.

Thursday, August 29, 2002


Thanks again.  I'll have to go check out the Mozilla web logs.  What I think is funny is how once someone mentions a "gripe" about a product it brings others to mind.  "Oh yeah, speaking of that, what about..."  I'll save it for the web logs  :)

Thanks again.

Nat Ersoz
Thursday, August 29, 2002

*  Recent Topics

*  Fog Creek Home