Fog Creek Software
Discussion Board




CAMEL: The morning meeting

Heh. I'm gonna make a project of keeping you guys posted, since this looks like it's going to be a fun ride (that is, if you're interested). I chose "CAMEL" as the tag:
http://phrases.shu.ac.uk/bulletin_board/6/messages/552.html

So we got together with two senior managers yesterday morning to "talk it out." It was actually fairly amiable - there was definitely a lack of communication on both sides (we didn't keep them posted as to what we were doing in the week we decided to take the bull by the horns on this project).

There were also personnel issues - the three senior architects (myself included) have only been in this office for about two months, while others have been here for years. Some of them complained to management that we were off "doing our own thing" and "having secret meetings" and leaving them out. From our point of view, we were knuckling down and simply getting things done.

So the net result was that this morning we had a meeting to present the organization methodology to "the team" (14 people). We are now going to move forward by having everyone review the requirements as entered and keep track of any comments they have. On Monday we're going to get together again (all 14 people) to discuss all the comments.

Yes, it's more important to keep everyone happy than to pursue a project plan.

Philo

Philo
Thursday, March 13, 2003

I'm looking forward to this story unfolding. Thanks for the update Philo.

Just me (Sir to you)
Thursday, March 13, 2003

keep the stories comming Philo.

Prakash S
Thursday, March 13, 2003

"A camel is a horse designed by a committee."

Sir Alec Issigonis (1906 - 1988)
British automotive engineer (designer of the Morris Minor)

Anonymous Coward
Thursday, March 13, 2003

Keep the reports coming, Philo!

Mark Hoffman
Thursday, March 13, 2003

I think you were using sarcasm when you stated: "Yes, it's more important to keep everyone happy than to pursue a project plan." (It's a little hard to tell from the text of your note.)

However, there is actually a lot of truth in this statement when read without any sarcasm. It's important to make the effort to mostly "keep everyone happy" as well as "pursue a project plan". This is something many engineers (including me) either have trouble with or aren't even aware of the issue.

For example, it's fine to have meetings with only a small group of people to decide designs, architecture, etc, but the decisions, reasons for them, technical issues, and even the as-yet unresolved questions need to be conveyed to and discussed with the rest of the team, almost immediately and frequently (responding to any criticisms, accepting any suggestions, explaining choices that were made, listening to suggested alternatives). Early in the process this needs to be done face-to-face, later it can be mainly emails, discussion forums, etc still with occasional meetings.

Philip Dickerson
Friday, March 14, 2003

Philip: Agreed on keeping everyone informed and maintaining morale as much as possible, but not to the detriment of the project. People don't get to take roles or join teams just because they want to (let's face it - *everyone* on the project wants to be an architect).

If a developer cannot work productively doing what they're assigned to do, then they need to leave. For example - one team here has to work with implementing an EDI solution. I've just spent the last year living EDI on another successful project. I let the team leader know that, then I shut up. I have no idea what the status of that team is, but I'm not worried about it - if he needs my help he knows where my desk is.

I am most certainly NOT going to run to management whining that I should be on the EDI imports team.

Philo

Philo
Friday, March 14, 2003

(let's face it - *everyone* on the project wants to be an architect).

Of course they do.  It will be a cold day in hell when I code something that someone else "architected".  Likewise, if I have to write the spec, then I might as well spend the remaining part of the day writing the code.  I can then go home and call it all "done" - AND take responsibility for the remaining bugs that ensue.

This kind of goes back to the notion of specialization (previously discussed).  Based on what I've read in this thread, I'd be inclined to give you enough rope and watch you hang yourself - a trick occaisionally used when someone is playing power politics with the code base.

Nat Ersoz
Friday, March 14, 2003

Nat - if you are working on an application that is large enough to require fifteen developers, are you honestly suggesting that fifteen people take part in designing the architecture of the application?

Philo

Philo
Monday, March 17, 2003

Of course.  That is exactly what we do, and have done in my 20 years of engineering experience.

Nat Ersoz
Tuesday, March 18, 2003

*  Recent Topics

*  Fog Creek Home