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
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.