j e s r u s h . c o m

Jason Hiner has a fascinating article at TechRepublic arguing that Google’s approach to software development is fundamentally incompatible with enterprise business requirements:

Google’s organization and corporate culture are radically decentralized. There’s not a lot of structure, process, or bureaucracy. The focus is on innovation and freelance creativity. That can make it a great place to work if you’re an engineer and it makes Google great at building Internet widgets and exciting new features for its search platform.

[. . .]

However, when IT departments do mass deployments of applications for business-critical tasks, they expect a high level of service. They expect the software to be bug-free, and if they do run into problems then they expect to be able to quickly connect with a customer support representative to resolve any issues immediately, if not sooner.

In order to pull off this type of experience that corporate IT demands, a software maker needs excellent attention to detail, strong processes and systems in place, and software that is “good enough” to provide a seamless experience for users. Again, delivering fully-packaged, mostly-bullet-proof software is not part of Google’s DNA.

Jason makes some interesting points here and on some level — I follow his reasoning. On the other hand, Google Apps has been a pretty big success by most accounts. Perhaps Google is a little more organized/process-driven than we’re giving them credit for?

My wife and I recently went to Italy and spent a lot of time studying the life and work of Michaelangelo. For a legendary genius, his day-to-day life was surprisingly tumultuous. If you thought he quietly tolled away on the world’s greatest art without interruption, you would be in for a big surprise. In fact, the process of decorating the Sistine Chapel was so crazy, that it immediately reminded me of wild and unruly software projects. Which in turn, got me thinking about some of the good (and bad) moves which Michaelangelo–chief engineer–made.

• Estimate? One year. When Pope Julius asked Michaelangelo to decorate the Sistine Chapel, the great genius estimated that it would take him no more than a year to complete the project. When all was finally said and done, four and a half years had transpired. And this was without any beta releases. What happened?
  
  It seems a perfect storm of factors converged to slow the project: There were political fights, there was miswork which had to be re-done, there were structural and weather problems in the chapel, and all variety of other complications. But the factor that struck me most strongly? Michaelangelo made the estimate himself at the beginning of the project before building his team of painter-assistants. At that time, he had not done frescoing in nearly twenty years (his focus had been on sculpture). In other words, he made a wild top-down estimate in an area outside his expertise without consulting the people who would actually be executing the work packages (his team). Sound familiar?

• Minimize your footprint. Renaissance artists had customers just like the rest of us, only they were called patrons. Patrons (be they the Pope or simply a rich businessman) would specify exactly what they wanted in the art which they were paying for… the number of figures… the scene, etc. Nonetheless, the artist would constantly make little, unplanned decisions about how the scene unfolds. Will that person in the crowd be a man or a woman? Young or old? Will they be smiling or frowning? What will they wear? Unfortunately many Renaissance artists (not Michaelangelo) were an egotistic bunch. They would do things like paint themselves side-by-side with the wise men in the nativity scene, or amidst the apostles in the resurrection scene. They look ridiculous, and one can only imagine what their patrons thought.
  
  When building software, you are constantly making the same kind of little, unplanned decisions about how the application will function. Should I display the customer name with their last name first? Should the input box be freetype or should I force selection from a drop-down list? These seemingly inconsequential decisions add up over time into a huge body of collective decisions that are often made with little customer consultation. This is the developer footprint. The bigger it is, the more likely something about it will irritate the customer. Where many renaissance artists had the audacity to paint themselves into scenes side-by-side with the apostles (a big footprint), Michaelangelo rarely painted himself and when he did it was in the most humble of places. In the Last Judgement, Michalangelo painted his face on the dead skin of a skinned martyr (Bartholomew). It was so subtle, that art historians didn’t even notice the portrait for hundreds of years!

• Start in the back. As mentioned earlier, Michaelangelo had not done frescoes for twenty years when he was commissioned to paint the Sistine chapel. With this in mind, he made a key decision: He started painting from the back of the sistine chapel first so that he could improve his technique by the time he got to the front. Indeed, there are obvious differences between the frescoes up front and those in the back. When one enters the chapel from the rear door–the eyes naturally see his best work in the front first.
  
  This reminds me of an agile development trap. With agile, the tendency is to build important, core functionality in the early iterations so that you’ve gotten something worthwhile accomplished if time or money unexpectedly runs out later. This is a wise tendency, however you usually don’t want to do the most important work in the first phase. Critical work should be done when the team is hitting stride, not when they are forming/storming. Michaelangelo nailed this.

I was on construx’s website the other day (Construx does software development best practices, seminars, consulting, etc.) and stumbled on a real nugget: Their career progression ladder for software project managers. For the life of me, I can’t re-find the page (perhaps it was pulled?), but fortunately I had saved the info to google notebook.

The ladder describes three “levels” of career progression and each level has three components: experiences (such as estimating a project), reading material, and training (mostly Construx seminars–which sound really good).

Given how much I love reading, it was (surprise!) the reading lists which really interested me:

Level 10

• Code Complete, Steve McConnell
• Rapid Development, Steve McConnell
• Software Project Survival Guide, Steve McConnell
• UML Distilled, Martin Fowler et all
• Mastering the Requirements Process, Robertson and Robertson
• Software Requirements, Karl Wiegers
• “Manager’s Handbook for Software Development”, NASA Goddard Space Flight Center

Level 11

• Principles of Software Engineering Management, Tom Gilb
• Mythical Man-Month, Fred Brooks
• Peopleware, Tom DeMarco and Tim Lister
• Measures for Excellence, Lawrence Putnam and Ware Myers
• The Art of Software Testing, Glenford Myers
• “Software Measurement Guidebook”, NASA Goddard Space Flight Center

Level 12

• Programming Pearls 2nd Ed, Jon Bentley
• Applying UML & Patterns 2nd Ed, Craig Larman
• Conceptual Blockbusting, James Adams
• Software Creativity, Robert Class
• Quality is Free, Philip Crosby
• The Deming Management Model, Mary Walton
• Managing the Software Process, Watts Humphrey
• Writing Effective Use Cases, Cockburn
• Exploring Requirements: Quality before Design, Gause and Weinberg
• Requirements Engineering, A Good Practice Guide, Sommerville and Sawyer

This is a killer list. The only thing missing is more coverage of risk management (!). But that omission aside, I’ve tackled about half of these and can attest to their value. Good stuff!