Truly great software development
It’s vacation time, and a happy byproduct of vacation is a chance to catch up on my reading. I’ve always been fascinated with the seminal software systems development projects that have taken place over the history of the industry.
The History of Software has a good retelling of the development of the first real time air defense system (SAGE) which at one point employed more than half of all of the software engineers working in the United States.
I’ve read The Mythical Man Month several times over, which is a collection of lessons learned from IBM’s OS 360.
This vacation I recently finished Showstopper!, an inside view of the development of Windows NT, led by the widely respected Dave Cutler. Four years and over a $ hundred million in the making, NT was a moonshot effort that’s shown incredible longevity. Now 15 years old, the kernel of Windows NT is still essentially the core of today’s Windows Server and Windows XP operating systems. The book does a great job of describing the different key contributors, their personalities and how they intermeshed, which neatly sums up pretty much all there is to learn about successfully creating a great software product.
The author had an excellent observation towards the end of the book that struck me as an important reminder with today’s mindset of “Anything worth doing can be done with three engineers and some Ruby on Rails.”
"A quarter century since the first fissures were spotted in the edifice of Bigness, it is now fashionable to dismiss big organizations and dinosaurs, incapable of managing complexity. It is hard to argue against specific examples. But this does not mean that small organizations are by definition to the answer to the challenge of complexity. While the entrepreneur and lone genius are rightly celebrated as engines of creative destruction, “small is beautiful” is a false cure for the Bigness disease. 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."
I’ve still got The Soul of a New Machine and Rebel Code to read. Please let me know if there are other great books about software projects that I should know about.
posted by Charles @ 3:09 PM
27 comments
27 Comments:
Charles,in 97 I wrote a Gartenr paper grading complexity of projects and making the point that single loction, single business process projects were type 1s and global, multi-business process projects were Type 3s. You are abolutely right there are "complexity drivers". But if Ruby projects are 1, and global SAP proejcts are 3, the SAGE project you quote is a 9, because it was massive and one off. Projects around SAP are repeatable, and therefore much more manageable.
What I called type 3s in 1997 still are classified as type 3s today in spite of 100s of experiences. They should really be 2 1/2 or 2's but mentally SAP (and your partners)still want to portray them as complex. The services guys do it to justify their fees, not sure why SAP continues to enforce that image. The core R/3 functionality came from R/2 (it was called RF, RK etc) then but thousands of projects have been done and yet we have seen little real productivity in doing them...SAP often wears complexity as a badge of honor. Not good for you, or your customers.
Vinnie, I'm talking about a passion for creating something truly great and timeless. That's what most people in the software business live for.
Not everything needs to turn into a "browbeat the vendor" rant.
Charles, sorry for having offended. I should have explained more. My point is if you truly want to write complex code and do pasionate stuff, there are places like NASA, NOAA, FAA which are working on some fascinating, complex projects like stuff to track hurricanes and manage the national air grid. But business apps are really meant to be boring and predictable. Some IT architects are romantic folks, but most CIOs I know do not want "art" and passion from their vendors - they want things that work and are economical and keep improving. To me, the 100th implementation should take 15-20 less effort, the 1000th one 40 less effort etc. Assembly line concepts, not art...that's our disconnect. I expect efficiency and assembly line concepts from vendors like SAP..and so come across as ranting ...
Charles,
I'm glad you enjoyed history of software, it is one of my favourites. Martin Campbell-Kelly deserves to sell many copies of it.
It is something I go on a lot about, but the US software industry owes a serious debt of gratitude to the US defense industry. The history of the industry is not just about guys in garages...
When I have a moment I'll do a reading list too.
Vinnie,
I'm not offended, I just think it's off-topic. To the points you just made, I completely reject your assertion that if you want to build great product, go work for NASA, if you want to do passable, boring work, do it in enterprise.
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.
A few great business software products:
Well Windows NT per my original post. That gave Microsoft it's first real toehold in the enterprise and today they have over 20% of the market.
R3 for another. Essentially the business operating system for thousands of the world's most recongized businesses.
IBM's OS 360. This MADE IBM, and turned the company into a profit generating machine for several decades. 30 years later a large percentage of the world's mission critical data is processed by the 360 or more likely the successor 390.
Lotus Notes. Defined groupware and collaboration software.
Java. Made portability mainstream, introduced component based development. Java development still dominates enterprise development.
Were all of these based off earlier concepts? Sure. That's the way the advancement of human knowledge works.
If these sorts of outcomes excite you, you may want to work in the software busienss. If they don't, well there's lots of other professions out there.
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. It really had nothing to do with global distributed or single process or multi-process.
Implementation is a completely different topic. I think that would be a great topic for a post on your blog, especially if you make it a conversation and try to get to the root cause of why this is (hint, it's not an industry-wide conspiracy to bilk your clients).
Charles, I have asked multiple times on my blog and eslewhere why the 100th project takes as much time as the 1st. And why the 1000th takes as much as the 100th. No matter what we agree on what is elegant software, you would agree me implementation need not be similarly romantic or elegant. The question SAP does not like to be asked is why does it allow to continue around its products - and indeed why its own consulting teams reinforce that image of complexity and need to spend x times in implementation what the software costs.
On software - each of the products you mention is an industry milestone. I would add Oracle, Netware and a few others to the list. But, look at it economically. For the $ 100 b customers pay a year to the s/w industry the list is awfully short.
Sorry, Charles, my job is to help clients get the most out of their tech spend. Much as I can personally admire certain products - and it may surprise you, I do enjoy well crafted software, in the end I have to measure "greatness" from that economic lens.
Charles,
You have the Tier 1 books covered, the following are a good reads
GOTO: Steve Luhr:
A bit shallow but comprehensive overview of rise of the software industry from the late '40s on. Best account of the history of FORTRAN development that I have read.
Inside OS/2: Gordon Letwin
I think Gordon joined Microsoft in 1977 and left in 2003. Good insights into the hacker mentality of the early microsoft developers and of course OS/2.
Revolution in the Valley: Andy Hertzfeld et al.
Steve's Pirates and the early days at Apple.
Triumph of Nerds/Accidental Empires: Bob cringleys' books.
Gossipy but fun fun fun!
Where Wizards Stay up late: Origins of the internet, Katie Hafner.
Early development of ARPANET.
On the big teams necessary for great design, I'm not sure it is that clear cut. We get into subjectivity, what is great design to you might be only useful to me. Form vs Function argument. FORTRAN, UNIX, C, Lisp, Visicalc, Java (pre 1.0) etc. were built by a handful of people and it is hard to say they are not great software products. On the other hand, some great systems were built by big teams (OS/360,SAGE etc.).
However there are big systems that have been very useful - WNT, R/3, Java (1.1 onwards), Oracle etc. But are they great products? Take WNT for example, at the time Helen is making the quote about NT, putting gigantic teams on WNT was possible because WNT was really VMS+1. It was possible to stitch together huge chunks of API level code written in relative isolation without having to worry about the internals barfing. But does cranking out lot of API and UI code (with all due respect) make it great? I hear with Vista, developers create maybe 4 or 5 lines of code on average everyday, how can you have passion anymore?
To use metaphors of architecture, since we are into form and function, nobody would argue that the empire state building is a work of great design and usefulness and it is complex and big. However, does a sprawling apartment complex, which is clearly useful, complex and big qualify for great architecture? Does greatness scale with number of apartments? In software terms, does adding another 1000 API's make a product greater? Useful:sure, Great design: Not sure.
So, I'm not sure which axis RoR qualifies on, (pure Ruby maybe on form). Compared to examples we discussed, the abstraction that RoR provides is low. Mostly driven by programmer's ADD tendency to jump on the new new thing and clever marketing. People who mention it in the same breath as SAGE, FORTRAN, OS/360 or NT are just being silly.
Vinnie,
Do you really think it's in SAP's best interest to have high implementation costs? Our core business is product license and maintenance revenue. The cheaper we can make the hardware, database and implementation, the more money the customer has left over for our products.
Let me cook up a post on this topic. I think the reasons behind the continued high services costs are many and subtle.
Naveen,
Thanks so much for the extended reading list! I had bought Fire in the Valley but never got around to reading it. The rest were relatively new to me.
I agree there have been some small, simple things that have gone a long ways (e.g. Mosaic) too.
I also agree that quantity is definitely not the path to a great product. The NT kernel is what's lived a long life, not all the feature/function stuff tacked onto it.
I don't buy that building off an existing base negates greatness. Sure R3 is R2 + 1, but a few things in the design took it from a few hundred customers to several thousand. Intuit is sort of the same way, the 100th small business accounting package but somehow they cracked the code. Linux was terrible for years before it became passable. Most of the time you seem to iterate around it a few years until you crack the code.
Vinnie asks "why the 100th project takes as much time as the 1st. And why the 1000th takes as much as the 100th. No matter what we agree on what is elegant software, you would agree me implementation need not be similarly romantic or elegant. The question SAP does not like to be asked is why does it allow to continue around its products..."
Quite frankly, with all due respect to a very experienced guy, this is a riduculous comment for two reasons:
First, SAP has been dealing head-on with this issue for years. In fact, folks who worked for me developed the original AcceleratedSAP tools, a project which started back in 1996.
Second, customized packaged software must be tailored to the needs of a business. Doing it right takes time. Of course, it can easily be done wrong, and then I'll write about it on my blog.
Michael Krigsman
http://projectfailures.com
Michael I have looked at workplans and proposals from SAP and its partners for a decade now. At the Unit level - numebr of horus to write a simple v/s complex report or interface the effort has not gone down. Rates have not gone down much - another productivity indicator (other than in offshore settings). There is still very lttile work done in central factories - too much coding, testing etc done at individual client sites. See my noite below for 5 areas of optimization in ths services delivery ecosystem - SAP and partners have a long way to go.
http://dealarchitect.typepad.com/deal_architect/2006/01/frederick_taylo.html
Vinnie,
The age-old problem: do consultants work for the customer or for themselves? A vendor like SAP has no choice but to engage an eco-system of consultants and partners. The question becomes controlling that diverse group.
From ten years of experience working with SAP, I know that the company really does want to improve service to customers -- that's an obvious point. However, aligning the interests of external service providers with customers is more tricky. One of the key goals of AcceleratedSAP, back in 1996, was developing this kind of alignment in the face of exhorbitant implementation costs.
Unfortuantely, there is a tension between your five services optimizations and the economic goals (ie: greed) of many (but certainly not all) consultants. Not an easy problem for any software vendor to address.
Michael Krigsman
http://projectfailures.com
Michael - sorry. Your true "partner" is our customer. not your service partners. You focus on their interests and your brand does not suffer, your slaes cycles drop. You have to become aggressive about your ecosystem. Pre ASAP you almost got destroyed because of the implementation overruns. Post ASAP look at how many of your customers wrote off $ 25 m plus...your software worked ok in most cases, the project costs just went out of control.And don;t just blame the partners. SAP consulting is not innocent either.
Vinnie,
I could not agree more -- yes, the customer is the true partner. However, the question of implementation complexity and failure is a little bit more complicated to answer.
Implementation failures generally do not have a root cause based in technology. Failures usually comes from arrogance, inexperience, or greed on the part of the vendor, consultant, or customer.
Incidentally, I have referenced this interesting discussion on my blog here.
Michael Krigsman
http://projectfailures.com
This comment has been removed by the author.
This comment has been removed by the author.
Good Stuff buddy
I thought the information above has given me great topics to think about. Thank you!
Best wishes,
Software developer
http://www.vinove.com
This comment has been removed by the author.
Good Stuff!!!!
Software Solution
This comment has been removed by the author.
I thought the information above has given me great topics to think about. Thank you!
software development
nice post..it was interesting to read
u can visit MidasWeb - Web Development Company to get more idea on software development
Blogs come and go and blogs like yours provide a valuable resource tool for others to learn. Thanks. "Discover Exactly How I Went From a $59 Affiliate Check to $7,975.63 in 2 months and How You Can Too!" EDC Gold Profits
Your site allowed me to do some more research on how to make money and now I Make $3k plus Daily. I'll show you step by step how You Can Earn $997 Per sale and keep 100% Its Amazing Big Money! With This Proven Automated System. Your New Fortune
nice article . thank you
nice post thank you for this post .
South Africa Staffing
Great posting! easy to download
Oes Tsetnoc one of the ways in which we can learn seo besides Mengembalikan Jati Diri Bangsa. By participating in the Oes Tsetnoc or Mengembalikan Jati Diri Bangsa we can improve our seo skills. To find more information about Oest Tsetnoc please visit my Oes Tsetnoc pages. And to find more information about Mengembalikan Jati Diri Bangsa please visit my Mengembalikan Jati Diri Bangsa pages. Thank you So much.
Oes Tsetnoc | Semangat Mengembalikan Jati Diri Bangsa
Post a Comment
<< Home