Methods & Tools is currently conducting a one-question poll to know What part of your software development budget is devoted to maintenance. Go to www.methodsandtools.com/dynpoll/vote.php to participate and to see intermediate results.
How important is software maintenance?
Started by ●June 18, 2007
Reply by ●June 18, 20072007-06-18
On 18 Jun, 17:41, martinig <edi...@methodsandtools.com> wrote:> Methods & Tools is currently conducting a one-question poll to know > What part of your software development budget is devoted to > maintenance. > > Go towww.methodsandtools.com/dynpoll/vote.phpto participate and to > see intermediate results.I grease my software every week and change the oil every 10,000 crashes. How on earth do you maintain software ? Compress the hard disk ?
Reply by ●June 18, 20072007-06-18
Marra wrote:> On 18 Jun, 17:41, martinig <edi...@methodsandtools.com> wrote: >> Methods & Tools is currently conducting a one-question poll to know >> What part of your software development budget is devoted to >> maintenance. >> >> Go towww.methodsandtools.com/dynpoll/vote.phpto participate and to >> see intermediate results. > > > I grease my software every week and change the oil every 10,000 > crashes. > > How on earth do you maintain software ? > > Compress the hard disk ?Software maintenance is often the continued tinkering with code that happens after the system has been delivered. It seems to be necessary in far too many systems to my mind. Mostly it is because someone has not got a handle on nailing down the specs tight enough. My own software does not need maintenance. If the requirements change after delivery it is a new project. -- ******************************************************************** Paul E. Bennett ....................<email://peb@amleth.demon.co.uk> Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/> Mob: +44 (0)7811-639972 Tel: +44 (0)1235-811095 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
Reply by ●June 18, 20072007-06-18
"Paul E. Bennett" <peb@amleth.demon.co.uk> wrote in message news:f56i80$2l$1$830fa79f@news.demon.co.uk...> Marra wrote: > >> On 18 Jun, 17:41, martinig <edi...@methodsandtools.com> wrote: >>> Methods & Tools is currently conducting a one-question poll to know >>> What part of your software development budget is devoted to >>> maintenance. >>> >>> Go towww.methodsandtools.com/dynpoll/vote.phpto participate and to >>> see intermediate results. >> >> I grease my software every week and change the oil every 10,000 >> crashes. >> >> How on earth do you maintain software ? >> >> Compress the hard disk ? > > Software maintenance is often the continued tinkering with code that > happens > after the system has been delivered. It seems to be necessary in far > too > many systems to my mind. Mostly it is because someone has not got a > handle > on nailing down the specs tight enough. > > My own software does not need maintenance. If the requirements change > after > delivery it is a new project.You're pretty lucky, then. Every once in a while I get a true "black box" project which is developed once, deployed, marketed, and never revisited. This usually means the product went nowhere, or was a one-off problem-solver for a very specific use. More often, however, I get projects which grow and develop - the market wants a new feature, or a V2 of some kind... and then I have to be able to understand and work productively on my own code, despite having perhaps long since erased and re-used those particular neurons. I have one project which has been ongoing for nearly 20 years, entirely because of new features and enhancements, usually with intervals of a couple of years between feature requests. And some people (clearly neither you nor I ;)) say "maintenance" when they really mean "bug fixing". V1 goes out in the market, and encounters some condition that was not known or recognised (or thought through) at spec time. Response times usually matter ;). Summary: software maintenance, for anything but the most trivial of applications, is vital. This really means clarity of code - which isn't that hard to do *so long as* you accept that clear code takes less time overall to develop *and maintain* than the (far too common) alternative. Unmaintainable code results in "stiffware" - code that no-one can, or wants to, maintain. This usually results in the next stage of development starting over from first principles... YMMV. Steve http://www.fivetrees.com
Reply by ●June 18, 20072007-06-18
Marra wrote:> martinig <edi...@methodsandtools.com> wrote: > >> Methods & Tools is currently conducting a one-question poll to >> know What part of your software development budget is devoted to >> maintenance. >>... snip ...> > I grease my software every week and change the oil every 10,000 > crashes.Sounds appropriate.> How on earth do you maintain software? Compress the hard disk ?Apply UPX to all executables? -- <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt> <http://www.securityfocus.com/columnists/423> <http://www.aaxnet.com/editor/edit043.html> cbfalconer at maineline dot net -- Posted via a free Usenet account from http://www.teranews.com
Reply by ●June 19, 20072007-06-19
Steve at fivetrees wrote:> "Paul E. Bennett" <peb@amleth.demon.co.uk> wrote in message > news:f56i80$2l$1$830fa79f@news.demon.co.uk...[%X]>> Software maintenance is often the continued tinkering with code that >> happens >> after the system has been delivered. It seems to be necessary in far >> too >> many systems to my mind. Mostly it is because someone has not got a >> handle >> on nailing down the specs tight enough. >> >> My own software does not need maintenance. If the requirements change >> after >> delivery it is a new project. > > You're pretty lucky, then. Every once in a while I get a true "black > box" project which is developed once, deployed, marketed, and never > revisited. This usually means the product went nowhere, or was a one-off > problem-solver for a very specific use.The type of systems I build are usually "one-off" control systems for specific, high end, applications (power stations and railways mostly). With such systems a lot of effort goes in during development to eradicate any bugs in the spec, the design and the code. Such systems have to also prove they will work to the customers satisfaction before they leave the factory. Then follows on-site commissioning to prove it works to the customers and regulatory bodies satisfaction.> More often, however, I get projects which grow and develop - the market > wants a new feature, or a V2 of some kind... and then I have to be able > to understand and work productively on my own code, despite having > perhaps long since erased and re-used those particular neurons. I have > one project which has been ongoing for nearly 20 years, entirely because > of new features and enhancements, usually with intervals of a couple of > years between feature requests.I know you and others here have a different type of embedded system where product enhancements are a continuation after the initial products are delivered. I suppose the question though is "is it really maintenance?". That question is sure to open up quite a long discussion about the definition of what is and is not maintenance.> And some people (clearly neither you nor I ;)) say "maintenance" when > they really mean "bug fixing". V1 goes out in the market, and encounters > some condition that was not known or recognised (or thought through) at > spec time. Response times usually matter ;).Not nailing down the specifications is poor practice and companies that are guilty of this really deserve to be in deep doo doo. I don't consider fixing bugs that arise out of such poor practice as maintenance but more as product rescue. Judging by the costs involved in such gargantuan efforts one wonders why anything but "software shall be written such that it requires zero maintenance" is not a standard phrase in all initial requirements documents.> Summary: software maintenance, for anything but the most trivial of > applications, is vital. This really means clarity of code - which isn't > that hard to do *so long as* you accept that clear code takes less time > overall to develop *and maintain* than the (far too common) alternative. > > Unmaintainable code results in "stiffware" - code that no-one can, or > wants to, maintain. This usually results in the next stage of > development starting over from first principles...You are marching into the re-useable code arena here Steve. Very laudable aiming to re-use as much code (from trusted library collections) as you can so long as it fits the goals of the current design. Of course more re-use of trusted components should lead to less need for bug fixing effort later.> YMMV.I know my mileage varies from yours but only because we deal in different types of product. However, I also know we have the same quality aims. -- ******************************************************************** Paul E. Bennett ....................<email://peb@amleth.demon.co.uk> Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/> Mob: +44 (0)7811-639972 Tel: +44 (0)1235-811095 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
