Weekend Reading
Over the weekend I read two books with two distinct purposes. The first was “Mouse: A language for microcomputers” by Peter Grogono (now out of print) and the second “DEC Is Dead, Long Live DEC” by Edgar H Schein.
Mouse
Peter Grogono’s book is an object lesson on how to write a book on a technical subject. It is beautifully paced, well illustrated with code and introduces an amazing range of computer language concepts in the easiest manner possible. If I were ever to have charge of trainee developers again then this book and it’s content would be on the course list.
The book introduces a simply structured (Reverse Polish Notation) language by taking the reader through the process of writing a stack based interpreter. The reader is introduced to new concepts almost by diffusion – by the end they will understand the relationship between “high level” languages and assembly codes, understand how variables are organised in memory, be confident with subroutines and functions – passing arguments by value and reference and well on their way to exploring a full range of data types.
The language, Mouse, was developed from a predecessor that was a Domain Specific language used to control a recording studio and running on a DEC PDP8.
The demise of DEC
Which brings me to the second book – one I had been looking forward to reading for a while. I started my professional career as a developer using DEC kit, was a customer of theirs for many years and between times almost became an employee. I was expecting to enjoy the recounting of the foundation, growth and the ultimate demise of this archetypal technology company. DEC was above all a technology business but unfortunately this book just about ignores the technology – giving it a background status at best.
The book represents an interesting viewpoint – perhaps some might say the viewpoint of the “lice” on the body corporate – that of management consultancy, and academic management consultancy at that.
I do not doubt that whenever or wherever a couple of ex DEC people get together (and that must be a frequent event given the numbers) opinion differs on just what happened. To be fair, this book has a couple of amazing insights. There is the 1976 internal report written by Larry Portner (VP of software development) that laid out every challenge facing the business at that time – and those challenges among them that were ignored all contributed to the demise of DEC. The second comes from 1989 when it became clear that Ken Olson (founder and CEO) was just unable to grasp that a $300 dollar semiconductor chip, built by one division in DEC, could outperform his $300,000 dollar top of the range Vax that was going to go up against IBM mainframes.
Lots of people point to DEC’s seeming inability to “get” the PC (something that indirectly allowed a start-up called Compaq to thrive) as a key element in their demise. It is my view that this was only symptomatic of a more fundamental problem – indeed PC based distributed processing only reached sufficient maturity to rival minicomputers well after Digital was in real decline.
For what it’s worth – it is my view that DEC senior management never understood why it was that DEC was successful. I am sure that they got the technology part – they knew that the exciting new computers they built were eagerly sought out by their customers and they had a vision based upon interactive processing – DEC computers were the first to make computing personal. What was happening though was that their low cost interactive computers were carving out a new market – one that IBM, ICL, UNYSIS etc. just did not address.
When DEC grew to be the second largest computer company in the world they got the funny idea that to be number one they needed to attack IBM’s core market – the mainframe.
DEC had thrived by disrupting the existing computer market place. They faltered when they stopped doing that – indeed when they allowed the next disruptive generation to stomp all over them. What is amazing is that with the alpha chip (backed by a new operating system being developed by Dave Cutler) they had the technology to keep on doing what they did so well. Here we are in 2007 (the year that some DEC senior managers originally predicted they would overtake IBM to become number one) IBM has been re-created as a services business (that just happens to sell a lot of mainframes) and DEC survive as little more than a memory and some HP product lines.
Thus DEC bet their own business on the continuation of a model that they had themselves originally disrupted but then became a part of. That model was apparently easy to live within – with it’s high margins and with technology moving forward at an (almost) predictable pace. However the clues were there. DEC had grown large enough to attract an OEM market place delivering alternate printers, back-up and storage solutions all working within the de facto standards created by DEC. Above all, of course, those standards included networking and the Ethernet network model.
What DEC needed to do was to continue down their original path – taking computing into new areas of business and daily life. Yes they should have bitten the bullet and allowed themselves to build PC “clones” and (at least as importantly) created a “commodity” distribution channel for them. With their unique value added approach to taking computers outside of the computer room they would then have become the network server supplier of choice. It is self evident that the Internet is not built on DEC technology – but it might well have been.
Oh yes, the book. It did not work for me but if you can stand reading the word "culture" more than one in every paragraph, it might be of interest to you.
A good yarn to gladden the heart of any Old Fogy.
I am not a big fan of books that use devices like an exchange of letters to tell their tale – although it can just work. The tale that unfolds here in a sequence of emails is however well worth following – even if the mathematical terms are from outside of your knowledge domain. It does not matter – the consequences of them are outside the knowledge domain of at least one of the protagonists.
Over the weekend I read two books with two distinct purposes. The first was “Mouse: A language for microcomputers” by Peter Grogono (now out of print) and the second “DEC Is Dead, Long Live DEC” by Edgar H Schein.
Mouse
Peter Grogono’s book is an object lesson on how to write a book on a technical subject. It is beautifully paced, well illustrated with code and introduces an amazing range of computer language concepts in the easiest manner possible. If I were ever to have charge of trainee developers again then this book and it’s content would be on the course list.
The book introduces a simply structured (Reverse Polish Notation) language by taking the reader through the process of writing a stack based interpreter. The reader is introduced to new concepts almost by diffusion – by the end they will understand the relationship between “high level” languages and assembly codes, understand how variables are organised in memory, be confident with subroutines and functions – passing arguments by value and reference and well on their way to exploring a full range of data types.
The language, Mouse, was developed from a predecessor that was a Domain Specific language used to control a recording studio and running on a DEC PDP8.
The demise of DEC
Which brings me to the second book – one I had been looking forward to reading for a while. I started my professional career as a developer using DEC kit, was a customer of theirs for many years and between times almost became an employee. I was expecting to enjoy the recounting of the foundation, growth and the ultimate demise of this archetypal technology company. DEC was above all a technology business but unfortunately this book just about ignores the technology – giving it a background status at best.
The book represents an interesting viewpoint – perhaps some might say the viewpoint of the “lice” on the body corporate – that of management consultancy, and academic management consultancy at that.
I do not doubt that whenever or wherever a couple of ex DEC people get together (and that must be a frequent event given the numbers) opinion differs on just what happened. To be fair, this book has a couple of amazing insights. There is the 1976 internal report written by Larry Portner (VP of software development) that laid out every challenge facing the business at that time – and those challenges among them that were ignored all contributed to the demise of DEC. The second comes from 1989 when it became clear that Ken Olson (founder and CEO) was just unable to grasp that a $300 dollar semiconductor chip, built by one division in DEC, could outperform his $300,000 dollar top of the range Vax that was going to go up against IBM mainframes.
Lots of people point to DEC’s seeming inability to “get” the PC (something that indirectly allowed a start-up called Compaq to thrive) as a key element in their demise. It is my view that this was only symptomatic of a more fundamental problem – indeed PC based distributed processing only reached sufficient maturity to rival minicomputers well after Digital was in real decline.
For what it’s worth – it is my view that DEC senior management never understood why it was that DEC was successful. I am sure that they got the technology part – they knew that the exciting new computers they built were eagerly sought out by their customers and they had a vision based upon interactive processing – DEC computers were the first to make computing personal. What was happening though was that their low cost interactive computers were carving out a new market – one that IBM, ICL, UNYSIS etc. just did not address.
When DEC grew to be the second largest computer company in the world they got the funny idea that to be number one they needed to attack IBM’s core market – the mainframe.
DEC had thrived by disrupting the existing computer market place. They faltered when they stopped doing that – indeed when they allowed the next disruptive generation to stomp all over them. What is amazing is that with the alpha chip (backed by a new operating system being developed by Dave Cutler) they had the technology to keep on doing what they did so well. Here we are in 2007 (the year that some DEC senior managers originally predicted they would overtake IBM to become number one) IBM has been re-created as a services business (that just happens to sell a lot of mainframes) and DEC survive as little more than a memory and some HP product lines.
Thus DEC bet their own business on the continuation of a model that they had themselves originally disrupted but then became a part of. That model was apparently easy to live within – with it’s high margins and with technology moving forward at an (almost) predictable pace. However the clues were there. DEC had grown large enough to attract an OEM market place delivering alternate printers, back-up and storage solutions all working within the de facto standards created by DEC. Above all, of course, those standards included networking and the Ethernet network model.
What DEC needed to do was to continue down their original path – taking computing into new areas of business and daily life. Yes they should have bitten the bullet and allowed themselves to build PC “clones” and (at least as importantly) created a “commodity” distribution channel for them. With their unique value added approach to taking computers outside of the computer room they would then have become the network server supplier of choice. It is self evident that the Internet is not built on DEC technology – but it might well have been.
Oh yes, the book. It did not work for me but if you can stand reading the word "culture" more than one in every paragraph, it might be of interest to you.
A good yarn to gladden the heart of any Old Fogy.
I am not a big fan of books that use devices like an exchange of letters to tell their tale – although it can just work. The tale that unfolds here in a sequence of emails is however well worth following – even if the mathematical terms are from outside of your knowledge domain. It does not matter – the consequences of them are outside the knowledge domain of at least one of the protagonists.
posted by Mike Griffiths | 3:38 AM
0 Comments:
Post a Comment
Links to this post:
Create a Link
<< Home