most software jobs are software maintenance rather than new development?

[Andrew McDonagh]

I don't understand this? There exists programs that don't use not even
single
design pattern? I didn't mean the Design Patterns.

I don't understand it either.....

Well yes design patterns are the Design Patterns, sometimes not.

.....you have gone a bit to Zen for me.


snipped

 

[Robert C. Martin]

Greenfield vs legacy? Imagine if all else was equal...

The trick to any software project is to keep the field green. Fields
turn brown for lack of care. A well tended field will remain green
for as long as it remains well tended. Brown spots in the field
indicate carelessness.

What would I rather work on? It happens to be my chosen profession to
help people turn their brown fields green again, and keep them green.



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

 

[Phlip]

The trick to any software project is to keep the field green. Fields
turn brown for lack of care. A well tended field will remain green
for as long as it remains well tended. Brown spots in the field
indicate carelessness.

What would I rather work on? It happens to be my chosen profession to
help people turn their brown fields green again, and keep them green.

The distinction between you and the original poster is..

http://c2.com/cgi/wiki?TransformationEconomy

The OP currently works at the Service level; cleaning up code. They aspire
to the "Experience" tier on the economic scale. The OP wants to create the
"look and feel" of a program's internal API, hopefully to provide a better
experience for its maintainers.

Your is the "Transformation" level. You provide a series of Experiences that
transform teams. Not just their code.

(At least I suspect you do. I'm just going by these here posts

 

[David Lightstone]

The trick to any software project is to keep the field green. Fields
turn brown for lack of care. A well tended field will remain green
for as long as it remains well tended. Brown spots in the field
indicate carelessness.

What would I rather work on? It happens to be my chosen profession to
help people turn their brown fields green again, and keep them green.

Nice metaphor/analogy/whatever where does laying down bull shit fit it.
Excessive brown nosing and marketing perhaps?

 

[Patrick May]

The trick to any software project is to keep the field green.
Fields turn brown for lack of care. A well tended field will
remain green for as long as it remains well tended. Brown spots
in the field indicate carelessness.

[ . . . ]
Nice metaphor/analogy/whatever where does laying down bull shit fit
it. Excessive brown nosing and marketing perhaps?

Fertilizer, of course! The business champion has to prepare the
field and keep the nutrients coming.

I much prefer gardening as an analogy for software development,
rather than that of an assembly line.

Regards,

Patrick

 

[Mark McIntyre]

The trick to any software project is to keep the field green.

This is trite nonsense. Continuing the metaphor: as soon as you start
to build on the field, you have brown bits. Nothing you can do to stop
that.

Fields turn brown for lack of care.

They turn brown because you build something. Keep it green by never
actually developing any code...

 

[Phlip]

This is trite nonsense. Continuing the metaphor: as soon as you start
to build on the field, you have brown bits. Nothing you can do to stop
that.

I only get that problem when I allow any of my code to decay, even just a
little. If it has no tests, if it's crufty, it goes brown rapidly. If I keep
adding clean tests, and keep cleaning the code, the code's quality remains
high, and new features get easier to add than the old ones were.

They turn brown because you build something. Keep it green by never
actually developing any code...

If you write the code without maintaining it, as it grows, it will grow
tangled, like wild untrimmed gardens. Alternate growth with sessions of
pruning and trimming, and you will remove the weeds, dead twigs, and
suckers. The result is only long branches supporting healthy leaves turned
to the sun.

 

[Richard Bos]

If you write the code without maintaining it, as it grows, it will grow
tangled, like wild untrimmed gardens. Alternate growth with sessions of
pruning and trimming, and you will remove the weeds, dead twigs, and
suckers. The result is only long branches supporting healthy leaves turned
to the sun.

It is never a good idea to take metaphors more seriously than reality.
That way lies Microsoft Bob.

Richard

 

[Guest]

What would I rather work on? It happens to be my chosen profession to
help people turn their brown fields green again, and keep them green.

A good point. The real heros in a software organization are not those
who write code for new systems. Instead, they are those who are able
to keep current systems current, extend current systems with new capability
while not breaking them, and solve problems created by those who originally
coded those systems.

There is a reason why we put new programmers into maintenance jobs. It is
largely about apprenticeship. Rare is the recent computer science graduate
who has the skill, the knowledge, and the experience necessary for building
good software from scratch. Rarer still is the a manager to take that kind of
risk.

Consider someone who has graduated from medical school, served one
or two years as an intern, and thinks himself ready to do open-heart surgery.
Do you want that person as your surgeon? Software is no different. In
our modern world, software flies our aircraft, operates our cardiac care
units, and controls the switching systems on our rail transportation facilities.
No development method, no amount of theoretical foundations, no experience
writing toy programs for an academic environment, and no overblown sense
of self-confidence will compensate for the skills acquired over a longer
period of time; skills developed actually writing and maintaining such software.
Too many things can go wrong, and even the most aware novice is probably
not ready to understand what s/he does not understand.

On the other hand, those old-timers are no good unless they keep their
own knowledge up-to-date. Some of them, instead of having ten
years experience, have "one year of experience, ten times." It is important
to listen to the newcomers, those with fresh bachelor's and master's degrees
because they do have something to offer. Further, they will eventually take
over when we are out to pasture.

Richard Riehle

 

[Guest]

I much prefer gardening as an analogy for software development,
rather than that of an assembly line.

.... and can you cite the source of that notion? It has been around for a
while.

Richard Riehle

 

[Guest]

I bugs me that languages don't seem to take maintenance into
consideration in design. The needs of maintenance programmers are
very low on the totem pole. The needs of the compiler writer trump
those of the package writer trump those of the application code trump
those of the maintenance programmer.

One of the key design goals of Ada was to enhance maintainability.

If 80% of the life of a program in maintenance, 80% of maintainance
is often devoted to trying to understand what to maintain. Popular
languages such as C++ are horrible for creating maintainable code.
Java, while a little better, is not that much better.

A language that stresses readability and understandability over writeability
is not likely to be popular with "greenfield" programmers. They often just
want to get the code laid down so they can get on to the next project.

So, if you want improved maintainability, one of your first steps is to choose
tools that support that goal. Ultimately, your maintenance programmers will
love you for that choice while those writing new code will grumble. Those
new code programmers represent a smaller part of your problem and they
are the easiest to replace.

Richard Riehle

 

[Roedy Green]

... and can you cite the source of that notion? It has been around for a
while.

I suppose Kent Beck in the main proponent of that view, constant
refactoring to keep the weeds at bay.

 

[Patrick May]

... and can you cite the source of that notion? It has been around
for a while.

Off the top of my head I was going to say that I first saw it in
something that Robert Martin wrote, but a quick Google shows that
Steve Mellor used a Japanese Garden as an architecture analogy in this
newsgroup back in late 1995. I don't know if he was the first,
though.

Regards,

Patrick

 

[Guest]

So... in at least some organizations, you get to the top faster by
being good at maintenance than you do by being indifferent at
maintenance but good at creating new work by yourself.

I always placed high value on programmers who could solve
difficult problems. In software those problems are often
created by other programmers. When you can read and
understand someone else's program, fix it, extend it, improve
it, or solve the otherwise intractable problems left behind by
the person who wrote it, you will be a valuable member of
the team -- maybe more valuable than someone who knows
only how to write "perfect" code.

Richard Riehle

 

[Roedy Green]

I always placed high value on programmers who could solve
difficult problems. In software those problems are often
created by other programmers. When you can read and
understand someone else's program, fix it, extend it, improve
it, or solve the otherwise intractable problems left behind by
the person who wrote it, you will be a valuable member of
the team -- maybe more valuable than someone who knows
only how to write "perfect" code

An analogy. Whose skill is more impressive. A top flight mechanic, or
a top flight mechanic who can do his repairs while the car is racing
at 140 MPH

 

[Benji]

An analogy. Whose skill is more impressive. A top flight mechanic, or
a top flight mechanic who can do his repairs while the car is racing
at 140 MPH

What kind of cars are we talking about, exactly? Is this the jetsons? If
not, I don't think this is a very good analogy.

 

[David Lightstone]

An analogy. Whose skill is more impressive. A top flight mechanic, or
a top flight mechanic who can do his repairs while the car is racing
at 140 MPH
--

There is a difference between skill and fantasy.

 

[Guest]

the more languages you know, the faster you can pick up on a new one.
All you need to focus on are the surface syntax differences and the
totally unique features.

In some respects this is true. However, some languages are radically
different and not that easy to learn unless you abandon much of what
you know about other languages. This does not make them bad
languages. In fact, some of the best languages that are are quite
different from the C family.

Eiffel does not look like other languages and to use it correctly, you
need to unlearn much of the silliness that you were required to know
to program in C++. Functional languages such as ML, OCAML,
and LISP, are different enough that you can easily make the mistake
of trying to program in them the way you program imperative languages.
Smalltalk, one of the languages that is fun to program in (more so than
Java, C++, or most other curly-brace languages), requires a completely
different approach to design and coding. One of my personal favorites,
besides Smalltalk, is Ada, and that language is structurally and philosophically
different from some of the more popular languages.

It is all too easy to think you understand a new language when you are new
to it and think the same way you did with some other language.

Richard Riehle

 

[ecky-l]

The older a system gets, the more skill is required to maintain it.

Thus, it makes little sense to me to put new people into a maintenance
role unless they are being mentored by very experienced people.

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


Eckhard

 

[Roedy Green]

In some respects this is true. However, some languages are radically
different and not that easy to learn unless you abandon much of what
you know about other languages. This does not make them bad
languages. In fact, some of the best languages that are are quite
different from the C family.

That effect certainly slowed me down in learning Java, not realising
how different it was despite the similar syntax.

On the other hand I know assemblers very well. I know what any
feature in the language has to eventually boil down to machine code.
In a pinch I can look at generated code to figure out what some
language construct does. I could not do that when I was a language
virgin. Even looking at JVM byte code has helped me understand Java.