in reply to Re^4: Reinvent the wheel!
in thread Reinvent the wheel!

In my experience, the needs of a production system often tend towards minimal changes to keep things running.

Now I see our mismatch.

I try to get my projects into production as soon as possible, providing the most essential, most minimal features possible to be useful to customers. From there, I prefer rapid iterative development guided by prioritized requests and feedback.

It sounds like your production code isn't under active development, but rather minimal maintenance. I can see how you'd find that rather underchallenging.

Replies are listed 'Best First'.
Re^6: Reinvent the wheel!
by tilly (Archbishop) on Mar 24, 2009 at 00:09 UTC
    Standard industry estimates are that 80% of software costs come during the maintenance phase. Maintenance in this case is definitely not what you'd call "active development". So in the long run we can expect 80% of developer time to be spent on stuff that is in what you'd consider minimal maintenance.

    Using agile incremental methodologies does not change this fact. Because no matter how wonderful your development process is, at some point the client is going to say, "OK, this is good enough, we don't want to pay for continued active development." And so you start leaving a trail of code that is in use but is no longer under active development. But that code is not perfect, and someone is going to wind up with the job of poking and prodding it along.

    If history is a guide, we will always have more under challenged programmers than over challenged ones. Which means that there is a real potential opportunity from finding ways to help bored programmers improve their skills.

[reply]
      Using agile incremental methodologies does not change this fact.

      It certainly does. Agile, incremental development pushes almost 100% of the cost of software into the maintenance phase.

[reply]
        That depends on how you define "maintenance".

        To me if you're actively building new features, that's not maintenance, that's development. The fact that people are using the software as you're developing it doesn't change the fact that it is under development. You obviously use the term "maintenance" differently.

        What I'd call "maintenance" is roughly equivalent to what you were calling "minimal maintenance" earlier. Granted, there is more of a gradual decline here rather than a bright dividing line. But the distinction is real.

        In that state a project needs much less development. But software stays in that state for much longer periods of time - frequently decades. And when bugs come up, the maintainer likely has not seen the relevant code in a long period of time, which makes everything that much more difficult to deal with. These two factors together are what causes so much aggregate expense in software which is changing at a glacial pace.

[reply]
Re^6: Reinvent the wheel!
by gwadej (Chaplain) on Mar 23, 2009 at 20:46 UTC

    I guess I still wasn't clear. Many of the projects I've worked on have been in relatively active development for 10-15 years. Even with new features being added daily, (not just minimal maintenance) a code-base like this needs more care and feeding in much of the work.

    New features in these cases require more knowledge of current libraries and code and less knowledge of the language and new techniques. Some decade-old design decisions may limit the directions you are allowed to go. I've seen many fellow programmers forget that these decisions are an artifact of the current system and not an absolute of programming. Over time, this can erode your ability to do basic programming unless you work to practice the basics.

    When I can, I truly enjoy working on new projects where I can use the latest best practices and the newest libraries. However, much of the work I'm paid to do has limitations that prevent that.

    G. Wade
[reply]

In Section Meditations