Chapter Four - The IBM years


In 1994 I joined the Object Technology Practice at IBM. This was a group started by Tom Love and at the time I joined had 35 people. The logo for our practice (left) was based on the Wild Ducks story. We developed custom applications for clients using Smalltalk as the target language. We followed UML but began to embellish it and ultimately created something called the World Wide Systems Development Method (WWSDM pronounced Wisdom). 

The project that I was hired to mange was an internal IBM project where the company was tying to rebuild most of its internal systems. My team was creating something called the Business Class Object-Oriented Library (BCOOL). As a side note... you should guess by now that IBM was fond of acronyms. The BCOOL was an attempt to first model and then build an executing set of Smalltalk objects that would reflect how IBM did business (e.g. opportunity management). We used a discovery technique invented by Ward Cunningham called CRC cards. CRC stood for Class / Responsibility / Collaboration. The analyst would sit down with a domain expert (like the customer) and usually already have a deck of CRC cards from prior sessions. Remember, OO is all about reuse. The domain expert would tell a story about what he/she wanted the system to do. Sort of like a verbal Use Case. The analyst would put cards down on the table as he/she heard nouns that were keywords. Then they would back up and see if they could tell that story by having each card (Class) use an existing responsibility to accomplish the story. If not, a new responsibility would be added and often an indication of a collaboration with another Class. For example, during opportunity management a new opportunity would be identified to sell some product to a customer. So we would take the Opportunity, Product, and Customer cards and see if they could be used for the creation of an opportunity. The analyst would say something like "I am the Opportunity, I am responsible for knowing which Product(s) i am selling". 

CRC cards were really good with smaller systems. With BCOOL we had lots and lots of cards and the session got very unwieldy. While we maintained a detailed object model in Rational Rose, we began to use the cards for something we called Major Business Components. This was the Reader's Digest of CRC. If we had discovered 1000 cobjects for our system we would ask ourselves how could we abstract that into an equivalent set of stories using only 50 MBCs. This lead us to some very interesting observations. For example, in the detailed universe (and as how it had been implemted by IBM in serveral legacy systems) there was the Lead, Opportunity, Proposal, and Contract. We created something called the Deal with different states and additional details added over time.

I eventually was promoted to be part of the OTP leadership team and went to Boulder CO for staff meetings. At one such meeting we were getting a detailed briefing on the WWSDM that was just about to be launched. As I said earlier, WWSDM was UML at its core with several additional components. Anyway... I happen to be sitting next to Ward Cunningham at the table. He does not admit it on his resume but for a short while he was an IBM employee and a member of the OTP. So I hear some mumbling to my left and look over and Ward is rolling his eyes. In a few minutes we have a break and I ask Ward what he thinks of WWSDM. He takes a napkin and begins sketching and telling me how he thinks the best way to do Software Development is to start with the programmer and figure out what needs to be done to make that individual most productive as an individual and then move up to a team of two programmers and figure out how a team of two could be made most productive. He thought that the bureaucratic nature of WWSDM was a good fit to the bureaucratic nature of IBM. I wish I had saved that "method on a napkin" as the perfect light weight method and a precursor to the Agile Manifesto

Eventually, the OTP gave up Smalltalk and learned Java. I eventually became the practice executive and we renamed our practice to be Java and Emerging Technology Services (JETS). Someone on my practice leadership team suggested we call ourselves "The next cool stuff practice" because we were always applying leading edge technologies to build applications that solve customer business problems. That aspect of the practice engagements eventually was reflected in our method. We tended to use iterative development with small teams and deep customer interaction to offset the inherent risk of using unproven products and technologies. Over a period of nine years while I was the practice executive we had approximately 2000 engagements with customers. These could range from small two day workshops up to multi-year development projects. Of these 2000 engagements approximately 100 were considered "Troubled". This meant that the project had slipped and the contract profitability was at risk and/or customer satisfaction was bad. Of these 100 Troubled projects all were eventually resolved. We never had a contract canceled due to our failure to perform. So how did we do this with emerging technologies? 

  1. The Cheese Wedge - This is an engagement model that started with inexpensive workshops and led through more elaborate engagements to a production roll out. By proceeding in steps towards this destination both the customer and IBM could make corrections to the plan and each party had natural points to make a go/nogo decision.
  2. High Customer Interaction - We tried to have customer developers and customer SMEs join the team and work with us on a daily basis. We had face to face meetings with the customer every week or two to discuss project status and tried to make corrections as soon as possible.
  3. We hired extremely talented people. Several authors have indicated that the single most significant factor in project productivity is the skills of the individual developer. Many of our projects hit snags and the team members adapted, improvised, and overcame. 

So the customer understood the inevitable  changes that were happening and saw the talented contributions of our team.

Around 2000 we moved from general Java development to specialize in Wireless Applications. While the underlying technologies were really new and cool, the software development method was still the one mentioned above.