Software Engineering - most software jobs are software maintenance rather than new development?

Author

most software jobs are software maintenance rather than new development?

apngss@yahoo.com

2005-10-20, 7:56 am

This topic should apply to software jobs regardless of the programming
languages.

I want to know if most of the software jobs in the market are software
maintenance (fix bugs, new feature enhancements on existing code)
rather than new developments (from scratch). This is my first job as a
Java programmer, but I really don't see I do much Java development, all
I do is to fix bugs, and add some new features for new builds. Well, of
course I need to understand the logic of existing code, but my
standpoint is that even I don't know Java well, I still can do the
work.

Is that normal in my case? Or I am just unlucky...

Please advise. thanks!!

John Harrison

2005-10-20, 7:56 am

Andrew Thompson

2005-10-20, 7:56 am

apngss@yahoo.com wrote:

> Is that normal in my case? Or I am just unlucky...

To have work? No.

Perhaps you are undeserving, ungrateful and extremely
self-centered*, but unlucky? No.

* To think your problem is so important that it justifies
cross-posting to such a wide range of groups.

Now GET BACK TO WORK.

Ross Bamford

2005-10-20, 7:56 am

On Thu, 20 Oct 2005 08:13:48 +0100, <apngss@yahoo.com> wrote:

> This topic should apply to software jobs regardless of the programming
> languages.
>
> I want to know if most of the software jobs in the market are software
> maintenance (fix bugs, new feature enhancements on existing code)
> rather than new developments (from scratch). This is my first job as a
> Java programmer, but I really don't see I do much Java development, all
> I do is to fix bugs, and add some new features for new builds. Well, of
> course I need to understand the logic of existing code, but my
> standpoint is that even I don't know Java well, I still can do the
> work.
>
> Is that normal in my case? Or I am just unlucky...
>
> Please advise. thanks!!
>

It's normal. It's something of a privilege to work on a new project, and
especially when you're new you'll tend to get stuck on the fixing jobs,
simply because there are usually more fixes to be done.

--
Ross Bamford - rosco@roscopeco.remove.co.uk

xpyttl

2005-10-20, 7:56 am

There probably is a lot more maintenance going on than new construction.

But I would hope that most shops would expect new programmers to do a fair
bit of maintenance before they do new development. Its pretty easy to
design

new stuff without any consideration for what it costs to own
that code. If you spend some time getting beat up by other people's
mistakes, you are less likely to make those mistakes on your own.

...

<apngss@yahoo.com> wrote in message
news:1129792428.032878.177440@g47g2000cwa.googlegroups.com...
> This topic should apply to software jobs regardless of the programming
> languages.
>
> I want to know if most of the software jobs in the market are software
> maintenance (fix bugs, new feature enhancements on existing code)
> rather than new developments (from scratch). This is my first job as a
> Java programmer, but I really don't see I do much Java development, all
> I do is to fix bugs, and add some new features for new builds. Well, of
> course I need to understand the logic of existing code, but my
> standpoint is that even I don't know Java well, I still can do the
> work.
>
> Is that normal in my case? Or I am just unlucky...
>
> Please advise. thanks!!
>

Phlip

2005-10-20, 6:59 pm

apngss wrote:

> I want to know if most of the software jobs in the market are software
> maintenance (fix bugs, new feature enhancements on existing code)
> rather than new developments (from scratch). This is my first job as a
> Java programmer, but I really don't see I do much Java development, all
> I do is to fix bugs, and add some new features for new builds. Well, of
> course I need to understand the logic of existing code, but my
> standpoint is that even I don't know Java well, I still can do the
> work.
>
> Is that normal in my case? Or I am just unlucky...

Ideally, all software projects should deploy to real users as soon as
possible. Then all further development is "maintenance", because you must
preserve existing (good) features while adding better ones. That depends on
clean code.

In your case, you are probably unlucky. Much software was written in a big
rush, under the belief that the software can't deploy until it has enough
features that customers will buy it and then use it through long maintenance
cycles. So the code has lots of bugs and a poor design.

The next AntiPattern in our industry: Managers then put the new guys into
maintenance, because it's slow burn. The hot-shots who wrote the bugs and
the poor design get rewarded with new and more lucrative projects.

Install JUnit, and start these policy:

- capture bugs with tests. Write new test cases
to capture every bug before killing it

- as you learn about the code, refactor - just a
little - to clean it up

That effort allows the code to get better over time. When you fix a bug, do
not throw away the knowledge that is fresh in your head write now. Invest
that knowledge back into the code by improving its test resistance.

--
Phlip
[url]http://www.greencheese.org/Z

Land[/url] <-- NOT a blog!!!

Walter Roberson

2005-10-20, 6:59 pm

In article <1129792428.032878.177440@g47g2000cwa.googlegroups.com>,
<apngss@yahoo.com> wrote:
>This topic should apply to software jobs regardless of the programming
>languages.

>I want to know if most of the software jobs in the market are software
>maintenance (fix bugs, new feature enhancements on existing code)
>rather than new developments (from scratch).

As others have noted, it is quite common to put new people onto
maintenance.

One of the posters suggested that this was training so that people
would learn the value of writing good maintainable code. Posters
might also have suggested [but haven't yet in my timeframe] that it
was an opportunity to give the new programmer a good understanding of
the project as a whole.

These two factors certainly apply, but there is another factor which
is often more important: maintenance is given to the new programmer
because in most power relationships, you give the unwanted tasks to
those who don't have the power to effectively refuse them.

In -every- programming environment i have worked in, the young
new programmers have chomped at the bit, eager to *write programs*,
and frustrated when they aren't given a program to write within a matter
of days. I have often seen new programmers upset that they aren't
creating new programs yet; often they would at least -say- that they
were thinking seriously of quiting because "this isn't what I
hired on for!" And most of them held that resentment of doing
maintenance (or even real formalized design specs), and pushed their
managers to rush into -new- -code-. Quite a few of them thereafter
refused to do maintenance as soon as they had accumulated enough
internal political capital to make it stick.

I've heard much the same thing from other people I know who are
in the software industry: most programmers really dislike code
maintenance -- even if it is their own code that is being maintained!
Most do not even like to do feature or design changes to their
existing code, not unless the change is clearly to add something "new".

Even to get someone to rewrite their code to make it faster
can be hard to convince them to do, unless you can make the situation
into a challenge to make their code run as quickly as possible...
a situation which often results in unmaintainable code that would
probably run slower on the next compiler over.

New programmers get stuck with maintenance because the more
senior people don't like to do maintenance. I've heard intermediate
people seriously tell their manager they would quit if they
were not given a "real" programming project.

The flip side of this is that it turns out that relatively few people
are actually -good- at maintenance. To be able to take existing code
(often poorly documented) and not only figure out what it -does- do,
but to figure out what it was -meant- to do, and to do massive
revisions to get clean code that does what it -should- do -- this is a
skill that I have rarely encountered. For a disorganized program of any
real size, it requires someone who is patient and an excellent mental
modeller, able to simultaneously hold in mind -many- program aspects
and relate them all to each other, seeing the overview of what is
logically consistant and yet able to pinpoint the minute details of
what does not fit. My experience suggests that the portion of
such people is less than 1 in 100 programmers; I'm not even confident
that as many as 3 in 1000 are good at this kind of work.
--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers

Roedy Green

2005-10-20, 6:59 pm

On Thu, 20 Oct 2005 14:06:52 +0000 (UTC), roberson@ibd.nrc-cnrc.gc.ca
(Walter Roberson) wrote or quoted :

>The flip side of this is that it turns out that relatively few people
>are actually -good- at maintenance.

Chairman Mao used to insist bureaucrats spent a few w

s each year
out on the farms. If he were in charge of the world's programming I
think he would do two things:

1. make all programmers spend a few w

s a year maintaining code so
they would learn what you need to do to write maintainable code and
what makes code unmaintainable. See
http://mindprod.com/jgloss/unmain.html

2. make all system programmers and language designers also spend a few
months a year doing applications coding so they would stop designing
to make their jobs easier and consider the application coder too.

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

BigBrian

2005-10-20, 6:59 pm

apngss@yahoo.com wrote:
> This topic should apply to software jobs regardless of the programming
> languages.
>
> I want to know if most of the software jobs in the market are software
> maintenance (fix bugs, new feature enhancements on existing code)
> rather than new developments (from scratch). This is my first job as a
> Java programmer, but I really don't see I do much Java development, all
> I do is to fix bugs, and add some new features for new builds. Well, of
> course I need to understand the logic of existing code, but my
> standpoint is that even I don't know Java well, I still can do the
> work.

I would be willing to bet that if you don't understand Java that well,
then you aren't doing the work as well as you think you are. You
should look at this an opportunity to learn every feature of the
language and use this knowledge to correct the bugs and/or bad design
decisions that may be the real cause of the bug. Doing this will gain
you alot of respect within your group. Maintance is a very important
part of the software life cycle.

> Is that normal in my case?

Yes, it's normal. And this is not a bad thing. If you're never in
maintainence mode, this probably means that your product has been
replaced with another vendors product and now you're scrambling to
start up another project.

It seems that the trend for software projects is for them to get larger
and larger. As this trend continues, more and more people will be
doing maintance, and those who do it well will be rewarded and valued.

> Or I am just unlucky...

No, you apparently have a job, and have admitted that you don't know
Java all that well. Sounds like you're very lucky!! ( I know expert
programmers who are looking for work. )

Andrew Thompson

2005-10-20, 6:59 pm

Roedy Green wrote:

> Chairman Mao used to insist bureaucrats spent a few w

s each year
> out on the farms.

I guess that was after the incident where Mao had the
bureaucrats direct (force) the rice farmers to plant
the rice seedlings so close together that they all
suphocated, resulting in widespread famine?

Maybe Mao should have been the one put out to pasture,
...errr, 'sent to the farm'.

"Ooh, Mao, M'Mao, Mao"
Russel Morris - 'The Real Thing'

Greg Comeau

2005-10-20, 6:59 pm

In article <f1afl19o3doibjk3fkuljj0v064bjss0mi@4ax.com>,
Roedy Green <my_email_is_posted_on_my_website@munged.invalid> wrote:
>On Thu, 20 Oct 2005 14:06:52 +0000 (UTC), roberson@ibd.nrc-cnrc.gc.ca
>(Walter Roberson) wrote or quoted :
>
>Chairman Mao used to insist bureaucrats spent a few w

s each year
>out on the farms. If he were in charge of the world's programming I
>think he would do two things:
>
>1. make all programmers spend a few w

s a year maintaining code so
>they would learn what you need to do to write maintainable code and
>what makes code unmaintainable. See
>http://mindprod.com/jgloss/unmain.html
>
>2. make all system programmers and language designers also spend a few
>months a year doing applications coding so they would stop designing
>to make their jobs easier and consider the application coder too.

When I was a manager years ago, I used to take Friday's off.
That meant, in addition to meetings, design etc through the w

,
actually sitting with the programmers and doing the work with them.
That meant I was approachable, not above them, and actually provided
a mechanisn to ricochet stuff back and forth, learn some of the
nitty gritties to make decision from, toss it back, etc.
I always felt it made us all more efficient, in sync, etc.
This also got newbies on board properly.
--
Greg Comeau / Celebrating 20 years of Comeauity!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Greg Comeau

2005-10-20, 6:59 pm

In article <1129820062.597739.133920@z14g2000cwz.googlegroups.com>,
BigBrian <work@brianmielke.com> wrote:
>I would be willing to bet that if you don't understand Java that well,
>then you aren't doing the work as well as you think you are. You
>should look at this an opportunity to learn every feature of the
>language and use this knowledge to correct the bugs and/or bad design
>decisions that may be the real cause of the bug. Doing this will gain
>you alot of respect within your group. Maintance is a very important
>part of the software life cycle.

Amen.
--
Greg Comeau / Celebrating 20 years of Comeauity!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

bugbear

2005-10-20, 6:59 pm

Robert C. Martin

2005-10-20, 6:59 pm

On Thu, 20 Oct 2005 07:35:12 GMT, John Harrison
<john_andronicus@hotmail.com> wrote:
[color=darkred]
>apngss@yahoo.com wrote:

From my point of view there is no difference between maintenance and
new development except, perhaps, for level of intensity. As soon as
the first line of code is written on a project, the project is in
maintenance; or so it seems to me.

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.

-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.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

Robert C. Martin

2005-10-20, 6:59 pm

On 20 Oct 2005 11:09:07 -0400, comeau@panix.com (Greg Comeau) wrote:

>When I was a manager years ago, I used to take Friday's off.
>That meant, in addition to meetings, design etc through the w

,
>actually sitting with the programmers and doing the work with them.
>That meant I was approachable, not above them, and actually provided
>a mechanisn to ricochet stuff back and forth, learn some of the
>nitty gritties to make decision from, toss it back, etc.
>I always felt it made us all more efficient, in sync, etc.
>This also got newbies on board properly.

The craft of software development it taught by masters to journeymen
and apprentices. It is not learned in school; and it is difficult to
learn it without a mentor. So, Greg, I applaud the approach you took.
Managers who have risen from the ranks should not leave the old job
behind. They need to mentor and guide the newer people coming behind
them.

One of *my* advisors (Dave Thomas of OTI fame) calls this the practice
of being a "playing coach".

-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.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

Mark P

2005-10-20, 6:59 pm

Greg Comeau wrote:
>
> When I was a manager years ago, I used to take Friday's off.
> That meant, in addition to meetings, design etc through the w

,
> actually sitting with the programmers and doing the work with them.

Your idea of taking the day off involves a lot more work than my idea of
the same. :)

H. S. Lahman

2005-10-20, 6:59 pm

Responding to Apngss...

> I want to know if most of the software jobs in the market are software
> maintenance (fix bugs, new feature enhancements on existing code)
> rather than new developments (from scratch). This is my first job as a
> Java programmer, but I really don't see I do much Java development, all
> I do is to fix bugs, and add some new features for new builds. Well, of
> course I need to understand the logic of existing code, but my
> standpoint is that even I don't know Java well, I still can do the
> work.
>
> Is that normal in my case? Or I am just unlucky...

Years ago I saw statistics collected independently by Capers Jones and
Howard Rubin on this topic bases on huge databases from thousands of
shops and tens of thousands of projects. I don't recall the exact
numbers by I believe they were in pretty close agreement that 60-80% of
all software development was maintenance against existing software.

Of course the definition of "maintenance" tends to be flexible. I have
developed modules with ~300 KLOC that were entirely new code that was
effectively autonomous (i.e., the module communicated with the rest of
the existing software through a well-defined API). I have also
developed entirely new standalone applications that were part of
existing larger systems that shared data and had limited
interoperability. In both cases I was effectively developing new code.
But that code was still an addition to existing software and some of
its nonfunctional requirements were dictated by existing code, so it was
technically "maintenance".

However, I suspect most of your problem is simply being the New Kid On
The Block. Many shops give those kids the work that nobody else wants
to do. Face it, everyone wants to be a System Architect and nobody
wants to code report generators or web pages. So to keep senior people
they may palm off the stuff the seniors don't want onto the new hires.
As long as you are working your way up the learning curve, you are going
to be the one who gets that stuff. Consider it in the grand tradition
of serving an apprenticeship.

BTW, fixing bugs is probably the best way to accelerate the learning
curve because isolating bugs quickly and fixing them without breaking
anything else requires substantial knowledge of what the software is
/actually/ doing. So you would probably end up doing more than your
share of that even in the most egalitarian shops.

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH

Mark McIntyre

2005-10-20, 6:59 pm

On 20 Oct 2005 00:13:48 -0700, in comp.lang.c , apngss@yahoo.com
wrote:

>I want to know if most of the software jobs in the market are software
>maintenance (fix bugs, new feature enhancements on existing code)
>rather than new developments (from scratch).

Theres a large body of existing code out there. Ergo there must be
lots of jobs maintaining it. Its impossible, given the length of time
that computing has been around, for new work to be larger than old
work.

>This is my first job as a
>Java programmer, but I really don't see I do much Java development,

You're the new boy. Its commonplace for newbies to spend a lot of time
fixing bugs, it lets them cut their teeth, explore their abilities and
so forth.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Andrew McDonagh

2005-10-20, 6:59 pm

Mark McIntyre wrote:
> On 20 Oct 2005 00:13:48 -0700, in comp.lang.c , apngss@yahoo.com
> wrote:
>
>

snipped.

>
>
>
> You're the new boy. Its commonplace for newbies to spend a lot of time
> fixing bugs, it lets them cut their teeth, explore their abilities and
> so forth.
>

Hi Mark,

( Please note this reply isn't so much to yourself, its to all of the
posts that talk about 'cutting their teeth' - I'm not singling you out.)

You are (

ly) right it is common. Its also the worst way of
integrating and using new people - especially newly qualified developers.

We are asking the to fix bugs on existing systems, where they typically
won't understand the original designs or design trade offs that were used.

Its actually more difficult to enhance or fix bugs in existing code
bases in a safe manner which doesn't introduce defects, than it is to
create new 'green field' code, for most people.

However, the main problem is the mentality of it -
" you are the new guy so your have to prove your worth scum-bag.."

Crazy.

Its not something I tolerate on my teams.

I employed a person who hadn't done any development for a year and half.
They also hadn't done any Java - they are a smalltalk-er - but they know
a little OO.

He started on the team and by the end of the first w

was developing
and being productive.

Now some of this is down to the teams principles and practices:

Collective Code Ownership - the new guy wasn't assigned an area or role,
he is part of a team where everyone works on all areas, maintenance and
greenfield.

Pair Programming - all development work being done in pairs meant that
he didn't need any ramp-up time to become useful - he paired with one of
the other team members and they worked together upon a single task, side
by side, swapping the keyboard as and when they wanted. The knowledge
transfer to the new guy is very quick this way and the other team person
learned some new skills from the new guy.

TestDriven Development - as we use TDD to design our system, any changes
the new guy and his pair make, are automatically regression tested by
the suite of unit tests. Their own design artifacts (their unit tests)
for the new code changes are simply added to the big pot of existing
designs.

there's more I can add if you want...

Andrew

Roedy Green

2005-10-20, 9:56 pm

On Thu, 20 Oct 2005 10:57:53 +0100, Mark McIntyre
<markmcintyre@spamcop.net> wrote or quoted :

>Theres a large body of existing code out there. Ergo there must be
>lots of jobs maintaining it. Its impossible, given the length of time
>that computing has been around, for new work to be larger than old
>work.

I heard one estimate that a program gets ten times as many hours spent
maintaining over its life that it does getting originally written. So
obviously maintenance predominates over initial coding. :There must be
many more maintenance jobs.

You may have noticed that programmers tend to be unusually
egotistical. This is part of the reason they generally don't like
modifying other people's code. They have to leave most of it "ugly" by
their personal scheme of aesthetics. It is a cause of stomach
wrenching unhappiness. They want to write virgin code so they can do
it "properly" or "their way" depending on your point of view.

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.

However, nationally advertised jobs tend to be the higher paying ones.
Here they are looking for experienced team leaders, architects etc.
not mundane maintenance programmers.

I think a bumbling incompetent could get by in a maintenance job
simply because the deadlines are not as tight and nobody really knows
how long it SHOULD take to find a bug or make some change. In theory
it should be easier, but managers don't put nearly as much weight on
efficient maintenance as getting the project up and going while the
spotlight is on it.

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Roedy Green

2005-10-20, 9:56 pm

On Thu, 20 Oct 2005 23:17:55 +0100, Andrew McDonagh
<news@andrewcdonagh.f2s.com> wrote or quoted :

>Pair Programming - all development work being done in pairs meant that
>he didn't need any ramp-up time to become useful - he paired with one of
>the other team members and they worked together upon a single task, side
>by side, swapping the keyboard as and when they wanted. The knowledge
>transfer to the new guy is very quick this way and the other team person
>learned some new skills from the new guy.

It is quite amazing how even a rank novice can become quickly useful
so long as he or she can type.

I would let them work first pretty well just as a typist as I went
about my usual business of writing and maintaining code. Most of this
was totally mysterious. But almost imperceptibly I could use a shorter
and shorter set of verbal commands to get the text I wanted written.
They learned much as a child learns a new language. You get to the
point where you could say something like. Write me a class with fields
x, y, z of the obvious types and do the usual constructors and
get/set.

Validate with configurable bounds.

Now adays you would do this with an IDE template, but people don't
need to be taught the template in excruciating detail, and they can do
theme and variations with little trouble. They can also convert old
code to a new pattern.

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

apngss@yahoo.com

2005-10-21, 3:57 am

Most posters say that companies usually put new programmers, or less
experience programmers to do the maintenance work.

One fundamental question that bothers me: How do we define "experienced
programmer"? 5 years experience, 10 years? I mean, how many years of
experience are considered as an experienced programmer?

Dag Sunde

2005-10-21, 3:57 am

<apngss@yahoo.com> wrote in message
news:1129875652.438870.223250@f14g2000cwb.googlegroups.com...
> Most posters say that companies usually put new programmers, or less
> experience programmers to do the maintenance work.
>
> One fundamental question that bothers me: How do we define "experienced
> programmer"? 5 years experience, 10 years? I mean, how many years of
> experience are considered as an experienced programmer?

How many years would you consider if I asked you about an experienced
mason, carpenter, mechanic or electrician? or a woodenboat builder for
that sake?

Its a craft, and is about the same thing.

--
Dag.

Walter Roberson

2005-10-21, 3:57 am

In article <1129875652.438870.223250@f14g2000cwb.googlegroups.com>,
<apngss@yahoo.com> wrote:
:Most posters say that companies usually put new programmers, or less
:experience programmers to do the maintenance work.

:One fundamental question that bothers me: How do we define "experienced
:programmer"? 5 years experience, 10 years? I mean, how many years of
:experience are considered as an experienced programmer?

Depends on the company. I've been programming for more than 25 years,
and the programming task that is waiting in the wings for me is
essentially maintenance work. On the other hand, if they thought
someone else could do this particular task well, they would have handed
it on by now instead of waiting for me --- there are some things that
effectively require very experienced maintenance programmers!

I no longer recall whether I was put on new code during my first
work term; I believe I was by my second, and I was doing some pretty
hairy work by my fourth.

But a lot depends on circumstances and skills and personality.
If the organization is "pushing" the progress of a fair sized project,
then the organization very likely is short of people who can readily
visualize diverse parts of the system and piece those parts together,
so anyone who displays an obvious talent in that field might find
themselves doing integration code development that most people with 5-10
years experience would hesitate to begin. But the skills and temperment
that make one a "natural" at that kind of integration code development
are pretty much the same as those that would be displayed by
a "natural" maintenance programmer/analyst.

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.
--
Programming is what happens while you're busy making other plans.

Martin Eisenberg

2005-10-21, 7:56 am

Roedy Green wrote:

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

Can you please expand on that for someone without extensive exposure
to old code?

--
Quidquid latine dictum sit, altum viditur.

BigBrian

2005-10-21, 7:01 pm

> You may have noticed that programmers tend to be unusually
> egotistical.

Isn't that the truth.

> This is part of the reason they generally don't like
> modifying other people's code.

Sad, but true.

> They want to write virgin code so they can do
> it "properly" or "their way" depending on your point of view.

... and then leave the project ( They're off design another project ) to
a group of other people how have to deal with the big pile of poop that
they implemented, and do the real work of getting everything working
correctly. ( No, I'm not bitter, LOL ) No, acutally, I like doing
maintenance ( and new development ).

Cristiano Sadun

2005-10-21, 7:01 pm

>I've heard much the same thing from other people I know who are
>in the software industry: most programmers really dislike code
>maintenance -- even if it is their own code that is being maintained!

This is odd. I dont know what "most programmers" do - and I'm not
particularly questoning your assertion - but I think one of the best
indications about how good a programmer is (or how well designed
his/her programs are) is exactly how easy it is to maintain them -
adding features, enhancing existing ones etc.

It would really be a

world if most programmers wouldn't like/accept
to do that..

Phlip

2005-10-21, 7:01 pm

apngss wrote:

> Most posters say that companies usually put new programmers, or less
> experience programmers to do the maintenance work.
>
> One fundamental question that bothers me: How do we define "experienced
> programmer"? 5 years experience, 10 years? I mean, how many years of
> experience are considered as an experienced programmer?

What will you do with the definition? "Allow" the programmer to write new
code?

I think experience comes from eating your own dogfood - from maintaining the
code you yourself wrote.

--
Phlip
[url]http://www.greencheese.org/Z

Land[/url] <-- NOT a blog!!!

timjowers@gmail.com

2005-10-21, 7:01 pm

JavaDoc. Design documents. Lots of self-promoters decry specifications
and documentation because they never had to maintian a few 100k lines
of code where they walked in cold with no knowledge of the code. Bug
fixing in an OS is tough but at least OS theory is well studied and
documented. Maintaing a huge corporate app where the requirements are
often only verbally understood by a few people who may no longer be
there is really tough.

Good logging of ALL errors. Ability to turn on DEBUG logging and
preferrable at various levels of verbosity.

A large source base with an integrated unit test to test all of the
code is very nice.

Elegant design. Repeated design when functionality is repeated.

BTW, newbies should be willing to perform maintenance for a time but
if you have an MS CSci. then don't insult yourself or your University
by maintaining some scrap code written by a hacker. Look for a company
where legitimate software design and development is occurring. The
market is far too overloaded with keyword programmers and architects
who think every design looks like some pattern from a vendor's promo
conference rather than consider design as part of the trade and apply
an appropriate design to the appropriate problem. You're probably
maintaining bloatware written atop some consultingware appserver or
other infrastructure. The engineering mindset of solving the problem
with the lowest cost effort is rare in this industry. That's why the
term "Software Engineer" is no longer used. The managers prefer
"Programmer" and "Consultant" because it hides the fact that good
software development requires real engineering. Does your code
represent the Unix mantra of Keep It Simple Stupid?

Best wishes,
TimJowers

Daniel Parker

2005-10-21, 7:01 pm

apngss@yahoo.com wrote:
>
> I want to know if most of the software jobs in the market are software
> maintenance (fix bugs, new feature enhancements on existing code)
> rather than new developments (from scratch). This is my first job as a
> Java programmer, but I really don't see I do much Java development, all
> I do is to fix bugs, and add some new features for new builds. Well, of
> course I need to understand the logic of existing code, but my
> standpoint is that even I don't know Java well, I still can do the
> work.
>
I think that's been the case for a long time, and is exasperated now
because there is so much legacy software, and because companies today
are buying more and building less. In place of new software
development you now have integration projects that involve building
many small things to tie bigger things together.

But you want to do new development. I don't think that maintenance
work naturally leads to new development work, maintenance programmers
do important work, and there's a tendency to leave them there. I also
don't think that you should just wait around until you have more
experience, hoping that will help. Instead, do whatever it takes to
get into a new development environment. Sacrifice income and job
title, enlist the help of agencies and friends, scour the market, find
companies that need to do things and position yourself to get in there.
Make that your number one priority and go for it.

-- Daniel

John Bode

2005-10-21, 7:01 pm

Andrew McDonagh

2005-10-21, 7:01 pm

Roedy Green wrote:
> On Thu, 20 Oct 2005 23:17:55 +0100, Andrew McDonagh
> <news@andrewcdonagh.f2s.com> wrote or quoted :
>
>
>
>
> It is quite amazing how even a rank novice can become quickly useful
> so long as he or she can type.
>
> I would let them work first pretty well just as a typist as I went
> about my usual business of writing and maintaining code. Most of this
> was totally mysterious. But almost imperceptibly I could use a shorter
> and shorter set of verbal commands to get the text I wanted written.
> They learned much as a child learns a new language. You get to the
> point where you could say something like. Write me a class with fields
> x, y, z of the obvious types and do the usual constructors and
> get/set.
>
> Validate with configurable bounds.
>
> Now adays you would do this with an IDE template, but people don't
> need to be taught the template in excruciating detail, and they can do
> theme and variations with little trouble. They can also convert old
> code to a new pattern.
>
>
>
>
I

by your reply - are you attempting to describe
PairProgramming - if so you are way off.

Andrew McDonagh

2005-10-21, 7:01 pm

Andrew McDonagh wrote:
> Roedy Green wrote:
>
> I

...

should have been 'I'm

....'

BigBrian

2005-10-21, 7:01 pm

Daniel Parker wrote:
> apngss@yahoo.com wrote:
> I think that's been the case for a long time, and is exasperated now
> because there is so much legacy software, and because companies today
> are buying more and building less. In place of new software
> development you now have integration projects that involve building
> many small things to tie bigger things together.
>
> I also
> don't think that you should just wait around until you have more
> experience, hoping that will help.

Hmmm, but the original poster admitted that he doesn't even know Java
well. Don't you think that knowing the language should be a necessary
requirement for any programming job?

Lets see.... He doesn't know java very well, but he has a job as a java
programmer. He gets assigned to doing maintanence ( IMHO a very good
opportunity to learn the language in addition to what is good and bad
design ), but instead he complains that he's not doing new development
( for which IMHO, given that he doesn't know the language all that
well, he's not qualified ). Then it seems that many people here
suggest the he look for another job ( instead of taking advantage of
his current opportunity to gain experinece/knowledge ). IMHO, there's
something wrong with this....

Daniel Parker

2005-10-21, 7:01 pm

BigBrian wrote:
>
> Hmmm, but the original poster admitted that he doesn't even know Java
> well. Don't you think that knowing the language should be a necessary
> requirement for any programming job?
>
:-)

You're referring to "my standpoint is that even I don't know Java well,
I still can do the work."

I didn't read that the way you did. I read it that even someone who
didn't know much about Java could still do the work that he's currently
being assigned, that the work isn't challenging.

-- Daniel

Bradley K. Sherman

2005-10-21, 7:01 pm

In article <1129925351.933408.156590@z14g2000cwz.googlegroups.com>,
Daniel Parker <danielaparker@hotmail.com> wrote:
>
>BigBrian wrote:
>:-)
>
>You're referring to "my standpoint is that even I don't know Java well,
>I still can do the work."
>
>I didn't read that the way you did. I read it that even someone who
>didn't know much about Java could still do the work that he's currently
>being assigned, that the work isn't challenging.
>

And whose English is below par. No big deal if he's working
outside the USA.

I never hire programmers who scorn maintaining existing code.

--bks

Chris Uppal

2005-10-21, 7:01 pm

Bradley K. Sherman wrote:

> And whose English is below par. No big deal if he's working
> outside the USA.

Do you care to rephrase that ? Or to recant ?

Otherwise do, please, include in your answer an exact description of what being
in "the USA" has to do with par (or above) English.

-- chris

John Bode

2005-10-21, 7:01 pm

BigBrian wrote:
> Daniel Parker wrote:
>
> Hmmm, but the original poster admitted that he doesn't even know Java
> well. Don't you think that knowing the language should be a necessary
> requirement for any programming job?
>

Well, my first real programming job as a freshout was in Ada, a
language in which I had *no* practical experience, and this was new
development, not maintenance. I had about two w

s to get proficient.

Granted, it was scutwork, but it was scutwork I had to develop from the
keel up.

So, no, knowing a specific language is not *necessarily* a requirement
for a programming job (barring things like numerical analysis or signal
processing or some other performance-oriented field, where intimate
knowledge of the implementation language is vital). More important is
a knowledge of programming fundamentals, coupled with an ability to
learn how to use new tools quickly (for a five or six year period,
every contract required me to learn a brand-new (to me) language or
API).

If you haven't been exposed to Java, but know C or C++, then that's not
that big a barrier. If you know one Algol-derived language, then you
ought to be able to pick up any other Algol-derived language with
little or no difficulty. If you're going from, say, Fortran IV to C++
(or vice versa), that may be a bigger problem, but even then the leap
isn't so great.

C to Lisp, now, that would cause some heartburn.

> Lets see.... He doesn't know java very well, but he has a job as a java
> programmer. He gets assigned to doing maintanence ( IMHO a very good
> opportunity to learn the language in addition to what is good and bad
> design ), but instead he complains that he's not doing new development
> ( for which IMHO, given that he doesn't know the language all that
> well, he's not qualified ).

There are people I consider experts in specific languages that I would
not assign new development to, because they constantly go beyond the
scope of the spec or, better yet, ignore the spec outright and deliver
something really

but really useless.

Getting to write new code has less to do with your familiarity with the
implementation language and more with your ability to spec and design a
solution, or at least to go from a spec to working code.

In the end, knowing the actual implementation language is a relatively
minor detail; understanding the application domain and how the code you
write fits into it is the more important thing.

> Then it seems that many people here
> suggest the he look for another job ( instead of taking advantage of
> his current opportunity to gain experinece/knowledge ). IMHO, there's
> something wrong with this....

FWIW, I think he should stick with his current gig for at least a year
or two, and get used to not only Java, but the application domain in
which he is working.

Andrew McDonagh

2005-10-21, 7:01 pm

BigBrian wrote:
> Daniel Parker wrote:
>
>
>
> Hmmm, but the original poster admitted that he doesn't even know Java
> well. Don't you think that knowing the language should be a necessary
> requirement for any programming job?
>
> Lets see.... He doesn't know java very well, but he has a job as a java
> programmer. He gets assigned to doing maintanence ( IMHO a very good
> opportunity to learn the language in addition to what is good and bad
> design ), but instead he complains that he's not doing new development
> ( for which IMHO, given that he doesn't know the language all that
> well, he's not qualified ). Then it seems that many people here
> suggest the he look for another job ( instead of taking advantage of
> his current opportunity to gain experinece/knowledge ). IMHO, there's
> something wrong with this....
>

Utter rubbish!

The project I'm leading is using Delphi7, VB6 & PL/SQL - none of which
I've used.

Knowing the languages helps - but knowing software engineering
principles and practices matter much more.

Once you have enough of a grasp on these, then moving to unknown
languages is trivial. The biggest learning task when moving to new
languages, is learning the libraries that they provide or are commonly
used - but this is simply fixed by talking to the guy next to you and
saying ' I want to do X - how do I do that in <insert your new language
here> '

Really, it is that simple.

Andrew

Andrew

Ian

2005-10-21, 7:01 pm

Bradley K. Sherman wrote:
>
>
> And whose English is below par. No big deal if he's working
> outside the USA.
>
? remember where the language came from!

Ian

Roedy Green

2005-10-21, 7:01 pm

On Fri, 21 Oct 2005 19:05:36 +0100, Andrew McDonagh
<news@andrewcdonagh.f2s.com> wrote or quoted :

>I

by your reply - are you attempting to describe
>PairProgramming - if so you are way off.

What is it in your definition?
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Bradley K. Sherman

2005-10-21, 7:01 pm

In article <435951d5$0$38040$bed64819@news.gradwell.net>,
Chris Uppal <chris.uppal@metagnostic.REMOVE-THIS.org> wrote:
>Bradley K. Sherman wrote:
>
>
>Do you care to rephrase that ? Or to recant ?
>
>Otherwise do, please, include in your answer an exact description of what being
>in "the USA" has to do with par (or above) English.
>

Sure, if you're working in Germany your English does not have
to be good. If you're working in the USA (or UK or Oz) it
should be.

--bks

Andrew McDonagh

2005-10-21, 7:01 pm

Roedy Green wrote:
> On Fri, 21 Oct 2005 19:05:36 +0100, Andrew McDonagh
> <news@andrewcdonagh.f2s.com> wrote or quoted :
>
>
>
>
> What is it in your definition?

what is what, in my definition?

Roedy Green

2005-10-21, 7:01 pm

On 21 Oct 2005 11:11:37 GMT, Martin Eisenberg
<martin.eisenberg@udo.edu> wrote or quoted :

>The needs of the compiler
>
>Can you please expand on that for someone without extensive exposure
>to old code?

Let's say that an application programmer were in charge. He sets up
listeners all the time. He would insist on doing that in at most a
line of code, no matter how much work it meant for the compiler and
library writers.

In your IDE you would right click on the component and insert the code
right there.

If an application programmer were in charge there would be smart
components for all the usual business objects, names, address, emails,
website, zips, provinces, countries, .dates, phone numbers that worked
for all countries. They would automatically format and validate all
input. That would not be his problem any more than the strange rule
of date calculation are. Low and high bounds checking and all manner
of other common validation would be built into the declaration without
any procedural code.

If an application programmer were in charge , components would know
their labels, and there would be layout that would automatically
insert such labels when there was sufficient room, and would at
minimum divulge them with a hover.

If an application programmer were in charge, the integration of SQL
and Java would be much more seamless, much like the new features for
than in C#.

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Roedy Green

2005-10-21, 7:01 pm

On 21 Oct 2005 06:20:49 -0700, "BigBrian" <work@brianmielke.com> wrote
or quoted :
[color=darkred]

Young hot shots are a major problem in a team environment. They are so
keen on doing something

, they forget some lesser light will have
to later figure it out to maintain it. These types often refuse to
write any documentation at all, claiming their code reads like poetry
and does not need it, at least if everyone scrutinizing every line
lovingly.

These hotshots can still be useful. For example, I was team leader
on the first MacIntosh commercial app written in Canada, the CSL Stock
Charter, developed on the Lisa and wired over to the Mac for
execution. Apple's docs and code were unbelievably bad. Lots of "to
comes" and simply wrong information.

Our app was embarrassingly slow. The problem was obviously Apple's
first cut at a software floating point library. I figured out that the
scaling routines for the graphing were the major culprits. I handed
the Pascal version of the code to a hotshot friend of mine, and said,
"go to it. Do this same thing using integer fixed point scaling,
assembler, any dirty tricks you can think of."

He came back a few days later with some motorola 68K assembler that
was about 2 orders of magnitude faster. Never would that code be
maintained. If the code were ported, it would be re-optimised from
the Pascal version, perhaps with hints from the 68K version.

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

David Alex Lamb

2005-10-21, 7:01 pm

In article <djbq58$8th$1@news.freedom2surf.net>,
Andrew McDonagh <news@us.com> wrote:
>Roedy Green wrote:
>what is what, in my definition?

I believe he means:
What is PairProgramming in your definition?
--
"Yo' ideas need to be thinked befo' they are say'd" - Ian Lamb, age 3.5
http://www.cs.queensu.ca/~dalamb/ qucis->cs to reply (it's a long story...)

Roedy Green

2005-10-21, 7:01 pm

On Fri, 21 Oct 2005 07:32:25 +0000 (UTC), roberson@ibd.nrc-cnrc.gc.ca
(Walter Roberson) wrote or quoted :

>But a lot depends on circumstances and skills and personality.
>If the organization is "pushing" the progress of a fair sized project,
>then the organization very likely is short of people who can readily
>visualize diverse parts of the system and piece those parts together,

That is an important observation. When you write new code, you can
focus 99% of your attention on the one class you are composing.

When you do maintenance, any change you make could potentially disrupt
ANYTHING in the whole app system. The better it was originally
designed, the less paranoid you have to be. You have to understand the
app as a whole and mostly what it is safe to IGNORE for any sort of
change.

In contrast, when you write new code, there are no interactions yet to
worry about.

I am big on Christmas present comments of the form, "If you have to
change X, or add a new Y all you need do is modify the tables/code at
a, b, c."

So you need a very focused mind for writing new code, and a mind that
can keep a million interactions in mind to do maintenance well.

I used to have a ritual for getting into heavy maintenance mode.
It involved consuming pizza and coffee, being undisturbed for long
periods of time, unusually late at night, re-rereading documentation
and refreshing my mind going over crucial code till a model of the app
as a whole was again fresh in my mind. Then I could make a great
series of changes very quickly and accurately.

Maintaining your own code is much easier. I can trust myself not to
pull a great many stupid stunts, and to thoroughly document iffy
tricks, and any crucially important gotchas. I can't do that
maintaining other people's code until I get to know them though their
code.

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Roedy Green

2005-10-21, 7:01 pm

On Fri, 21 Oct 2005 13:40:29 GMT, "Phlip" <phlipcpp@yahoo.com> wrote
or quoted :

>I think experience comes from eating your own dogfood - from maintaining the
>code you yourself wrote.

Perhaps this is partly why there is so much outsourcing. People who
maintain their own code write better code.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Roedy Green

2005-10-21, 7:01 pm

On 21 Oct 2005 12:46:17 -0700, "BigBrian" <work@brianmielke.com> wrote
or quoted :

>He doesn't know java very well, but he has a job as a java
>programmer. He gets assigned to doing maintanence ( IMHO a very good
>opportunity to learn the language in addition to what is good and bad
>design ),

Getting paid to maintain the code of a master programmer is a bit like
being invited to sit at the lotus feet of your guru.

What an opportunity for education!

On the other hand, cleaning up code from incompetents will rapidly
teach you all the things not to do. I took out much of my frustration
from such jobs writing the most popular essay of my lifetime:
http://mindprod.com/jgloss/unmain.html with almost a million hits on
it now.

It hit a nerve.

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Roedy Green

2005-10-21, 7:01 pm

On Fri, 21 Oct 2005 21:54:25 +0100, Andrew McDonagh
<news@andrewcdonagh.f2s.com> wrote or quoted :

>Once you have enough of a grasp on these, then moving to unknown
>languages is trivial.

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.

On the other paw, I had more trouble with Java than I should have
mainly because I kept expecting it to be the same as C++ because it
superficially looked so similar.

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Flash Gordon

2005-10-21, 9:56 pm

Bradley K. Sherman wrote:
> In article <435951d5$0$38040$bed64819@news.gradwell.net>,
> Chris Uppal <chris.uppal@metagnostic.REMOVE-THIS.org> wrote:
>
>
> Sure, if you're working in Germany your English does not have
> to be good. If you're working in the USA (or UK or Oz) it
> should be.

Yes, and the last time I checked the only one of those three that was
not outside the USA is the USA.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

Roedy Green

2005-10-21, 9:56 pm

On Fri, 21 Oct 2005 23:29:57 +0100, Andrew McDonagh
<news@andrewcdonagh.f2s.com> wrote or quoted :

>
>what is what, in my definition?

Who's on first? It sounded to me you were trashing the only
definition given of pair programming a while back. On digging through
the threads I discover that it was your definition, so it is unlikely
you were baldly berating yourself for being wrong without offering an
alternate definition.

In my own post I was talking about an alternative way to teach
programming, nothing to do with pair programming other than it
involves two people sitting at the same computer.

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

N. B. (substitute bay for gulf to e-mail)

2005-10-21, 9:56 pm

Ian wrote:
> Bradley K. Sherman wrote:
> ? remember where the language came from!
>
> Ian
What does speaking English well have to do with Germany?

Andrew McDonagh

2005-10-22, 7:56 am

Roedy Green wrote:
> On Fri, 21 Oct 2005 23:29:57 +0100, Andrew McDonagh
> <news@andrewcdonagh.f2s.com> wrote or quoted :
>
>
>
>
> Who's on first? It sounded to me you were trashing the only
> definition given of pair programming a while back. On digging through
> the threads I discover that it was your definition, so it is unlikely
> you were baldly berating yourself for being wrong without offering an
> alternate definition.
>
> In my own post I was talking about an alternative way to teach
> programming, nothing to do with pair programming other than it
> involves two people sitting at the same computer.
>
>

right now I understand your comment....

its certainly one way for a new person to learn - *I* doubt its very
effective.

Andrew McDonagh

2005-10-22, 7:56 am

David Alex Lamb wrote:
> In article <djbq58$8th$1@news.freedom2surf.net>,
> Andrew McDonagh <news@us.com> wrote:
>
>
>
> I believe he means:
> What is PairProgramming in your definition?

Well, the small paragraph I posted describing how *my Team* actually do
Pair Programming is pretty much how I'd define PP. Though there is more
to it than that.

As for a more accepted definition...

"Two programmers working side-by-side, collaborating on the same design,
algorithm, code or test. One programmer, the driver, has control of the
keyboard/mouse and actively implements the program. The other
programmer, the observer, continuously observes the work of the driver
to identify tactical (syntactic, spelling, etc.) defects and also thinks
strategically about the direction of the work. On demand, the two
programmers can brainstorm any challenging problem.

Because the two programmers *periodically switch roles*, they work
together as equals to develop software."

-- Laurie Williams
North Carolina State University Computer Science

Roedy Green

2005-10-22, 7:56 am

On Sat, 22 Oct 2005 10:57:17 +0100, Andrew McDonagh
<news@andrewcdonagh.f2s.com> wrote or quoted :

>its certainly one way for a new person to learn - *I* doubt its very
>effective.

Since you have never experimented with the technique, you should know.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Andrew McDonagh

2005-10-22, 7:56 am

Roedy Green wrote:

>
> On the other hand, cleaning up code from incompetents will rapidly
> teach you all the things not to do. I took out much of my frustration
> from such jobs writing the most popular essay of my lifetime:
> http://mindprod.com/jgloss/unmain.html with almost a million hits on
> it now.
>
> It hit a nerve.
>
>
>

Yes, for us programmers - that essay is one of the funniest - well done
Roedy

Andrew McDonagh

2005-10-22, 7:56 am

Chris Uppal wrote:
> Andrew McDonagh wrote:
>
>
>
>
> Which does not, in fact, resemble what Roedy described at all. I'm puzzled by
> why you thought there was a connection ?
>
> -- chris
>
>

I was puzzled by Roedy's description because I 'Thought' he was trying
to describe what Pair Programming (as in the snipped definition) means
to him.

Thats all - we are talking across each other..about different things
that 'Just Happen To use two people working together in some form'

Andrew

Goran Sliskovic

2005-10-22, 6:57 pm

"Andrew McDonagh" <news@andrewcdonagh.f2s.com> wrote in message
news:djd2o9$lf5$2@news.freedom2surf.net...
> Roedy Green wrote:
....
....[color=darkred]
> Yes, for us programmers - that essay is one of the funniest - well done
> Roedy

It looks that it's not funny for everybody. I have to maintain 350 kloc
project done by programmers who thought it was study book... However, I
must admit that I have learned a lot about programming from that. Also,
being the one who managed to control that chaos had some good consequences
(financial and in little privileges such as *very* flexible working hours,
days off etc..). So it levels it fine.

Goran

pauldepstein@att.net

2005-10-22, 6:57 pm

Daniel Parker wrote:
> BigBrian wrote:
> :-)
>
> You're referring to "my standpoint is that even I don't know Java well,
> I still can do the work."
>
> I didn't read that the way you did. I read it that even someone who
> didn't know much about Java could still do the work that he's currently
> being assigned, that the work isn't challenging.
>
> -- Daniel

Well, I found the original posting very offensive, and I agree 100%
with those who replied with personal criticisms of the poster and
called the OP "self-centred" etc.

The original posting was _wildly_ OT for this _c++ language_ newsgroup.
And it's incredibly pompous of this individual (the OP) to assume not
only the right to employment, but the right to be intellectually
challenged by the work. I'm sure there are some people who earn a
living as janitors who are more intelligent and better-educated than
the OP.

Paul Epstein

Chris Uppal

2005-10-22, 6:57 pm

pauldepstein@att.net wrote:

> And it's incredibly pompous of this individual (the OP) to assume not
> only the right to employment, but the right to be intellectually
> challenged by the work. I'm sure there are some people who earn a
> living as janitors who are more intelligent and better-educated than
> the OP.

Do you really mean that no one has the right to be dissatisfied with their lot
if there is someone else who is in an even worse position ? If so then at
most one person in the world at any one time is entitled to be disgruntled...

-- chris

Daniel Parker

2005-10-22, 6:57 pm

"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
news:tkkfl1lj3i2435s2gv9mq2bh3rm7hv9e6u@
4ax.com...
>
> From my point of view there is no difference between maintenance and
> new development except, perhaps, for level of intensity. As soon as
> the first line of code is written on a project, the project is in
> maintenance; or so it seems to me.
>
Yeah, well let's say you were about to join Chrysler in 1995 or thereabouts,
and were given a choice of two projects: a maintenance role on the existing
payroll system, or a spot on Kent Becks's C3 project? Which would you have
gone for? Decisions, decisions...

Regards,
Daniel Parker

Chris Smith

2005-10-22, 6:57 pm

Goran Sliskovic <gsliskov@yahoo.com> wrote:
>
> It looks that it's not funny for everybody. I have to maintain 350 kloc
> project done by programmers who thought it was study book...

I don't find that very believable. If you're maintaining 350,000 lines
of code written by someone who's too dumb to understand the point of
Roedy's essay, then you'd have serious problems whether Roedy had
written that essay or not!

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Branimir Maksimovic

2005-10-22, 6:57 pm

<apngss@yahoo.com> wrote in message
news:1129792428.032878.177440@g47g2000cwa.googlegroups.com...
> This topic should apply to software jobs regardless of the programming
> languages.
>
> I want to know if most of the software jobs in the market are software
> maintenance (fix bugs, new feature enhancements on existing code)
> rather than new developments (from scratch).

Developement from scratch assumes writing a new framework.
After framework is done all other work can be considered as maintenance.
Lot of projects start within a code framework, so many jobs are maintenance
buy your thinking. There is no such thing as development from scratch
any more, at least from begining of time when libraries are invented :)

This is my first job as a
> Java programmer, but I really don't see I do much Java development, all
> I do is to fix bugs, and add some new features for new builds. Well, of
> course I need to understand the logic of existing code, but my
> standpoint is that even I don't know Java well, I still can do the
> work.

Learn first, then they will assign you more challenging tasks probably.
What you would do if they assign you a task you couldn't accomplish?

Greetings, Bane.

Bradley K. Sherman

2005-10-22, 6:57 pm

In article <f9co23xo17.ln2@news.flash-gordon.me.uk>,
Flash Gordon <spam@flash-gordon.me.uk> wrote:
>Bradley K. Sherman wrote:
>what being
>
>Yes, and the last time I checked the only one of those three that was
>not outside the USA is the USA.

Noted!

--bks

Goran Sliskovic

2005-10-22, 6:57 pm

"Chris Smith" <cdsmith@twu.net> wrote in message
news:MPG.1dc405fe93139d54989b40@news.altopia.net...
> Goran Sliskovic <gsliskov@yahoo.com> wrote:
done[color=darkred]
>
> I don't find that very believable. If you're maintaining 350,000 lines
> of code written by someone who's too dumb to understand the point of
> Roedy's essay, then you'd have serious problems whether Roedy had
> written that essay or not!

It was a sarcasm (which implies great sorrow and pain it has done to me).
Though code does exactly what essay says, so I wonder sometimes...

Regards,
Goran

Andrew Thompson

2005-10-22, 6:57 pm

Branimir Maksimovic wrote:

> What you would do if they assign you a task you couldn't accomplish?

That's a no brainer.

Come onto the usenet newsgroups, pretending you are
describing the most arcane of computational problems,
that 'myself and my colleagues' had been 'kicking around'
and were 'inviting further ideas'.

Then add that you don't want to hear from anyone that has
not 'implemented these ideas - no time wasters, please'.

Then close with 'reply by email' & 'Urgently', to convince
them you are busy.

Andrew McDonagh

2005-10-22, 6:57 pm

Branimir Maksimovic wrote:
> <apngss@yahoo.com> wrote in message
> news:1129792428.032878.177440@g47g2000cwa.googlegroups.com...
>
>
>
> Developement from scratch assumes writing a new framework.

Does it?

Not on my teams - we certainly let frameworks emerge over time through
refactorings, but we certainly don't start off developing them.

It can and

ly does happen on the majority of teams - but its not a
good thing - Running Tested Features released often and early is much
more preferable to customers than Frameworks - RTFs have business value

pauldepstein@att.net

2005-10-22, 6:57 pm

Chris Uppal wrote:
> pauldepstein@att.net wrote:
>
>
> Do you really mean that no one has the right to be dissatisfied with their lot
> if there is someone else who is in an even worse position ? If so then at
> most one person in the world at any one time is entitled to be disgruntled...
>
> -- chris

Well, the OP gives the strong impression of having inappropriately high
expectations of what to expect from employment, given the OP's
admittedly limited knowledge.

I was offended by this, and I was not the only one. I'm a bit
surprised that this reaction -- being offended -- was not the universal
one.

I posted a parody of the OP in another thread. It expresses my
opinions of the OP very well and I'm quite proud of the parody:

My parody is printed verbatim below as part of my posting excerpt:
Some explanation is needed. The reason the OP is off-topic (in some
newsgroups) is that the thread was included in newsgroups on the _c++
language_.

EXCERPT BEGINS BELOW

I also find it absurdly ironic that, in marked contrast to the attitude

towards compiler/platform discussions, the following posting, which was

_wildly irrelevant_, induced a long and sober thread of replies, and
did not seem to be condemned as OT by anybody.

Yesterday's irrelevant (but apparently not judged OT) thread began as
follows:

" I would like to share my distress at the way I have been treated in
my new entry-level job as a java programmer. (I have 3 months
programming experience). My salary is less than 2 million dollars a
year, and my boss has never offered to provide me with a chauffeur to
drive me into work, even though I live in a neighboring town.
Furthermore, last w

he treated me to dinner at a Chinese restaurant,

and I was shocked and appalled to notice a small stain on one of the
tablecloths.

Are such experiences typical of everyone, or am I just unlucky?"

END OF EXCERPT

Paul Epstein

Branimir Maksimovic

2005-10-22, 6:57 pm

"Andrew McDonagh" <news@andrewcdonagh.f2s.com> wrote in message
news:djdu9e$105$1@news.freedom2surf.net...
> Branimir Maksimovic wrote:
>
> Does it?
>
> Not on my teams - we certainly let frameworks emerge over time through
> refactorings, but we certainly don't start off developing them.
>
> It can and

ly does happen on the majority of teams - but its not a good
> thing - Running Tested Features released often and early is much more
> preferable to customers than Frameworks - RTFs have business value

And how you are supposed to run tested features without framework?

Greetings, Bane.

Robert C. Martin

2005-10-22, 6:57 pm

On Sat, 22 Oct 2005 11:12:32 -0400, "Daniel Parker"
<danielaparker@spam?nothanks.sympatico.ca> wrote:

>"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
> news:tkkfl1lj3i2435s2gv9mq2bh3rm7hv9e6u@
4ax.com...
>Yeah, well let's say you were about to join Chrysler in 1995 or thereabouts,
>and were given a choice of two projects: a maintenance role on the existing
>payroll system, or a spot on Kent Becks's C3 project? Which would you have
>gone for? Decisions, decisions...

Smalltalk vs. Cobol? That's a no-brainer. XP vs. Waterfall? That's
also a no-brainer. Working with Kent? No-brainer.

-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.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

Branimir Maksimovic

2005-10-22, 6:57 pm

"Branimir Maksimovic" <bmaxa@eunet.yu> wrote in message
news:djdug3$igi$1@news.eunet.yu...[color=darkred]
>
> "Andrew McDonagh" <news@andrewcdonagh.f2s.com> wrote in message
> news:djdu9e$105$1@news.freedom2surf.net...

I call this technique: a "chaotic development style"
Normal consequence is that dozens of small incopatible frameworks and
redundant
code emerge from each team and then when integration comes to play
they spend lot of wasted time to refactor the code for nothing.

Greetings, Bane.

Andrew McDonagh

2005-10-22, 6:57 pm

Branimir Maksimovic wrote:
> "Andrew McDonagh" <news@andrewcdonagh.f2s.com> wrote in message
> news:djdu9e$105$1@news.freedom2surf.net...
>
>
>
> And how you are supposed to run tested features without framework?
>
> Greetings, Bane.
>
>
>
>

By Framework - I took you to mean that you created some Generic
infrastructure for your application, that is also specific the type of
application you are developing - as in JBoss, JavaMail, Etc...

If I'm wrong - can you explain a bit what you do mean by Framework.

If I'm right - Then any application can be developed without generic
Frameworks within it - they still run.

If the customer needs an app that reads stock market info and sends them
an email when ever their own stocks value starts to drop, then we don't
need any framework for this.

If the customer then wants us to add in the ability to send them an SMS
text msg instead of an email - we MAY decide that we need a generic
Messaging Transport framework of some kind or we may NOT - there is only
two message transports to be used - the 'framework' at this point is an
'IF' statement or polymorphic call at best.

If the customer added a third message transport type (web page updates,
Carrier Pigeons, Motorcycle Dispatches etc) then it is usually prudent
to use a framework.

But right in the beginning - it just sent emails - so we didn't need a
generic Messaging Framework.

Is that a good enough example?

please don't mis-understand me - I'm not anti-framework, I'm just
against prematurely-introducing-frameworks. I've seen to many projects
be months late because the team thought they needed to have a framework
in place BEFORE they could do anything, rather than INTRODUCE a
framework later when they really do have a need.

Andrew

Andrew McDonagh

2005-10-22, 6:57 pm

Branimir Maksimovic wrote:

Snipped.

>
> I call this technique: a "chaotic development style"

Thats ok - I call it by its real name: Agile development.

> Normal consequence is that dozens of small incopatible frameworks and
> redundant
> code emerge from each team and then when integration comes to play
> they spend lot of wasted time to refactor the code for nothing.
>
> Greetings, Bane.
>
>

Are you talking about Frameworks for multiple teams or about multiple
developers on a single team each separately developing a 'framework'
then merging into main line for the rest of the team to use?

Ross Bamford

2005-10-22, 6:57 pm

On Sat, 22 Oct 2005 17:56:36 +0100, Andrew Thompson
<seemysites@www.invalid> wrote:

> Branimir Maksimovic wrote:
>
>
> That's a no brainer.
>
> Come onto the usenet newsgroups, pretending you are
> describing the most arcane of computational problems,
> that 'myself and my colleagues' had been 'kicking around'
> and were 'inviting further ideas'.
>
> Then add that you don't want to hear from anyone that has
> not 'implemented these ideas - no time wasters, please'.
>
> Then close with 'reply by email' & 'Urgently', to convince
> them you are busy.

Finally, argue against the solutions you're provided, while selecting the
best one and implementing it anyway, claiming you 'Found the answer
elsewhere'.

--
Ross Bamford - rosco@roscopeco.remove.co.uk

Andrew McDonagh

2005-10-22, 6:57 pm

Andrew McDonagh wrote:
> Branimir Maksimovic wrote:

snipped...

>
> please don't mis-understand me - I'm not anti-framework, I'm just
> against prematurely-introducing-frameworks. I've seen to many projects
> be months late because the team thought they needed to have a framework
> in place BEFORE they could do anything, rather than INTRODUCE a
> framework later when they really do have a need.
>
> Andrew

oh WRT 'anti-framework' here's a very funny post on Joel-on-software...

http://discuss.joelonsoftware.com/d...oel.3.219431.39

"....Actually, we don't sell hammers at all.

So...

According to our research, what people really needed wasn't a Universal
Hammer after all. It's always better to have the right kind of hammer
for the job. So, we started selling hammer factories, c...."

Roedy Green

2005-10-22, 6:57 pm

On Sat, 22 Oct 2005 12:30:21 +0100, Andrew McDonagh
<news@andrewcdonagh.f2s.com> wrote or quoted :

>I was puzzled by Roedy's description because I 'Thought' he was trying
>to describe what Pair Programming (as in the snipped definition) means
>to him.
>
>Thats all - we are talking across each other..about different things
>that 'Just Happen To use two people working together in some form'

There are many cues missing you get with verbal communication that
lead to foul-ups in newsgroup communication.

You don't have the voice print/accent/dialect cue on every word to
remind you who is saying what.

You don't get the body language or cues of emotion, joking, anger...

With voice, you can tell immediately if someone is disagreeing or
seconding or augmenting. In newsgroups that is not obvious and leads
to all kinds of puzzlement when the wrong assumption is applied.

Everybody talks at once about everything.

The speaker does not get immediate feedback by quizzical looks when he
is not being understood.

It is easy to mistake the age, sex, or intelligence of a newsgroup
poster. This is particularly true when you add in people whose first
language is not English.

In face to face communication WHO said something is very important. It
is easy to lose track in newsgroups.

On the other paw, you can always get a word in edgewise no matter how
long winded someone else is, and nobody can shout you down.

Then there is the matter of stage fright. People who would never say
boo in public will fearlessly tackle anyone in a newsgroup even in
front of hundreds of readers.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Branimir Maksimovic

2005-10-22, 6:57 pm

"Andrew McDonagh" <news@andrewcdonagh.f2s.com> wrote in message
news:dje1s5$2d2$1@news.freedom2surf.net...

>
> Are you talking about Frameworks for multiple teams or about multiple
> developers on a single team each separately developing a 'framework' then
> merging into main line for the rest of the team to use?

Both. In reality both cases can happen when applying chaotic development
style.

Gretings, Bane.

Branimir Maksimovic

2005-10-22, 6:57 pm

"Andrew McDonagh" <news@andrewcdonagh.f2s.com> wrote in message
news:dje1ja$278$1@news.freedom2surf.net...
> Branimir Maksimovic wrote:
>
> By Framework - I took you to mean that you created some Generic
> infrastructure for your application, that is also specific the type of
> application you are developing - as in JBoss, JavaMail, Etc...

Yes.

>
> If I'm wrong - can you explain a bit what you do mean by Framework.

Necessary work to be done in order to provide module integration
and testing, also there belongs skeleton code implementing
different design patterns. A library if you want.

>
> If the customer needs an app that reads stock market info and sends them
> an email when ever their own stocks value starts to drop, then we don't
> need any framework for this.
>
> If the customer then wants us to add in the ability to send them an SMS
> text msg instead of an email - we MAY decide that we need a generic
> Messaging Transport framework of some kind or we may NOT - there is only
> two message transports to be used - the 'framework' at this point is an
> 'IF' statement or polymorphic call at best.
>
> If the customer added a third message transport type (web page updates,
> Carrier Pigeons, Motorcycle Dispatches etc) then it is usually prudent to
> use a framework.
>
> But right in the beginning - it just sent emails - so we didn't need a
> generic Messaging Framework.
>
> Is that a good enough example?
>

What I can say. You can work in any way you like.
This type of development is not good for larger programs.
For small ones no problem you can change on the fly, but....
adding features always depends on how flexible the design is.

> please don't mis-understand me - I'm not anti-framework, I'm just against
> prematurely-introducing-frameworks. I've seen to many projects be months
> late because the team thought they needed to have a framework in place
> BEFORE they could do anything, rather than INTRODUCE a framework later
> when they really do have a need.

Oh, they didn't know how to do it. First, scatch design, then make framework
interface, then develop features , then integrate and test in framework.
OO is designed to simplify things. You don't need finished
framework in order to write usefull code.
Framework should be written only *once* and later just adapted
for other projects.
It goes pretty fast. Even you can do this: one team can write framework
other
payload code.

Greetings, Bane.

Andrew McDonagh

2005-10-22, 6:57 pm

Branimir Maksimovic wrote:
> "Andrew McDonagh" <news@andrewcdonagh.f2s.com> wrote in message
> news:dje1ja$278$1@news.freedom2surf.net...
>
>
>
> Yes.
>
>
>
>
> Necessary work to be done in order to provide module integration
> and testing, also there belongs skeleton code implementing
> different design patterns. A library if you want.
>

Oh yes Design Patterns - another favorite. With many issues as
Frameworks. I do actually love patterns - think they are great - so
much so that I mentor people in them.

I also show them that they are useful when needed - but not before.

Now, 'when needed' might be straight away - or might be a years time.

>
>
>
> What I can say. You can work in any way you like.
> This type of development is not good for larger programs.

Our experience is different - what can I say.

> For small ones no problem you can change on the fly, but....
> adding features always depends on how flexible the design is.
>
>
>
>
> Oh, they didn't know how to do it. First, scatch design, then make framework
> interface, then develop features , then integrate and test in framework.

Well they all had very experienced people on them going about it very
much as you describe - though how long was spent on each of those stages
was different per team. Different as in some scratched the design,
others spent a long time fine tuning, and others somewhere in the middle.

They were still late because everyone of them had frameworks that were
over engineered for the actual purpose of the the current feature sets.

producing code/frameworks/libraries for future use or because things
changed that meant they weren't used as much as expected - is waste in
the Lean Six Sigma sense.

> OO is designed to simplify things.

Simplify over what?

>You don't need finished framework in order to write usefull code.
> Framework should be written only *once* and later just adapted
> for other projects.
> It goes pretty fast.

>Even you can do this: one team can write framework other payload code.
>
> Greetings, Bane.
>

I have - with mixed results.

On teams where there was poor inter-team communication and common goals,
it failed miserably every time we integrated.

On teams where there was great inter-team communication and both teams
shared common goals (as in my current work place) it works great.

Like I said - I'm not against frameworks.

Branimir Maksimovic

2005-10-22, 6:58 pm

"Andrew McDonagh" <news@andrewcdonagh.f2s.com> wrote in message
news:dje3ki$33s$1@news.freedom2surf.net...
> Andrew McDonagh wrote:
>
>
> snipped...
>
>
> oh WRT 'anti-framework' here's a very funny post on Joel-on-software...
>
> http://discuss.joelonsoftware.com/d...oel.3.219431.39
>
> "....Actually, we don't sell hammers at all.
>
> So...
>
> According to our research, what people really needed wasn't a Universal
> Hammer after all. It's always better to have the right kind of hammer for
> the job. So, we started selling hammer factories, c...."

Good one ! :)

puzzlecracker

2005-10-22, 6:58 pm

Branimir Maksimovic wrote:
> "Andrew McDonagh" <news@andrewcdonagh.f2s.com> wrote in message
> news:dje3ki$33s$1@news.freedom2surf.net...
>
> Good one ! :)

This thread becomes uncontrolled, off-topic, off-subject, and full of
subjective opinions that no one in their rational mind can give weight
to.

In short, most of above is a plain exercise in futility. After all,
this is a C++ group and not who-can-bull-shit-more group!

enough SAID, for I am doing and perpetuating above with deterrent
intentions.

Branimir Maksimovic

2005-10-22, 6:58 pm

"Andrew McDonagh" <news@andrewcdonagh.f2s.com> wrote in message
news:dje62v$41j$1@news.freedom2surf.net...
>
> Oh yes Design Patterns - another favorite. With many issues as
> Frameworks. I do actually love patterns - think they are great - so much
> so that I mentor people in them.
>
> I also show them that they are useful when needed - but not before.

I don't understand this? There exists programs that don't use not even
single
design pattern? I didn't mean the Design Patterns. Well yes design patterns
are the Design Patterns, sometimes not.

>
> Now, 'when needed' might be straight away - or might be a years time.

One always know what patterns would be needed in current project
and add them to library as necessary. I didn't said that framework has
to be swiss knife or some kind of perfection. This is impossible.
You are actually describing well known anti pattern.

>
> Well they all had very experienced people on them going about it very much
> as you describe - though how long was spent on each of those stages was
> different per team. Different as in some scratched the design, others
> spent a long time fine tuning, and others somewhere in the middle.
>

So I see. They just over complicated things.

> They were still late because everyone of them had frameworks that were
> over engineered for the actual purpose of the the current feature sets.

That is another matter. Framework shouldn't be over complicated.
In the begining it can just provide small interface not much of a code
but yet usefull and evolve in time.
One designs framework by current need with extensions in mind.

>
> Simplify over what?

I don't understand. It is designed to make code maintenance more flexible.
Therefore abstract interfaces and all that stuff. This is simply THE tool
and invitation for writing frameworks. I've started with procedural
languages untill I found OO. Now I need less much time to achieve
tasks then before.
Problem is now that many people overcomplicate things, more
then necessary :)

Greetings, Bane.

Branimir Maksimovic

2005-10-22, 6:58 pm

"puzzlecracker" <ironsel2000@gmail.com> wrote in message
news:1130015127.156480.276130@o13g2000cwo.googlegroups.com...
>
>
>
> This thread becomes uncontrolled, off-topic, off-subject, and full of
> subjective opinions that no one in their rational mind can give weight
> to.

Hm, there exists such thing as objective opinion? If there is a
such thing that would be sum of all subjective opinions divided by
number of opinions. :)

>
> In short, most of above is a plain exercise in futility. After all,
> this is a C++ group and not who-can-bull-shit-more group!

Well, there is comp.lang.c++.moderated, but then again this topic
was started as crosspost so original message could be
successfull troll.

Greetings, Bane.

Phlip

2005-10-22, 9:56 pm

Robert C. Martin wrote:

> Daniel Parker wrote:

>
> Smalltalk vs. Cobol? That's a no-brainer. XP vs. Waterfall? That's
> also a no-brainer. Working with Kent? No-brainer.

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

Now instead imagine the decision between an average legacy project
(test-free), and a legacy project built via clean and expressive unit tests.

No brainer.

--
Phlip
[url]http://www.greencheese.org/Z

Land[/url] <-- NOT a blog!!!

Daniel Parker

2005-10-23, 7:56 am

"Phlip" <phlipcpp@yahoo.com> wrote in message
news:oyC6f.1292$8W.673@newssvr30.news.prodigy.com...
>
> Greenfield vs legacy? Imagine if all else was equal...
>
> Now instead imagine the decision between an average legacy project
> (test-free), and a legacy project built via clean and expressive unit
> tests.
>
> No brainer.
>
You mean like C3 today? Just kidding. But the choice that you'd like to
see isn't usually the choice confronting a new entrant into the programming
world. Maintenance programmers typically work on a branch off the main line
and their job is to fix production bugs and address the needs of the day.
The main development line is usually happening elsewhere.

I agree with the call to extend automated acceptance test coverage. Many IT
shops are way behind there, and could benefit from that enormously.

-- Daniel

Daniel Parker

2005-10-23, 7:56 am

"Branimir Maksimovic" <bmaxa@eunet.yu> wrote in message
news:djdm9c$eq7$1@news.eunet.yu...
>
> What you would do if they assign you a task you couldn't accomplish?
>
It's the technical lead who needs to know the answer to that question. Back
when I ran small teams that had to do things, staffed with young programmers
who didn't know how to do them, I would give something to someone and the
important thing was that they made progress, not that they necessarily
finished the task. If they took it to 80 percent, perhaps with some
guidence, someone more senior could step in and finish it off. Leads have
to know their resources and what they can do. It's an extremely valuable
skill to learn how to accomplish something when you don't know how to do it,
it's a good thing to be in an environment where you can experience that. At
one time all companies had to do a lot of things internally, and everbody
had to learn. Now they don't have to do as much, they get used to buying
things, and many seem to have forgotten completely how to build anything.

-- Daniel

Thad Smith

2005-10-23, 7:56 am

pauldepstein@att.net wrote:

[Regarding discussions of a post inquiring whether it is normal
for a new programmer to only do maintenance]

> Well, I found the original posting very offensive, and I agree 100%
> with those who replied with personal criticisms of the poster and
> called the OP "self-centred" etc.

If you aren't pulling our leg, I think you are being too easily offended.

> The original posting was _wildly_ OT for this _c++ language_ newsgroup.

Agreed.

> And it's incredibly pompous of this individual (the OP) to assume not
> only the right to employment, but the right to be intellectually
> challenged by the work.

The OP struck me as naive with respect to programming careers, not
pompous. If you are taught to write new programs, you naturally expect
to get a programming job writing new programs! I think the better
description of his circumstance was probably surprise and some
frustration. Perhaps it is time to revamp the education of those
heading into programming to better prepare them for maintenance.

Thad

Andrew McDonagh

2005-10-23, 7:56 am

Branimir Maksimovic wrote:
> "Andrew McDonagh" <news@andrewcdonagh.f2s.com> wrote in message
> news:dje62v$41j$1@news.freedom2surf.net...
>
>
>
> 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

2005-10-23, 6:58 pm

On Sun, 23 Oct 2005 02:27:32 GMT, "Phlip" <phlipcpp@yahoo.com> wrote:

>Robert C. Martin wrote:
>
>
>
>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: unclebob@objectmentor.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

Phlip

2005-10-24, 3:57 am

Robert C. Martin wrote:

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

--
Phlip
[url]http://www.greencheese.org/Z

Land[/url] <-- NOT a blog!!!

David Lightstone

2005-10-24, 7:57 am

"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
news:qk4ol1p0e0he0hrccoqi3ao5qjjmfsqgr3@
4ax.com...
> On Sun, 23 Oct 2005 02:27:32 GMT, "Phlip" <phlipcpp@yahoo.com> wrote:
>
>
> 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?

>
> -----
> Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.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

Patrick May

2005-10-24, 7:57 am

"David Lightstone" <david._NoSpamlightstone@prodigy.net> writes:
> "Robert C. Martin" <unclebob@objectmentor.com> wrote:
[ . . . ][color=darkred]
> 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

------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
pjm@spe.com | (C++, Java, Common Lisp, Jini, CORBA, UML)

Mark McIntyre

2005-10-24, 6:58 pm

On Sun, 23 Oct 2005 18:01:35 -0500, in comp.lang.c , Robert C. Martin
<unclebob@objectmentor.com> wrote:

>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...
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Phlip

2005-10-24, 9:56 pm

Mark McIntyre wrote:
>
>
> 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.

--
Phlip
[url]http://www.greencheese.org/Z

Land[/url] <-- NOT a blog!!!

Richard Bos

2005-10-25, 3:56 am

"Phlip" <phlipcpp@yahoo.com> wrote:

> 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

Phlip

2005-10-25, 3:56 am

Richard Bos wrote:

[color=darkred]
> It is never a good idea to take metaphors more seriously than reality.
> That way lies Microsoft Bob.

What about the patron saint Bob of the Church of the Subgenius? (The ones
that named their Nirvana "Slack" in the late 70s or so, folks..)?

--
Phlip
[url]http://www.greencheese.org/Z

Land[/url] <-- NOT a blog!!!

William

2005-10-25, 7:01 pm

"Phlip" <phlipcpp@yahoo.com> wrote in message
news:M2l7f.1852$jV2.1533@newssvr17.news.prodigy.com...
> Richard Bos wrote:
>
>
>
> What about the patron saint Bob of the Church of the Subgenius? (The ones
> that named their Nirvana "Slack" in the late 70s or so, folks..)?

What do you mean "in the late 70s"? It's never gone away.
http://www.subgenius.com/

Praise Bob! -Wm

2005-11-07, 10:00 pm

"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
news:qk4ol1p0e0he0hrccoqi3ao5qjjmfsqgr3@
4ax.com...
>
> 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

2005-11-07, 10:00 pm

"Patrick May" <pjm@spe.com> wrote in message
news:m23bmrnn0w.fsf@patrick.intamission.com...
>
> 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

2005-11-07, 10:00 pm

"Roedy Green" <my_email_is_posted_on_my_website@munged.invalid> wrote in message
news:0mkgl1lvqfviqp0f4ulg9fff431gk9g054@
4ax.com...
>
> 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

2005-11-07, 10:00 pm

On Sat, 05 Nov 2005 21:32:10 GMT, <adaworks@sbcglobal.net> wrote,
quoted or indirectly quoted someone who said :

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

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Patrick May

2005-11-07, 10:00 pm

<adaworks@sbcglobal.net> writes:
> "Patrick May" <pjm@spe.com> wrote:
>
> ... 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

------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
pjm@spe.com | (C++, Java, Common Lisp, Jini, CORBA, UML)

2005-11-07, 10:00 pm

"Walter Roberson" <roberson@ibd.nrc-cnrc.gc.ca> wrote in message
news:dja5i9$bn0$1@canopus.cc.umanitoba.ca...
>
> 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

2005-11-07, 10:00 pm

On Sun, 06 Nov 2005 15:21:16 GMT, <adaworks@sbcglobal.net> wrote,
quoted or indirectly quoted someone who said :

>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
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Benji

2005-11-07, 10:00 pm

In comp.lang.java.programmer Roedy Green <my_email_is_posted_on_my_website@munged.invalid> wrote:
> 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.

--
Of making better designs there is no end,
and much refactoring wearies the body.

David Lightstone

2005-11-07, 10:00 pm

"Roedy Green" <my_email_is_posted_on_my_website@munged.invalid> wrote in
message news:5m3tm15bisp6hhju1kcrib4cq35hq652ue@
4ax.com...
> On Sun, 06 Nov 2005 15:21:16 GMT, <adaworks@sbcglobal.net> wrote,
> quoted or indirectly quoted someone who said :
>
>
> 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.

> Canadian Mind Products, Roedy Green.
> http://mindprod.com Java custom programming, consulting and coaching.

2005-11-08, 3:57 am

"Roedy Green" <my_email_is_posted_on_my_website@munged.invalid> wrote in message
news:grsil15krossfr96b6njemefpge4809te6@
4ax.com...
> On Fri, 21 Oct 2005 21:54:25 +0100, Andrew McDonagh
> <news@andrewcdonagh.f2s.com> wrote or quoted :
>
>
> 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@web.de

2005-11-08, 3:57 am

> 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

2005-11-08, 3:57 am

On Tue, 08 Nov 2005 06:51:12 GMT, <adaworks@sbcglobal.net> wrote,
quoted or indirectly quoted someone who said :

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

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

David Lightstone

2005-11-08, 7:57 am

<ecky-l@web.de> wrote in message
news:1131433285.994471.113240@z14g2000cwz.googlegroups.com...
>
> 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.

>
> Eckhard
>

Robert M. Gary

2005-11-08, 6:58 pm

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

2005-11-08, 6:58 pm

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

2005-11-09, 6:59 pm

Robert M. Gary wrote:

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

--
Phlip
[url]http://www.greencheese.org/Z

Land[/url] <-- NOT a blog!!!

Robert M. Gary

2005-11-09, 6:59 pm

> 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@gmail.com

2005-11-09, 9:57 pm

Robert M. Gary wrote:

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

--
Phlip
[url]http://www.greencheese.org/Z

Land[/url] <-- NOT a blog!!!

David Lightstone

2005-11-10, 7:57 am

<phlip2005@gmail.com> wrote in message
news:1131588771.163239.41750@g49g2000cwa.googlegroups.com...
> Robert M. Gary wrote:
>
>
> 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

>You start by adding more tests and passing
> the existing ones, and that makes the maintenance much easier.
>
> In theory!
>
> --
> Phlip
> [url]http://www.greencheese.org/Z

Land[/url] <-- NOT a blog!!!
>

Robert M. Gary

2005-11-10, 6:59 pm

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

2005-11-10, 6:59 pm

<phlip2005@gmail.com> wrote in message
news:1131588771.163239.41750@g49g2000cwa.googlegroups.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.

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

pete

2005-11-10, 6:59 pm

adaworks@sbcglobal.net wrote:
>
> <phlip2005@gmail.com> wrote in message

> In theory.

In theory, theory and practice are the same.
In practice, they're different.

--
pete

2005-11-11, 9:56 pm

"pete" <pfiland@mindspring.com> wrote in message
news:4373D076.3F7@mindspring.com...
> adaworks@sbcglobal.net wrote:
>
>
> In theory, theory and practice are the same.
> In practice, they're different.
>
That was pretty much my point.

Richard Riehle

scottf3095@aol.com

2005-11-11, 9:56 pm

[color=darkred]
>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"

kevindotcar@gmail.com

2005-11-11, 9:56 pm

Walter Roberson wrote:
> In article <1129792428.032878.177440@g47g2000cwa.googlegroups.com>,
> <apngss@yahoo.com> wrote:
>
>
> As others have noted, it is quite common to put new people onto
> maintenance.
>
Yup- for good reason, too- less risk (you can always go back to
the prev. version :-)

> One of the posters suggested that this was training so that people
> would learn the value of writing good maintainable code. Posters
> might also have suggested [but haven't yet in my timeframe] that it
> was an opportunity to give the new programmer a good understanding of
> the project as a whole.
>

Not to be cynical (...and I am a -very- cynical person :-) but I
don't think corporations are interested in "developing" programming
talent anymore... All programmers are pretty much all on equal footing
nowadays; we're all expected to be experts.... The old "Programmer
Analyst I/II/III thing is a relic- we're all "IT Consultants" now.

> These two factors certainly apply, but there is another factor which
> is often more important: maintenance is given to the new programmer
> because in most power relationships, you give the unwanted tasks to
> those who don't have the power to effectively refuse them.
>
Thiry years ago I called this "Electro-political engineering" :-) And I
thank you for bringing it up, because I thought *I* was the only person
this happened to!

> In -every- programming environment i have worked in, the young
> new programmers have chomped at the bit, eager to *write programs*,
> and frustrated when they aren't given a program to write within a matter
> of days. I have often seen new programmers upset that they aren't
> creating new programs yet; often they would at least -say- that they
> were thinking seriously of quiting because "this isn't what I
> hired on for!" And most of them held that resentment of doing
> maintenance (or even real formalized design specs), and pushed their
> managers to rush into -new- -code-. Quite a few of them thereafter
> refused to do maintenance as soon as they had accumulated enough
> internal political capital to make it stick.
>

WOW- does this still happen? Although I'm technically a
Perl/Java/VB/SQL guy, I go back to what my COBOL teacher told me in
1976: "...Programming is a service profession..." And nothing more;
If someone provides a service that's economically better than what
they're paid, everyone will be happy.

> I've heard much the same thing from other people I know who are
> in the software industry: most programmers really dislike code
> maintenance -- even if it is their own code that is being maintained!
> Most do not even like to do feature or design changes to their
> existing code, not unless the change is clearly to add something "new".
>

Again, you shock me. ... I enjoy this best of all- If I can add
something that adds value to something I've already done, it makes me
feel that another round of evolution has taken place... The program
is, in a sense, actually "living" within an organization.

[---]

> ... For a disorganized program of any
> real size, it requires someone who is patient and an excellent mental
> modeller, able to simultaneously hold in mind -many- program aspects
[---]
> what does not fit. My experience suggests that the portion of
> such people is less than 1 in 100 programmers; I'm not even confident
> that as many as 3 in 1000 are good at this kind of work.

I don't know if your stats are correct, but you bring up a really good
point-
There is a certain amount of personal character involved with building
any professional specialization... Many times, programmers live by a
zeitgeist that is actually just a personal belief... The most common
is "develop or stagnate..." And because of this, I've seen programmers
cause a lot of damage along their professional paths by not learning
to "live" for awhile with what they created...

Namaste,

kevin

xpyttl

2005-11-12, 6:59 pm

> 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

2005-11-12, 6:59 pm

On Thu, 10 Nov 2005 22:49:24 GMT, <adaworks@sbcglobal.net> wrote:

>
><phlip2005@gmail.com> wrote in message
>news:1131588771.163239.41750@g49g2000cwa.googlegroups.com...
>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: unclebob@objectmentor.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

Sponsored Links