I recall Tom West (Chief Scientist at Data General, and star of Soul of a New Machine) once saying to me when he visited New Zealand that there was an old saying “Hardware lasts three years, Operating Systems last 20 years, but applications can go on forever.”
Over the years I have known many application developers and several development managers, and one thing that they seem to agree on is that it is almost impossible to maintain good code structure inside an app over a period of many years. The pressures of deadlines for features, changes in market, fashion and the way people use applications, the occasional weak programmer, and the occasional weak dev manager, or temporary lapse in discipline due to other pressures all contribute to fragmentation over time. It is generally by this slow attrition that apps end up being full of structural compromises and the occasional corner that is complete spaghetti.
I am sure there are exceptions, and there can be periodic rebuilds that improve things, but rebuilds are expensive.
If I think about the OS layer, I recall Data General rebuilding much of their DG/UX UNIX kernel to make it more structured because they considered the System V code to be pretty loose. Similarly IBM rebuilt UNIX into a more structured AIX kernel around the same time, and Digital UNIX (OSF/1) was also a rebuild based on Mach. Ironically HPUX eventually won out over Digital UNIX after the merger, with HPUX rumoured to be the much less structured product, a choice that I’m told has slowed a lot of ongoing development. Microsoft rebuilt Windows as NT and Apple rebuilt Mac OS to base it on the Mach kernel.
So where am I heading with this?
Well I have discussed this topic with a couple of people in recent times in relation to storage operating systems. If I line up some storage OS’s and their approximate date of original release you’ll see what I mean:
| Netapp Data ONTAP | 1992 | 22 years |
| EMC VNX / CLARiiON | 1993 | 21 years |
| IBM DS8000 (assuming ESS code base) | 1999 | 15 years |
| HP 3PAR | 2002 | 12 years |
| IBM Storwize | 2003 | 11 years |
| IBM XIV / Nextra | 2006 | 8 years |
| Nimble Storage | 2010 | 4 years |
I’m not trying to suggest that this is a line-up in reverse order of quality, and no doubt some vendors might claim rebuilds or superb structural discipline, but knowing what I know about software development, the age of the original code is certainly a point of interest.
With the current market disruption in storage, cost pressures are bound to take their toll on development quality, and the problem is amplified if vendors try to save money by out-sourcing development to non-integrated teams in low-cost countries (e.g. build your GUI in Romania, or your iSCSI module in India).
Filed under: N Series, Nimble, SAN Volume Controller, Storwize V7000, XIV |
We're all only here temporarily... 
Hi Jim.
Good post although I would question the DS8000 date.
The IBM SVC was announced to the world June 2003 and since the Storwize product line uses a direct port of that code I agree you can safely argue that Storwize code has an announcement (start) date of 2003.
The DS8000 on the other hand was announced Q4 of 2004 but was a software headcase till around Q2 of 2005 (I know as my backside was on fire for those 6 months dealing with the fall out). While you could argue that the DS8000 code had very strong ESS (Shark) heritage, the Shark was around well before 2000 and in fact the Shark was based on the VSS or Tarpon which had some 3990-006 heritage which drags us back almost to the 80s. But I can say with great certainty that pretty well every line of Shark code was completely rewritten for DS8000 from the ground up as almost every aspect of how the hardware worked was changed.
But anyway… if we are going to say Storwize started in 2003 on announcement date, then I think you have to say DS8000 started in 2004.
LikeLike
I was assuming that the ESS / Shark was the code base for the DS8000. Wasn’t the DS8000 mainly just a back-end change from SSA to FC? …albeit with a new GUI courtesy of Romania : )
LikeLike
DS8000 was a late addition to my list. I guess it’s a sign of how ambiguous some of the code ages can be. Storwize disk systems for example are a mix of SVC and DS8000 code (with bits of XIV-like GUI).
LikeLike
I remember the DS8000 code issues well. It was a deeply embarrassing time for all involved and I seem to recall the issues dragged on longer than Q2’05. That does highlight the other aspect to age – new things are sometimes immature.
I was going to change it to 2004, but got part way through the edit and I can’t quite bring myself to do it without acknowledging the code rebuilds that no doubt VNX2 and ONTAP have gone through. So I will handle it another way instead as a stated assumption in the table.
LikeLike
and CLARiiON was based on HADA (1991)… the dates end up looking more and more arbitrary, but the principle remains the same.
LikeLike
It’s an interesting debate! shark and ds8000 did have binary compatibility for mirroring but the code differences were so massive that I think it’s safer to say 2004 for DS8
If we instead said they had the same base then the DS8 code would have a start date somewhere in the 90s….
LikeLike
I’m running with 1999 which is the release date on the F10 (SCSI) Shark. It’s the principle of the bigger question that’s more important i.e. What state are these old code stacks in?
LikeLike
Cool. Of course we could probably add1-3 years to each product to account for development time before the world even heard of these products.
LikeLike