> "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..
********************************************************************
Reply by CBFalconer●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 ?
Reply by Steve at fivetrees●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 Paul E. Bennett●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 Marra●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 martinig●June 18, 20072007-06-18
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.