most software jobs are software maintenance rather than new development?  
Author Message
scottf3095





PostPosted: 2005-11-11 22:56:00 Top

java-programmer, most software jobs are software maintenance rather than new development?
>> If the code were written with copious unit tests, and if they still
>> passed no matter how old the original effort, then you don't need such
>> expertise to maintain it.

>Dubious at best. Obviously you only have read well written/refactored code

I think someone can only see the world through TDD glasses :)
-Scott Frye
"aut viam inveniam aut faciam"

 
scottf3095





PostPosted: 2005-11-11 22:56:00 Top

java-programmer >> most software jobs are software maintenance rather than new development?
>> If the code were written with copious unit tests, and if they still
>> passed no matter how old the original effort, then you don't need such
>> expertise to maintain it.

>Dubious at best. Obviously you only have read well written/refactored code

I think someone can only see the world through TDD glasses :)
-Scott Frye
"aut viam inveniam aut faciam"

 
xpyttl





PostPosted: 2005-11-12 21:13:00 Top

java-programmer >> most software jobs are software maintenance rather than new development? > While many quality theories (TQM, Six Sigma) etc claim
> that the cost of lower quality is always higher than the
> cost of quality

In Six Sigma, we figure out the cost of quality, and the cost of poor
quality, and make economic decisions. This is one of the major
differences between SS and earlier quality initiatives. Although there
is plenty of statistics, Six Sigma is about "show me the money".

Based on many years of experience (I'm a really old fart), I agree that
"optimal" code is rarely optimal. You should make an appropriate
investment in the code. In today's world, that often means just barely
working. But there are situations where you want good, solid
maintainable code. It can be tough knowing the diffeence.

..

 
 
Robert C. Martin





PostPosted: 2005-11-13 3:23:00 Top

java-programmer >> most software jobs are software maintenance rather than new development? On Thu, 10 Nov 2005 22:49:24 GMT, <email***@***.com> wrote:

>
><email***@***.com> wrote in message
>news:email***@***.com...
>>
>> If the code were written with copious unit tests, and if they still
>> passed no matter how old the original effort, then you don't need such
>> expertise to maintain it. You start by adding more tests and passing
>> the existing ones, and that makes the maintenance much easier.
>>
>> In theory!
>>
>In theory. Testing is not _the_ answer. Testing is one tool in
>the creation of dependable software. As software grows, it
>becomes impossible to run enough tests to ensure that there are
>no errors.

This is true. More generally, it becomes impossible _by any practical
means_ to ensure that there are no errors. Unfortunately the
threshold size for this limit of practicality is very small.
>
>Reliance solely on testing is OK for smallish systems. However, this
>does not scale-up as the software becomes larger and more complex.

And I would say that "smallish" means "comp-sci 101 exercise". E.g.
Write a program to calculate the quadratic formula.

>Further, one can test for the errors one expects. In software there are
>likely to be a lot of errors no one could have anticipated. Those errors
>are often overlooked by the tests.

Again, this is very true, and the incidence grows with the square of
the number of features. (if not faster).

>There are many other things one must do as part of
>the software process to arrive at a point where there is some
>confidence in the final software product.

Agreed. You have to get your fingers and eyeballs on it. You have to
torture test it. You have to let a million monkeys into the room to
bang on it. You have to work hard to anticipate systematic weaknesses
and failures, and probe them all.

Each one of these things helps; and yet none are completely
sufficient. Spacecraft will still think they are on the ground when
they are 100Y up. They will still overshoot orbits because of unit
conversions. Billing systems will still send bills for negative
amounts. Telephone systems will still randomly drop you. And (though
it hasn't happened to my knowledge) airplanes will suddenly flip
upsidedown when they cross the horizon.

>This is not to say we should not test. It simply means that we
>should not be so naive as to put more faith in testing than is
>realistically warranted.

Agreed. Nothing gets rid of all the risk. All we can do is mitigate
the risk. Testing is a *big* part of that, but is not the whole
enchilada.

>It is also important to understand that more tests will not necessarily
>make the code more maintainable. It might help a little, but more
>important is the way we structure the code, organize the modules,
>and design the architecture, among other things.

It is remarkable just how much the test-first discipline helps in this
regard. The act of designing your system around tests that you write
first goes a very long way towards helping to organize and structure
the code in a maintainable way.

Again, this is not a panacea. One should not depend on test-first as
the sole source of good design and structure. But it *does* help a
lot!
-----
Robert C. Martin (Uncle Bob) | email: email***@***.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716


"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo