RFC: startup time - again

[Adrian Wilkins]

Forest Bond wrote:
> Hi,
> 
> On Wed, Sep 10, 2008 at 04:44:47PM -0500, Matthew D. Fuller wrote:
>> On Wed, Sep 10, 2008 at 03:20:55PM +0100 I heard the voice of
>> Adrian Wilkins, and lo! it spake thus:
>>> My userbase would never
>>> have grokked the default porcelain in git, so for them, git would
>>> have been a lot slower than Bazaar.
>>
>> I don't buy this for a second.  git isn't fast because it has a wacky
>> UI
>
> I don't think Adrian was saying that git is fast *because* its UI is
> incomprehensible 

My point was broadly that if an operation requires you to think hard or
refer to the manual before you do it, you've just added a large amount
of latency. The software may do the job fast, but the total time taken
for the operation now includes a chunk of head-scratching ; it doesn't
matter how fast it is _after_ you push enter if it takes you longer to
get there.

bzr might do actual work slower than git, but I'm prepared to believe
that some of that difference is made up for by being easier to
understand and reducing user latency. This may be small, and varies
per-command, per-user, and with how long the user has been using the
product. For myself, with long experience administering and converting
version control systems, the difference is probably small. For my
userbase, who are not programmers, I think it would have been somewhat
more pronounced.

It's a shame that OSS projects have not yet come up with a way of doing
usability studies more scientifically than gathering opinion on lists.
Ideas about a shell that can measure human time, alongside real, user,
and system, are flitting into my head...

Given that changes to user interfaces annoy users and slow them down
(even if the UI was bad to begin with), but the CPU just takes changes
to the internal code in it's stride, I'd rather have an excellent UI and
a slower core which I can improve later, over a confusing UI and a core
that is at the sweet end of optimal.