Date: Thu, 31 Aug 1995 07:27:00 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> Cc: nate@rocky.sri.MT.net (Nate Williams), hackers@freebsd.org Subject: Re: /etc/disktab and stuff Message-ID: <10050.809879220@time.cdrom.com> In-Reply-To: Your message of "Thu, 31 Aug 1995 04:36:20 PDT." <199508311136.EAA10989@gndrsh.aac.dev.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I wish.. but I've been trying to pound some common sense into the minds
> of all of FreeBSD about what you do and don't do in a release engineering
> branch of a tree. It is starting to sink in, but it still has a long
> way to go.
Well, I think this bears further investigation later, but I only have
this to say:
If Rod or anyone else wants to pound sense into the project WRT
scheduling and such, the time to do so is NOT 2 WEEKS BEFORE RELEASE!
At that point, if we're still squabbling about what goes in then the
battle is already lost and you're the captain at the stern of a ship
going down, shouting rudder orders as the foredeck goes under and
looking like a complete idiot.
This is not effective management. If Rod or anyone else REALLY, TRULY
and HONESTLY wishes to effect the release schedules then the time to
start rallying the troops and shouting orders was 3 months in the
past, not NOW!
I'm perfectly serious. A release isn't about 4 months of sort of
muddling along like two laconic farmers in a field discussing the
weather ("Ho hum. We have a release coming soon, don't we?" [long
pause] "Yup" [long pause] "Gonna be a big one" [long pause] "Yup")
followed by 3 frenzied weeks of activity as everyone rushes around and
Rod climbs the local water tower with his scoped Mannlicher-Carinno to
take pot shots at anyone not rushing frantically in exactly the right
direction.
This is not project management and anything Rod says to the contrary
here is, I hate to say it, complete fertilizer. He's trying to look
effective by running around slamming doors and making a lot of noise
in the barn about the proper raising of horses, but all the horses
already escaped 3 months ago and are well into the next county by now.
This is just not how it's done and it's utterly ridiculous to pretend
that it is or that we can salvage things by acting like a release team
at the very last minute. I'm reminded of a couple of 5 year old girls
covered in lipstick and mom's jewlery, pretending to be grown-up in
front of the mirror. We can pretend, but that doesn't make it so.
Yes, we started 2.1 with the best of intentions. We had meetings, we
discussed features, we even tried to lock down a tree in preparation.
But we still missed that most fundamental ingredient, the lack of
which rendered the rest entirely moot: CONSISTENT FOCUS.
What do I mean by that? I mean an awareness *all through* the release
cycle of just what we were doing to get to the release day. We (and I
do include myself) instead spent the time muddling around with many
different things, got facinated by the occasional cool feature in
-current and dropped everything to go look at it or occasionally just
got bogged down in just the most ridiculous political wrangling over
some petty issue and wiped out everyone's productivity for weeks at a
time. Now we have a release due very shortly and the usual panic
reaction has set in.
I have been with this project for 4 major releases now, actively
involved in at least 2 of them, and I see this as a consistent
pattern. A couple of weeks of rest following the previous release, 6
months of general dozing and puttering around with bursts of intense
effort and then a final month where everyone freaks out when they wake
from their Rip Van Winkel sleep and say "MY GOD! It's been 6 months
since the last release! We need to do another one RIGHT NOW!!"
It doesn't matter if we had regular meetings every month for the
previous 5 months and in every meeting said "everyone remembers the
release coming up in {5,4,3,2,1} months time, right? RIGHT?"
([chorus] "Yes yes! We're not stupid! We're on it!") We still don't
ACT any differently! We leave the meeting and it's really as if it
never happened.
This leads me to pose two alternatives, and frankly I'm still not sure
which one is "most correct" though my preference is pretty plain:
1. We start actually operating like a real team inside a real company
where tangible progress towards each goal is seriously measured at
each milestone point by management types who make it their sole purpose
in life to worry about such things. Various heads also roll if they've
been day dreaming or absent at any point in the project, not just at
the very end when it's time to punish the innocent and praise the guilty
because everything has gone wrong. In a "real team" you need to sit down
with your manager every week while he goes over your little goal chart to
see what your team has missed and what it's made, and if it's missed
lots of stuff you get the whole "I'm very disappointed" number and
have to go back to your team feeling like shit and upset that though
it really wasn't your team's fault that their development machines were
scrambled by the EMP from that little nuclear accident they had at the
Navy base 3 miles away, your boss is right - you didn't make the goals
and now the whole project timeline is going to suffer. Only with this
kind of committed, constant buy-in to the overall project timeline
do the really big projects succeed in being "commercial quality."
2. We realize that model #1 isn't very much fun and the reason they generally
paid us so much to be principle engineers at large companies (my own
background) was mainly because it's a PAIN to be held so accountable
for one's actions 40 or more hours out of every week. It might, at times,
feel kinda nice to be running the team and seeing your ideas slowly
translated into reality, but it's still nothing more than a whole
heap of work and late nights at your desk filling out progress reports
so that your boss can do HIS job the following morning.
Given that reality, we don't try to pretend that we're anything like
that and instead just try to RELAX a little and enjoy some of the
benefits of not being such a team. We also fully understand that
"worry" is not transferable or commutative and just because you're
jumping out of your shoes with concern, you can't transfer it to
someone else. You can do that in a real company because somebody,
somewhere is generally being paid to take on some of your worries
("HR! My paycheck is late! PAY ME NOW BEFORE I STARVE!!") but not
here. Just because David, Rod or I worry about our release schedule
doesn't give us the right to try and transfer some of that worry onto
others and I'd say a great majority of our problems have come out of
such misapprehensions that we could. That needs to change, and
if we take this option then we need to start treating each other more
like friends and less like each other's managers.
Frankly, I don't think that model #1 is going to work, nor is the
"punishment cycle" that Rod likes to indulge in around this time any
help in even approximating it. The problems aren't in the release
phase, they're well before it and the only way I could guarantee that
we didn't arrive at this predicament would be to start playing the
manager in #1 and I don't think that any of us would like that very
much, me least of all.
We say this a lot, but perhaps we should repeat it more often: We're
doing this for fun. We can take it very seriously, but we're still
not a team of highly paid engineers working inside of Microsoft or
IBM, we're a volunteer project. If we try to warp this group into a
defacto engineering team through intimidation or guilt-tripping then
this is not going to be anything but a very UNHAPPY group of
volunteers and we'll have killed the golden goose in an attempt to get
all the eggs out at once.
I vote for option #2. Let us treat this project seriously and try to
make a success of it, but let us also not totally lose our perspective
in the process. In the typical definition of such things, I am not a
manager, you are not a team, this is not a project. We are a group of
hobbiests that have SOME of the characteristics of all of the above,
but that doesn't make it the same thing and the distinction is quite
an important one.
Thank you.
Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?10050.809879220>