"Truly great software development"
Charles Zedlewski of SAP has a nice post on his summer reading on large technology product developments including The History of Software, Showstopper! and The Soul of a New Machine. He expresses his admiration of large (and immensely successful) industry projects like Windows NT, SAP R/3, Sun Java, Lotus Notes, OS/360. As he says in the comments "Common among all of these products: it took a sizeable group of very smart people several years working as a tight team to get there."
I would also throw in Oracle 8, Netware, Google - no question the software industry has had some outstanding products. And when you look at what the FAA is attempting with the National Air Grid or the National Weather Service with Hurricane tracking, the mega software project is alive and well. No arguments with Charles so far.
But then he proceeds to quote questions around the current mindset of “Anything worth doing can be done with three engineers and some Ruby on Rails.” "The really grand dreams of humanity increasingly require immense resources and armies of skilled people; however nimble, small agencies are ill equipped to marshal the required people and resources."
That got me going. You can see the passionate banter in the comments. Everything does not have to be big. SAP is particular, I believe, needs to be sensitive to the fact that a lot of bigness - and a lot of waste - has been justified in its name.
Charles responds "I also don't care if CIO's see art or passion in a great software product. That doesn't affirm or negate its greatness. If they refuse to pay money for it, well that's a different story."
That is the story, Charles. CIOs do spend $ 100 billion each year with the big software vendors (and much more with integrators and smaller software companies). I would argue for that spend there have been too few NTs and OS/360s, and way too many delayed MS Vistas and poor quality Oracle 11s. And massive overruns on customer implementation projects.
Greatness to me is not just an exciting product - it is also one developed by the vendor and available to be implemented by customers at a reasonable budget. And this is where constraint based thinking like that around Ruby on Rails is good for the industry. More for less. Much more for much less.


I agree with you in that there are a lot of good SW-products developed by small vendors. They are mostly more innovative etc.
But on the other side, I also understand the concept of "beeing with the winners" = the marketleading large vendors, who are becoming bigger and bigger by buying the small vendors. Beside it always is comfortable to be with the winners, there are also a lot of other benefits by buying from the large vendors:
- Their prices are mostly cheap and large organizations can get good prices
- They are presented (sales, support etc) most over the world, incl. Denmark
- Mostely graduated and experienced developers have competences in there products
- U have assurance in there future and that they do not close the business tomorrow or beeing bought up by others bigger vendors with risc of not supporting the product anymore.
Posted by: Asim Hanif | August 23, 2006 at 09:05 AM
Asim, thanks. Not sure I was saying buy from smaller vendors. I am urging big and small vendors to think big, but execute small. Speak softly and carry a big stick...
Posted by: vinnie mirchandani | August 23, 2006 at 09:12 AM
Hi Vinnie,
My problem with the "Anything worth doing can be done with three engineers and some Ruby on Rails" school of thought is that little attention is paid to elements like scalability, availability and recoverability - something that CIOs should be concerned about. While I'm not sure I would characterize the effort as requiring "armies", it does take a certain amount careful design and implementation. The nature of the beast is such that this work needs to be done up-front. Small companies can do this, no doubt. They often don't because they're under pressure to get the product out, and it's justified and excused because they're Agile, nimble and what not. As a result, CIOs are stuck with production systems that are prototype-class. This story cannot have a happy ending.
Posted by: Aditya | August 23, 2006 at 11:08 AM
Aditya, again this is not about speaking highly about smaller vendors. Agile methods and resuse and economies of scale and repetition can and should also be used by every type of vendor. It is also about productivity from internal IT. It's about more payback from every tech dollar.
Posted by: viinnie mirchandani | August 23, 2006 at 11:39 AM
Vinnie,
Just to enhance my orginal point:
Many great things come from small teams and foucsed projects. Many, but not all; and it will always be this way. It's easy for you or I to argue against the other extreme point of view.
Yes there are many moonshot projects of large teams that fail and underdeliver (more than 50% I imagine). These examples are many and easy to throw darts at, but it doesn't mean that you can throw out complexity as overwrought or avoidable.
It's also good and fine that you or your clients don't marvel at the greatness of those timeless innovations like the OS 360. They use them anyways. It's like the difference between being a consumer and an afficionado. The consumer buys the BMW because it's reliable, runs fast and corners well at a good price. The afficionado can tell you everything about the new steering linkages and air intake system in the 2007 model. Most of the market is comprised of consumers. Most everyone who designed the next BMW is an afficinado. Be grateful some of the products you use are built by afficianados.
Passion for the product mostly belongs in the vendors and those few consumers who just happen to love the stuff. I'm more than happy to serve the everyday consumers who have more utilitarian concerns.
Posted by: Charles Zedlewski | August 25, 2006 at 12:38 AM
actually Charles we agree more than you may think. When I was at PwC I learned from a wise old project manager that RAD (Rapid) is FRAUD without FU. At Gartner I cautioned against all the rapid implementation methods that came out in late 90s including SAP's ASAP.
Having said that, I see bigger vendors in particular selling big, scoping big, not being bothered by big write offs..
They say the 3 words a parent dreads the most are on a tox box "some assembly required". In our industry we seem to take pride in taking that to an extreme...
Posted by: vinnie mirchandani | August 25, 2006 at 07:26 AM