It's spring, which means that my travel has kicked in to high gear. Managing my travel schedule is perhaps the most challenging time management problem I have. I am grateful that there are so many people who want a piece of me, but currently I'm staring at a five page document that enumerates all the requests for my time and it's frightening in its scope. I could easily schedule myself to travel every week for the next two years and still not exhaust the list. That list contains all the usual places in the United States both inside and mostly outside IBM, but it also contains requests from every populated continent on earth. Don't get me wrong for I love to travel and seeing the world and the many different ways of living has been a humbling and life-expanding journey, but I have to say no more than I wish I had to.
Last week, IBM Rational hosted an executive seminar in Phoenix wherein we flew in about one hundred CTOish types from around the world and from various industries. I gave a talk on best practices in software development, which covered my usual shtick about architecture and process. A good time was had by all over the three days in the sun. This week, I just returned from Salt Lake City where I attended the DoD's Systems and Software Technology Conference and was presented with the Stevens Award.
Among other things, I had a very engaging discussion with Kelly Miller, principal director of engineering for the NSA.
Given where I am in my life and career, I have nothing left to prove and thus not only try to lead from the perspective of my world view, I'm also not timid when it comes to telling the emperor he has no clothes. To that end, I think I managed to at annoy/make uncomfortable many of the generals and program managers in the crowd. Specifically, I discussed three topics that were likely very controversial and certainly not the common group think. First, I noted that while I find architecture to be an essential element in building quality software, standards such as the DoDAF were dangerous, because when used (all to easily) improperly, they gave you the illusion you were doing architecture, without really doing any real architecture at all. I made those same comments at a lecture in Washington, DC recently, and unbeknownst to me, two of the primary authors of the DoDAF were in the crowd. Needless to say, we had a lively discussion after my talk, and suffice it to say that the ongoing work of a UML profile for DoDAF is a good thing plus I'm trying to do what I can to assist with the next instantiation of DoDAF. Second, there was some chatter at the SSTC over systems engineer and the degree to which software issues should be considered germane. I made it clear that it would be insane to deprecate any discussion of software issues, for from the perspective of all interesting contemporary systems, the software therein was essential to the functionality of that system and moreover was the source of most of that system's technical risks. Third, I made my usual observation between project success and a high CMM rating: there is only an accidental correlation. Project success in a commercial sense can be measured in capitalistic terms, namely, the return on investment; project success in a government/military sense can be measured in terms of carrying out the assigned mission in a timely, efficient, and predictable fashion. CMMI measures process maturity. These are very different things, for I've seen CMMI 5 shops that are economicallyunsuccessful and so risk aversive as to be totally lacking in innovation. From my experience, CMMI 3 is an honorable place to be, and anything more gets you into serious organizational psychological issues of number envy. It's this last topic that led to the frosty reception I received from a general who prided himself on running a CMM 5 shop. Still, I stand behind what reality tells me.