Summary
Sometimes, we're required to do things because "that's the way things are done around here." But interpreting corporate standards and applying subtle adaptations can yield substantial rewards.

I'm a bit confused that the law requires me to wear a seatbelt while driving my car, but not a helmet when I take my motorcycle for a ride. Though I've tried reasoning about why this might be, politics and money seem to be the major factors explaining why I must be protected from myself when driving a car, but not while operating my motorcycle. Of course, some will argue that I'm required to wear my seatbelt not to protect myself from myself, but to protect the taxpayers from supporting me should I drive my car into a wall. Interesting that I can still legally smoke should I choose to do so. In the real world, politics and money are pretty influential.

So it is with software development too. Corporate standards often dictate the process I must use and artifacts I create, managers are heavily involved with technical decisions, and committees review my work to inform me when I've deviated from the norm. I know it isn't always the most effective, but that's how it works in the real world. There are folks whose primary job function is to model, evaluate and proof tools and APIs, and develop and impose processes and standards. You can sometimes question these practices, but often times that's just "the way things are done around here." Millions may have been invested in a technology, and while it may be square, my job is to make it fit into a round hole. Certain practices and artifacts have been identified as necessary to account for the countless hours spent researching problems on past projects, and my job is to develop a product using these practices and create the required artifacts. No, I don't always have to agree with it, but I do have to accept it. So while part of what I have to do is make sure I conform, with every standard, process or technology there is always room left for interpretation and adaptation.

So...I'll rarely mention RUP or XP at work. While I find the contrasts and comparisons between these two processes fascinating, I'm generally not too interested in the emotional charge these words tend to spark. The politics of process, especially when time and money has been invested, is not something I care to partake in. I have too much other important development work to do. But I also realize that the agile practices of XP can be valuable in a more structured RUP environment, while some RUP practices can be valuable in a more agile XP environment. For instance, I've found that many new RUP adopters tend to devote a lot of their initial efforts on formulating the use case documentation. This natural tendency to invest more effort creating documentation is a side affect of their attempted move away from a waterfall mentality. In this situation, working to employ an XP style continuous integration strategy can drive the team towards a more iterative style, while avoiding some of the politics surrounding XP.

There is no one process that fits all. Each team will have its own set of strengths and weaknesses, many of which will surface at different times throughout the development lifecycle. Different teams require different practices. Avoiding the hype, and addressing the issues with proven practices will yield more favorable results than fighting through the political issues commonly associated with someone's preferred process. Ultimately, it's the practices, not the process, that makes a team successful.

Talk Back!

Have an opinion? Readers have already posted 2 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Kirk Knoernschild adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Kirk Knoernschild is a hands-on software consultant with over ten years of industry experience, and is passionate about using leading best practices to build better software. Kirk is the author Java Design: Objects, UML, and Process, published in 2002 by Addison-Wesley. He frequently contributes to various technical publications, and actively updates his personal website, www.kirkk.com, with new articles and whitepapers on a variety of software development topics. He is also the founder of www.extensiblejava.com, a growing resource of design pattern heuristics in Java.