most software jobs are software maintenance rather than new development?

[David Lightstone]

I think, maintaining an "old" system (old means probably "stable" and
"reliable", doesn't it ) is a good opportunity to get accomplished
with the code and learn how experienced people did it. Everyone should
go through this, before (s)he starts to develop new code, IMHO...

What I state may sound flippant ot silly, but it is correct.

Yes, once you know all the mistakes that can be made you actually can start
writting good code.

 

[Robert M. Gary]

I would say that it is exceedingly rare to write code from pure
scratch. I work on a code base that is several million lines long for a
large technology company. When we come out with new product, it is an
extention to the existing code base. I think it often becomes very hard
to define "new code" vs. "enhacement". At some point, its hard to tell
what is what. Would you consider writing a J2EE application "new code"
even though you are using an existing infrastructure? Most people would
say yes, I would therefore argue that "enhancements" to existing code
is not much different.

-Robert

 

[Robert M. Gary]

Maintenance is much harder. I spent the first 5 years of my carrer
working in "Current Product Engineering" for a major telco software
provider. That was much harder than creating new code because you had
to figure out what someone else (who had long since left) was trying to
do. You also had to follow the existing coding style since mixing
styles causes a huge mess. Most employeers look for people with real
maintenance experience for a couple reasons...
1) It shows you can understand other's code and can incorporate your
own stuff into it and
2) You have a better appreciation for the importance of good error
messaging and stable code. You never learn to write really solid code
until you've spent several years fixing other people's code.

-Robert

 

[Phlip]

Maintenance is much harder. I spent the first 5 years of my carrer
working in "Current Product Engineering" for a major telco software
provider. That was much harder than creating new code because you had
to figure out what someone else (who had long since left) was trying to
do. You also had to follow the existing coding style since mixing
styles causes a huge mess. Most employeers look for people with real
maintenance experience for a couple reasons...
1) It shows you can understand other's code and can incorporate your
own stuff into it and
2) You have a better appreciation for the importance of good error
messaging and stable code. You never learn to write really solid code
until you've spent several years fixing other people's code.

These are all rich arguments for aspects of a poor situation: Throwing good
money after bad.

I would say that it is exceedingly rare to write code from pure
scratch. I work on a code base that is several million lines long for a
large technology company.

What's its ratio of unit tests to production code?

 

[Robert M. Gary]

These are all rich arguments for aspects of a poor situation: Throwing good

money after bad.

Huh? Hiring programmers with maintenance experience is throwing good
money after bad? I guess I'm really not following.

 

[phlip2005]

Huh? Hiring programmers with maintenance experience is throwing good
money after bad? I guess I'm really not following.

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!

 

[David Lightstone]

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

 

[Robert M. Gary]

Ok, I'm going to put on my MBA hat (don't worry, my undergrad is in
Computer Science ) I think there is an arguable cost/benefit analysis
that says it may not always be optimal to write such solid code, as you
describe. While many quality theories (TQM, Six Sigma) etc claim that
the cost of lower quality is always higher than the cost of quality, I
think a more reasonable business view would say that is not always the
case. As a development organization you need to look at what your
Sales/Revenue limiters are. If quality is what is limiting you, than
tools such as Six Sigma, unit testing, etc are vehicles to use. Often
though, development organizations decide that they have other, higher
priority inhibitors. Time to market is probably the most common,
minimal resource, is another. If you need to increase your performance
in Time to Market, than you need to take less time with unit testing,
etc. In other words, there are a lot of variance in the extend to which
you invest in high quality, not all result in better business rewards.
In the RND shop I work in we do a far amount of documentation, we do
peer code reviews and peer project reviews, but do unit testing an a
per-project basis. Some projects are so integrated that unit testing is
not a big "bag for buck" and functional testing is more beneficial.
About 20% of what I work on is simply to develop Intellectual Property.
Some of that code needs to work well enough to generate my Patent, I
don't list my unit tests in the Patent.

Anyway, my 2cents.

-Robert

 

[Guest]

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.

Reliance solely on testing is OK for smallish systems. However, this
does not scale-up as the software becomes larger and more complex.
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.

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.

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.

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.

Richard Riehle

 

[scottf3095]

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]

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]

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: (e-mail address removed)
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