JC - you're taking my position, which is that not only is SUNW NOT proprietary, but open standards and support for that concept in the development community has been a source of underlying strength for SUNW throughout its history... you need to wipe those glasses and re-read my post...
BTW I read through a big chunk of "the UNIX Philosophy" - great reading and a huge Deja Vu for me. I have a thread of correspondence with the CIO of one of the big insurance companies from 1990 which is almost identical to some of the discussion in the book. This guy was insisting on a fully documented design spec down to the module level, as well as a full entity relationship diagram for the database Schema, before a lick of code was written. I had proposed a top level functional spec and high level schema followed by rapid prototyping. This guy was of course an old-line mainframe guy.
The debate actually got pretty nasty. I eventually "placed a bet" on rapid prototyping. I offered to develop the system to a running Alpha state using my method at no cost, and then submit the results to an evaluation by the management team, while the CIO contracted with a well-known consulting firm for the "full up" design spec and implementation. If the client did not choose my design, they had no obligation.
I had a team of only nine people on the job, evenly divided into client design, network and infrastructure, and database design. The famous consulting team had more than 50 people on the job. Our team met with the users once a week for an hour or two to review the design prototype - the consultants submitted reams of paper on their design for review by the customer on a daily basis. The business unit managers estimated that 20% of their time was spent reviewing those paper design specs from the consultants.
They were not working for free, of course - they were burning through fees at a rate of more than $100,000 a week.
At the end of 4 months, we had a working prototype which fulfilled all of the base requirements. The consultants had a 600 page functional specification and design document and more than a thousand pages of entity-relationship diagrams, but no working code. They had been paid more than a million dollars for that work product.
Our base principles were the same as those in Gankarz' book. If a module was more than 50 lines, it was probably too big... much of the functionality was done in shell scripts... big systems that work are built on small systems that work... build a prototype as soon as possible.
Despite the obvious superiority of the approach, the client did not believe our way was better - instead, they assumed that we had succeeded in spite of our "unprofessional" methods. However, the actual working system was compelling... and they decided to pay us for it and base their new system on that design. But as a final irony, the consultants were then paid more to document our work than we were paid to create the system in the first place.
I wish I could say that thinking has changed in the 10 years since those events, but I still have those design discussions with otherwise intelligent people. This has, of course, now come to be known as the "Thud factor" - even today, a wall of documentation that is out of date before it comes off the printer is more impressive to many senior IT executives than an actual working system. |
