The Artima Developer Community
Sponsored Link

Weblogs Forum
Politics and Money

2 replies on 1 page. Most recent reply: Mar 7, 2005 10:19 AM by rusty

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 2 replies on 1 page
Kirk Knoernschild

Posts: 46
Nickname: kirkk
Registered: Feb, 2004

Politics and Money (View in Weblogs)
Posted: Jun 3, 2004 11:28 PM
Reply to this message Reply
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.
Advertisement

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.


Jason Yip

Posts: 31
Nickname: jchyip
Registered: Mar, 2003

Re: Politics and Money Posted: Jun 4, 2004 2:31 AM
Reply to this message Reply
> associated with someone's preferred process. Ultimately,
> it's the practices, not the process, that makes a team
> successful.

I wouldn't even say that it's ultimately the practices. It's ultimately the people and the practices and process will either hinder or assist the people.

rusty

Posts: 1
Nickname: rusty69
Registered: Mar, 2005

Re: Politics and Money Posted: Mar 7, 2005 10:19 AM
Reply to this message Reply
I though you were talking about Politics of Monery: http://www.politicsofmoney.com

Flat View: This topic has 2 replies on 1 page
Topic: Architecture the Accelerator Previous Topic   Next Topic Topic: Secure Application Development


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us