Life is good when a video combines an “avant-garde” cellist, references to metadata and information architecture, and an allusion to the iterative nature of technology (around 7:30 of the video).

You can follow Zoe Keating on Twitter @zoecello. She has over 350,000 followers.


The 2009 ITMPI Software Best Practices Conference

Yet another gloomy and tempestuous day here in Detroit, both methodologically and financially, with thunder and lightening in the air and the apparent bankruptcy of Chrysler finally announced. However, I’m comfortably ensconced in the MGM Grand Detroit attending this year’s Software Best Practices Conference, sponsored by the IT Metrics and Productivity Institute.

The speakers include:

  1. Bob Lawhorn, CTO of CAI, on “IT and the World Wide Manufacturing Revolution.”
  2. Ed Yourdon, author and international consultant, on “Moving Beyond SEI Level 1.”
  3. Larry Dribin, principal of The Pearl Street Group, on “What Gets Measured Gets Done.”
  4. Dan Galorath, President of Galorath, Inc., on “Sizing, Cost, Schedule, and Risk for Software: A 10 Step Process.”
  5. Bob Lawhorn again on “Transforming IT Management for Dramatic Business Success.”

It isn’t quite lunch yet, but I’ll be updating this post during the day (laptop battery permitting) with some of the speaker comments and highlights.

BTW, you can watch the webinars live here.

Update: Ok, we’re on a break, I can share a few of the nuggets so far.

“Moving Beyond SEI Level 1,” by Ed Yourdon.

  1. Generally, things have improved within the software development space from a quality and productive standpoint in the last 15-20 years when you review the SEI CMM data.
  2. Process maturity = quality + productivity.
  3. In 2003, 60-80% of all SEI Level 5 companies were in India.
  4. “There is not enough pressure to change” when it comes to improving software (itself) or process.
  5. Ed presented an interesting list of “barriers to improvement.” The bottom line is that the same barriers that have existed for decades. My two favorites were:
    • Sturgeon’s Law: Ninety percent of everything is trash.
    • “Software is a human effort — and people are still the same.”

This last point is certainly in harmony with my own beliefs. Software is a human effort, and this point can’t be underestimated when you are planning and executing a software development effort that requires more than one person to complete.

Mr. Yourdon also pointed out a few of his blog posts that you may find of interest related to these barriers to improvement: November 9th, 2006, and November 19th, 2006.

“What Gets Measured Gets Done!” by Larry Dribin.

Larry’s presentation highlighted a number of challenges and opportunities within the metrics and measurement space. His comments had a patriotic flavor and he indicated a few times that the US has work to do in order to be able to compete successfully with other countries who have focused more on quality than we have. He mentioned a specific example in which a project was developed by two teams, one in the US and one in India. Apparently, of the nearly 1500 bugs that were uncovered during the testing phase, over 1400 of them were produced by the US team. His main comment was, “Indian software firms publish their defect density on their home page. If you don’t know yours, how can you compete?”

He also referenced the work that 37 Signals has done in the “making things smaller” space, which is directly correlated to the fail fast concept. This mention of 37 Signals reminded me, for the second time this week, of the fantastic book Dreaming in Code, by Scott Rosenburg.

The ninth chapter of this book, simply titled “Methods” (click here for the endnotes) reads like a short summary of software development methodologies over the last 30 years, and I believe it actually foreshadows what software development will look and feel like in the future: very simple, very small, and very productive. I can’t remember who borrowed my copy of the book so I can’t look up the details at this moment (I will update this post later if I find it and it changes my memory), but in essence he points out that smaller teams are more effective and productive (like 37 Signals) and that even this fact may suggest what the next phase of software development methodologies will become post-agile (somewhat like The Agile Cloud I’ve mentioned before). Definitely worth the read, both for this informative chapter and the wonderful world of start-up companies that the book covers.

“Sizing, Cost, Schedule, and Risk for Software: A 10 Step Process,” by Dan Galorath.

Dan talked about the importance of determining what to measure when it comes to metrics as well as one of my favorite topics, estimates. He advised getting at least three estimates (best case, likely, and worse case) and told a number of interesting stories about the process and importance of estimation that certainly rang true with my own experiences (this is no surprise given Dan’s expertise on this topic). His talk included a fantastic set of graphs; the one I found most interesting focused on the optimal staffing model for a project. I’ll pass along a link as soon as I find it.

Dan also alluded to the importance of baselining your projects either against your own data (over time) or against publicly available data, like that from ISBSG. Obviously, the extent to which you want to take this sort of optimization effort needs to be scaled to your business model and needs, but being able to articulate the effectiveness of your internal process either over time or against the backdrop of industry data is a powerful corporate capability.

“Transforming IT Management for Dramatic Business Success,” by Bob Lawhorn.

Bob spoke at length regarding “the transformational journey” needed to improve software management:

  1. Standard Processes
  2. Managing with Metrics
  3. Automation

He made a number of interesting comments, my favorites of which were:

  • We need to develop a way to bring new members into a team so that they can be safe and learn effectively by learning from their mistakes.
  • You have an ineffective process if your mistakes are not found within the team that creates them, as it diminishes the effectiveness of a reliable feedback loop.
  • Executives and the friends of developers are the two largest sources of black market (out of scope) activities.
  • Rework is one of the areas that has the greatest opportunity for the reduction and removal of waste, and therefore for the improvement of productivity.

Overall, it was an enjoyable day of presentations by a very esteemed group of software and IT leaders. It was not even dampened by my losing $8 on the quarter slots on the way to the parking deck.

The only disappointment to me was that nearly all of the speakers made what I would call gently critical comments regarding the agile software development movement at some point in their speeches. This may actually have been predictable given that, in general, agile is not overly focused on metrics and measurement with respect to productivity but instead on collaboration, working software, and responding to change. I don’t believe that these are mutually exclusive worlds — my last agile shop could generate fantastic metrics regarding historical estimates, backlogs, and time dedicated to canceled features because we had the systems and processes in place to capture this data — but I would agree that there isn’t as much science in this aspect of software development in the agile world as there is in the waterfall one. There may be an opportunity for an effort to begin tracking data regarding agile projects and their associated metrics in order to fill this void.

Regardless, companies like 37 Signals may have the final word on productivity and quality if their success is any indication.

Agile Software Development and Fail Fast

I haven’t yet done a good job of describing the fail fast model with my thoughts on agile software development in this blog. Blogs feel more like streams-of-consciousness than articulated, structured documents. While I get my arms around how best to tell the fail fast story as I have experienced it through time, I thought it would be helpful to provide a bit more background on the topic by posting a copy of my Agile 2008 whitepaper, “The Big Projects Always Fail: Taking an Enterprise Agile.” You can now read it here; I would love to hear your thoughts and comments.

In Celebration of the Montreal Bagel

It the final years of the last century, I was amazingly fortunate to be working at Detroit Edison / DTE Energy when the transformation from “an Oracle shop” to “a Java shop” was being implemented. DTE’s CIO had the connections and insight to bring a wonderful group of people from the outside world in to mentor those of us on the inside, people who, a decade later, I still like to keep in touch with (Mr. Tibbetts, Mr. LeJacq, Mr. Meyer, etc.).

One of these wonderful people was Mr. Boutros, who flew in from his home in Montreal every Monday morning and back every Thursday night, if memory serves. I definitely remember the Monday mornings because that was when Stephane introduced us to Montreal bagels. As a native Michigander who had worked primarily in downtown Detroit until that point in my career, I had never even known that a Montreal bagel existed. Steph would bring in bags full of these bagels, which had been baked that morning at Beaubien Bagel (he picked them up at 5am), flown down to Windsor, and then trucked over the the border in the Tunnel Bus to DTE’s HQ. They were well-traveled bagels.

More importantly, they were fantastic. Sesame-seeded with a bigger-than-normal hole, they resembled an oval salt pretzel, but were sweet and denser. Fresh bagels were fantastic right out of the bag, and the development team would hail Steph and start devouring handfuls of bagels and cupfuls of the French press coffee we made every hour. (I guess, looking back, we were a high-maintenance technology team.) Whatever we didn’t eat that day were fantastic the next, toasted with cream cheese. These bagels have been favorites of mine ever since, and certainly their place in my gastronomic memory and heart was concretized by the unique person who introduced them to me.

I have gone to great lengths to get to a Montreal bagel since then. A few years ago, my wife and I went to Montreal to celebrate one of our wedding anniversaries. We stayed at the charming Auberge de La Fontaine, which I recommend for its location, comfort, and, naturally, the fact that they serve Montreal bagels for breakfast.

Others have also gone to great lengths to acquire them for me. The two oldest and most popular Montreal bagel bakeries are Fairmount and St-Viateur. Until recently, neither of them shipped to the US, unfortunately, so I had to hire a few gentlemen from Canada (Mr. Purdie and Mr. Tontodonati know who they are) and then have the bagels shipped to their homes so they could bring them to me, good men and great friends that they are.

Finally, at least one of these bakeries is now shipping directly to the US. It is not inexpensive — it looks as though the shipping is just as much as the bagels themselves — but they are certainly worth it.

I was never very good at geography, but I have learned that the heart and the stomach have a good memory for places. You heart knows where home is, where it was broken, where it has soared. Your stomach remembers where it has eaten well, whether it was breakfast in Traverse City at The Omelette Shoppe, the world’s best cafe mocha in Ann Arbor at Espresso Royale, a traditional Coney Island miracle at Detroit’s American Coney Island, or what I believe to be the best bagels in the world.

The Layered Cloud

I’ve mentioned the agile and personal cloud in previous posts, and, like most architectural / patterny folks, I’ve started thinking about the cloud in layers (whatever the proper meteorological term for cloud layering is — it may really just be “cloud layers“). They are:

  1. The Personal Cloud
  2. The Services Cloud
  3. The Platform Cloud
  4. The Agile Cloud

I need to think a bit more about how to draw that layered picture — and your help is certainly welcome — but I think they do build on each other and have some inter-relationships as well. I will write more about the two middle clouds soon, but in the meantime the folks over at Perficient have posted the presentations from their cloud event a few weeks ago. You can check them out here.

The Personal Cloud

With all this talk of cloud computing at an enterprise level, it is easy to forget the much more powerful cloud that you are probably taking advantage of all day long. You get your email through any HTTP device thanks to Gmail, AOL, Yahoo, MSN, etc. Like apparently the rest of the world, I’ve latched on to Gmail — it is very reliable (despite its “beta” status), it has the cool conversation threading functionality that I hated at first but that now feels more natural than my Outlook inbox’s approach, and the BlackBerry interface is great, ensuring that I’m never far from email, despite my wife’s distaste of that same closeness. I sent my first Gmail email on August 31st, 2004, and, over four years of casual usage later, I’m still “currently using 258 MB (3%) of your 7305 MB.” Wow. Obviously, there are plenty of other email providers, but Google seems to have gotten it mostly right with fairly unintrusive advertising, solid if not perfect spam control, and a nice filtering capability that is a good way to label your mail.

Of course, there is no such thing as social networking without the cloud, and little is more personal. The MySpace phenomenon seems to have faded, at least in my circle of friends and colleagues, in favor of the wow-this-is-big wave of Facebook. Soon, you might not be perceived to exist if you aren’t on Facebook: “I’ve updated my status, therefore I am.” The natural extension of Facebook to the mobile devices of the times only makes it more powerful and ubiquitous.

(Though it doesn’t have much to do with the cloud, I do need to take a quick detour while we’re on Facebook: I’m continually amazed how it makes some connections that were previously difficult or impossible so much more straightforward. As an example, the other night my wife and I were at the Wings game. Maybe 20 rows away there was a guy my wife thought was someone we had gone to school with. I disagreed — it just didn’t seem like it was him, even though I hadn’t seen him in two decades. So, we logged into her Facebook account to check his status. You can guess it: “enjoying the Wings game tonight!” Bingo: a connection. LinkedIn is doing the same thing at the office, with its own set of connections and groups. It will be interesting to see how these worlds intersect, or if they do. Today, there is a pretty clear distinction — LinkedIn is clearly your professional profile, filled with certifications and professional  updates and work-related statuses, while Facebook is all about your dinner with friends, carting the kids around, or your clearly personal opinion of the world — which, if carelessly utilized, already can negatively intersect with the LinkedIn world by getting you fired.)

Of course, not everything is email and social networking. You still have to create documents and spreadsheets. At the risk of sounding like a Google fanboy, Google Docs does seem to have an advantage here (though I think Buzzword has a much more elegant interface for documents). We’ve used both the documents and spreadsheet capabilities at work and, particularly for collaborating, they are truly powerful tools, cloud or no cloud. Have everyone get into a shared spreadsheet (sort of fun if you are all in the same conference room, too, but not required) and start editing. It is wild the first time you see where everyone else “is” in the spreadsheet — sort of like a bizarre game of Battleship — and realize how easy it is to collectively edit and add to the information. Much more effective than a shared Excel spreadsheet on a network drive — and cheaper. Same effect for documents, and the freedom from 980 Track Changes versions flying around via email feels about as liberating as the first time you realized you could carry around your music library as digital files on your iPod rather than lugging your Discman and CDs everywhere. Well, alright, maybe it isn’t that cool, but it is liberating.

So, were in good shape. We’ve got email, our social network, our documents and spreadsheets, and instant messaging (a longstanding killer cloud app) all in our personal cloud. We can work everywhere we have a browser, a connection, and a few user names and passwords. Whoops. One second. We do need some music. Cannot work without music. Your iTunes library is pretty portable as long as you didn’t forget your iPod, but Apple really needs to make it available to you wherever you are for it to be a better cloud experience. In the meantime, Pandora is my current favorite for cloud music. Tell it the sorts or artists you like and it constructs a personal internet radio station, and you can rate the songs they select so that it continuously improves to match your preferences. The best feature is that it won’t be long before it recommends a song you like from an artist you’ve probably never heard of. And like anything in the cloud — status, documents, or email — it is really easy to share — here’s mine.

For files that don’t have a good cloud home yet. a good friend of mine recently introduced me to Dropbox, which is very handy as well. I typically work on at least three or four computers a day, and having a place to store documents or files I would like to get to from many different machines is wonderful. It feels sort of like a personal Subversion repository in the cloud, and their introductory email image (below) certainly makes reference to that angle of their service.

Finally, it would obviously be rude of me to not talk about WordPress. Here I am, running Ubuntu, in Firefox, riding a “free” connection thanks to my coffee purchase at Panera, blogging away, with little to no configuration. Wonderful stuff, perfectly personal, completely free.

I have to say I love the power of this personal cloud. Are you doing anything interesting with yours?