most software jobs are software maintenance rather than new development?

Discussion in 'C Programming' started by apngss, Oct 20, 2005.

  1. apngss

    apngss Guest

    This topic should apply to software jobs regardless of the programming

    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

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

    Please advise. thanks!!
    apngss, Oct 20, 2005
    1. Advertisements

  2. No its normal, at least in my experience. New development is much more
    interesting of course, but you likely to need a little more experience
    before you get given jobs like that.

    Not relevant to you (I'm sure) but I heard a funny phrase recently, a
    newbie programmer was given a couple of Java classes to develop from
    scratch. After a while he delivered these new classes and promptly got
    taken off the project because his code had 'logic issues', he's bug
    fixing now.

    John Harrison, Oct 20, 2005
    1. Advertisements

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

    Andrew Thompson, Oct 20, 2005
  4. 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
    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, Oct 20, 2005
  5. apngss

    Ross Bamford Guest

    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, Oct 20, 2005
  6. apngss

    xpyttl Guest

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

    xpyttl, Oct 20, 2005
  7. apngss

    Phlip Guest

    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, Oct 20, 2005
  8. As others have noted, it is quite common to put new people onto

    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.
    Walter Roberson, Oct 20, 2005
  9. apngss

    Roedy Green Guest

    Chairman Mao used to insist bureaucrats spent a few weeks 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 weeks a year maintaining code so
    they would learn what you need to do to write maintainable code and
    what makes code unmaintainable. See

    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.
    Roedy Green, Oct 20, 2005
  10. apngss

    BigBrian Guest

    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.
    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.
    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. )
    BigBrian, Oct 20, 2005
  11. 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'
    Andrew Thompson, Oct 20, 2005
  12. apngss

    Greg Comeau Guest

    When I was a manager years ago, I used to take Friday's off.
    That meant, in addition to meetings, design etc through the week,
    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, Oct 20, 2005
  13. apngss

    Greg Comeau Guest

    Greg Comeau, Oct 20, 2005
  14. apngss

    bugbear Guest

    As long as the changes are small, and the original
    code nicely modular - yeah, you can do what
    I have heard called "peephole development".

    Unfortunately, this activity degrades the overall
    quality of the code (including modularity) over time.

    Eventually, more significant refactoring is required,
    which may require more skill/insight/experience.

    bugbear, Oct 20, 2005
  15. 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:
    Object Mentor Inc. | blog:
    The Agile Transition Experts | web:

    "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, Oct 20, 2005
  16. 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

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

    Robert C. Martin (Uncle Bob) | email:
    Object Mentor Inc. | blog:
    The Agile Transition Experts | web:

    "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, Oct 20, 2005
  17. apngss

    Mark P Guest

    Your idea of taking the day off involves a lot more work than my idea of
    the same. :)
    Mark P, Oct 20, 2005
  18. Most programming jobs are (were or should be)
    advertized as "programmer/analyst".
    A programmer develops new code.
    An analyst tries to understand and maintain existing code.

    The reason that you got stuck maintaining old code
    is that there is no proper documentation
    so you are obliged to read it and "reverse engineer"
    the original design from the code itself.
    How's it going? ;-)

    The problem with compelling new programmers
    to analyze and maintain old code is that
    they inherit bad habits from the original author.
    You shouldn't be finding and fixing bugs
    if the original code was any good.

    If you really want to be a programmer,
    ask your supervisors if you can re-write the bad code.
    If they won't let you do that, consider moving on.
    There are lots of really good jobs for Java programmers.
    E. Robert Tisdale, Oct 20, 2005
  19. apngss

    BigBrian Guest

    If you really want to be a programmer,
    Ah, that appears to be the tendency for many novice programmers doing
    maintenance. Yes, sometimes code needs to be re-writen, but IMHO,
    novice programmers are more likely to suggest it than seasoned experts.
    IMHO, sometimes managers really do make the right decision. Many times
    their decision is based on business information that the programmer
    doesn't have or doesn't understand. Moving on for something like this
    is childish, IMHO.
    BigBrian, Oct 20, 2005
  20. apngss

    . Guest

    As people have pointed out, there is more maintenance work out there then
    there is new development. I've heard people claim there is 4 times more
    people doing maintenance then there is doing new development. I think it
    is even higher than that.

    Right now I'd say my site has 50 developers and 40 of them are doing
    maintenance or enhancement requests.

    The thing you have to realize is that putting a new programmer onto new
    development is just asking for trouble. As you do your maintenance you
    will notice that coding decisions some people have made creates a tonne of
    problems for you. The hope is that after having dealt with other people's
    code for a while, you will know what not to do when you finally are given
    the chance to do new development.
    ., Oct 20, 2005
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.