Business plus hacking is a dangerous mixture. Handle with extreme
caution.
I have lots of interesting replies to reply to today, but I want to
start here (on the svn dev list). I think what I'm going to say is a
no-brainer and the hard part is figuring out why it didn't happen in
practice and what to do about it now and in the future.
Very abstractly (and roughly speaking), I think one should:
1) explore and understand a technology domain
2) develop a widely shared understanding of its nature
3) develop opinions about what to do with it
4) be able to explain it clearly and precisely to just about
anyone; do so
5) explore all that carefully
6) THEN, (if appropriate) integrate it into business plans
Don't I have a (slight) gift for stating the very very obvious as if i
were the only one who knew it?
Taking a broader perspective, steps (1..5) are an activity that
businesses need to fund and support (research and development) if they
want to have a reason to keep existing. Frankly, looking at the
industry, that'd be a good place to start picking up the mess.
Activity 6, rather than being where the battle is among competing
executive teams, boards, and investment brokers, should really be a
fairly mundane tactical space. Really, all those business decision
makers need to focus on 1..5 and wear that fact on their sleeves.
That's why they will deserve trust.
If those decision makers aren't personally qualified to grok the
technology .... well, maybe they know people who can help and maybe
that means we just all go a little bit slower. I mean, they can
already read and write and do arithmetic so they're 3/4 of the way
there (at least); some of them are former engineers; I suspect they
can handle it pretty well, actually. All it takes is the will to act.
One is losing hard whenever things go in approximate reverse. As in:
1) get a so-so picture of a possible cool hack; make some good
demos or a neat power-point presentation
2) figure out how (supposedly) it can drive a business model
(or reputation exercise or other kind of power trip)
3) start the project. Get at least some people into such
a bind that their livelihood depends on a relentless march
to completion.
Our interactions look to me like you are losing hard. Lame replies
about "oooo its shell scripts" and "that's a post 1.0 issue", both of
which you are obviously collectively capable of doing much better
than, are evidence.
In similar situations, with other groups forced into losing hard, I
have formed the impression of a quiet war: engineers basically lie and
hide things from business decision makers who expect this, tolerate
it, count on it, and dance their merry way straight to hell. I hope
things aren't that bad where you are, but i'd be surprised if they
were much better than that.
What if you got really close to 1.0, then something came along that
caused you to rethink the fundamentals of what you are doing and the
impact it will have if plans proceed? Do you have the freedom to stop
and think? For a day? A week? Some months? Or will you lose your
job if you don't make a deadline? If your company *has* to shut down,
and you are a wage slave, has your employer made provisions to keep
you safe for as long as possible? Do you have the freedom to bail?
Why do people volunteer for your project, unless because it gets a
certain kind of press, sending a perhaps rather misleading message
about the value of volunteering to volunteers. And how does that
press happen? No -- volunteers aren't fools. I almost volunteered
for svn myself, purely on the basis of the technology, and that's
where i'd guess the best volunteers are at. (Ultimately, I didn't
volunteer personally because of some subtle flaws (imo) with the tech
that were easier to work-around by writing arch than volunteering into
svn and trying to fix them from within.)
We started chatting about patch set formats long ago. I thought it a
good place to start because, _if_ we reach more or less agreement on
that, then i think there are broader implications for the rest of your
design. Even if we never get to those broader implications, a common
patch set format won't be a bad thing to have, in my opinion.
From what I've seen on the dev list, that discussion could have
reached a level where we were building models and proofs like that one
i sent you, using those as tools to describe and explore the design
space, all of us getting a much clearer idea of what the heck this
technology is really about. Documents like that should have, in my
view, been where that discussion wound up within a few days of its
start; and we might or might not be still talking over the issues
today. But instead, well, it's all "post 1.0" (post GCC-team
deployment? post apache-team deployment? what's the next way in
which the true nature of the technology will have to take a back seat
to business).
Perhaps arch is completely wrong. I very much doubt it, but let's
stipulate that that's the case. Regardless, arch is at least a very
plausible indication that svn has a few fundamentals wrong (and
perhaps some other fundamentals right). It's a stop and think kind
of event -- not a post 1.0 issue. Even if its wrong, it has value
because it can clarify your thinking while you figure out exactly
_why_ it's wrong.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 10 20:51:38 2002