As I briefly mentioned in my previous post, I recently flew to Chicago to attend an internal IBM Rational kick-off event. As a technical manager at IBM I lead the Software Group IT specialist team in Mexico, which includes engineers who belong to the Rational brand. Therefore I need to know in what direction the organization is moving.
As a long time software developer, Rational has always been intriguing to me. I have worked on many complex projects, sometimes alone (when that was still possible back in the 80s and early nineties) and more recently leading small teams. I started programming at age 14, and sold my first commercial application for the Apple II four years later. Being a good programmer did not help me with my first engagement as a consultant, though. Even thought I had already published three commercial applications in the U.S. at the time, that did not prepare me at all for the job. I can say with no hesitation that the project turned quickly into an absolute disaster (it was riddled with typical project management issues, which I was unable to anticipate). I learned a lot from the experience though, and have been able to avoid making the same mistakes ever since.
Rational has a great value proposition. It offers to train IT organizations in how to effectively implement a development process that should allow, in theory, to avoid most of the common pitfalls these organizations encounter daily. That process, RUP (Rational Unified Process), is the result of collecting the experience of thousands of teams who have worked on both successful and unsuccessful projects. Although, as many developers, I am personally allergic to any kind of process that stands between myself and my IDE, I have to admit that many of the failed projects that I have witnessed could have been executed successfully by implementing a decent process. I have found in particular that most programmers fail to properly garner requirements and effectively test their applications. Rational is specially strong in both disciplines and I like that.
So, if implementing a process is so beneficial why do few organizations actually do it? There are many explanations. Junior developers simply do not understand that they need to do it. Experienced developers are sometimes arrogant and think that they can live without it, not understanding that the code lives on when the application is finished and they move to other projects. Someone else will have to maintain the application and expand it. They will need proper documentation, test sets and tools to keep track of the changes. However, in my mind there is an additional reason. In many cases, those who sell methodologies too often have not written any line of actual code in years.
This is a problem as it creates a strong credibility issue. How can a Java programmer trust the recommendations of someone who does not even know the language and wrote his last COBOL application ten years ago? That happened to me when I went to my first Rational conference. I thought, well they may be right, but why should I trust them, after all they are no longer programmers. Today, I have realized that they do not have to be programmers. Their recommendations apply to any software development project, no matter what the language or the architecture is. However, I still feel that there is a strong technology gap between those who focus on methodologies and those who actually do the programming. That is why I am working on making sure that my Rational IT Specialists become fluent in Java and interact more with the WebSphere team. Credibility is key, no matter how good the service Rational sells.