Support
Nouns...A military operation (often involving new supplies of men and materiel) to strengthen a military force or aid in the performance of its mission (Example: "They called for artillery support")
The act of bearing the weight of or strengthening (Example: "He leaned against the wall for support")
Aiding the cause or policy or interests of (Example: "The president no longer had the support of his own party")
The activity of providing for or maintaining by supplying with money or necessities (Example: "His support kept the family together")
Any device that bears the weight of another thing (Example: "There was no place to attach supports for a shelf")
Supporting structure that holds up or provides a foundation (Example: "The statue stood on a marble support")
Something providing immaterial support or assistance to a person or cause or interest (Example: "The policy found little public support")
The financial means whereby one lives (Example: "He applied to the state for support")
Financial resources provided to make some project possible (Example: "The foundation provided support for the experiment")
Documentary validation (Example: "The strongest support for this view is the work of Jones")
A subordinate musical part; provides background for more important parts
Approaches
Being in support feels a bit like a David Attenborough monologue:
"Here, at the arse end of the software lifecycle, evolution has reached its pinnacle. Selection pressures are so intense, that there is no niche left into which to mutate. Exotic creatures throng and thrive in complete darkness. It is a world untouched by progress"
I've been looking for ways of dealing with the issue of support and maintenance of software in a commercial environment. This blog has considerable insight and has a colllection of very good links to other good discussions.
The key issue as I see it is that support deals with issues that have two important properties: they are business critical, and unpredictable. Any issue that has these two properties is almost certainly to be treated in a "hand-to-mouth" manner - e.g. resources are allocated to deal with the issue without significant planning. After a while of living like this, the support organisation becomes resistant to change since changing the "process" is percieved as high risk. It is not possible to change the fact that someone will be screaming down the phone when the system stops delivering business value, and it seems that conventional support processes are designed to reduce the impact of a screamer.
Another aspect of being in a support organisation is that by definition, one is always dealing with defects. This leads to a somewhat warped view of a delivered system, and a subsequent tacit hostility towards the original development organisation. This is particularly true when members of the support team are not involved in the development process. From this, one may create a hypothesis that better integration between development and support personnel would improve the "bravery" of the support process.
I haven't even begun to understand all the issues related to maintenance. I recognise that, as developer, I have placed delivering functionality (and maintainability of source code) over maintainability of the system as a whole. It is time for me to address this personal deficiency.
One of the idioms in Agile development is the phrase "If X is so good, let's do X all the time". This applies to testing, code reviews, planning, etc. Let us, as developers, now see how we can incorporate support and maintenance issues into the development process.
posted by Nick Drew @ 2:25 pm
5 Comments:
Khapre.org link has been changed to http://www.khapre.org/blog/2004/08/agile-and-iterative-software.aspx for Agile Support.
Fixed.
This comment has been removed by a blog administrator.
I'm not sure what you are getting at here. Definition of support in this sense, I'd say, is in reference to maintenance--- rather than being stood-on, demoted or being some sort of subordinate role. Talking about agile, agility is about communication. I don't see how why a critical fix has to be planned any differently from other development work in the agile environment. In XP for instance the customer is on-site (or at least a representative of the customer is) this person prioritizes the work. If the customer is screaming down the phone after the release then perhaps one of the key benifits of agile is missing: talking to the customer. This is done throughout the development to make sure the key buisness value is being delivered. Reliabilty and tolerance are buiness values. Faults may need to be tracked but that is little different from tracking stories.
I don't understand why the process must be different, unless the divisions exist in the organisation already.
I wrote this during a "Tour of duty" on a 3rd line support team, and I admit it's a bit incomprehensible, but it's meant to be slightly sardonic.
But anyway, there WERE divisions in the organisation at the time, and I was feeling the frustration at the lack of integration.
Post a Comment
<< Home