Network device command line interfaces

Robert Bonomi bonomi at mail.r-bonomi.com
Fri Nov 25 05:01:21 UTC 2011


Jonathon Exley <Jonathon.Exley at kordia.co.nz> wrote;
>
> That's the problem - as a propellorhead I don't make the purchasing decisi
> ons. I can recommend products but low cost speaks more loudly than "this g
> ear is a dog to work with". 
> I don't really believe that manufacturers make crippleware user interfaces 
>  for thier products to encourage people to buy a more expensive range. I a
> m more inclined to think that the software developers didn't have a good r
> eq uirements spec to work from and made it up off thier own back. 
> With the wealth of experience of people using these devices in this forum,
>  maybe we could collate some good advice on what features of a UI are real
> ly important.
> Hopefully there are some manufactures listening who can take the advice on
>  board for the next product they develop. 
>

The trick to deailing with this as a propellorhead[sic] is to include a
*monetized* estimate of the increased manpower OPEX of using the 'dog to 
work with' box.  And a TCOS figure over the projected lifetime of the
units.   No need to 'fight' with management about it, just understand
'how'  they make the decisions, and give them the informatin they need
to make the decision come out 'your way'.

Aside -- on your other point, there are *many* _documented_ cases of 
manufactuers deliberately crippling certain features so as to not 
cannibalize the sales of higher-riced units.

IBM was medium-notorious for this.  The original IBM-PC keyboard had 'non-
standard' positioning for several keys (the extra key between 'z' and 'left
shift', the location of 'caps lock', and the bastardized shape/position of
'enter') -- *expressly* to discourage using a PC in place of a dedicated 
higher-priced IBM 'word processor' (the Displaaywriter ??).  Also, the PCjr 
used the _same_ floppy-controller chip as it's big brothers, *BUT* the
interrupt line was not connected, and _extra_ hardware had to be included
in the to compensate for the failure to use the interrupt.  This was done
exprerssly to cripple performance -- so it was useful only for hobby/game
use, and not for any 'real' work (i.e. couldn't do serial I/O _while_ any
floppy I/O was in prgress.  To do file transfers, it took custom code
that would 'suspend' the serial port operation while reading/writing the
floppy, and then 'resume' it after the floppy operation was complete.  
There is absolutely no doubt that this was a deliberate 'crippleware' design,
given that they had to -add- extra hardware, vs doing  it the 'compatible'
way. Yup, they deliberately spent extra money to make it 'incompatible'.





More information about the NANOG mailing list