In my experience, the needs of a production system often tend towards minimal changes to keep things running. I've known many people who eventually reach a point where they don't really program as much as they serve the system.

This can involve extreme knowledge of the various libraries and configurations needed by the production system, and a loss of basic programming ability. (In some cases, this can be so extreme that they can no longer write a standalone program.

This may very well be a function of my particular career experience.

I find that working outside production environments allows me to exercise a different set of programming muscles. This also allows me to try things that might fail where the risk is lower.

I find this kind of programming practice both a good exercise and a good way to learn new things. It also helps me re-examine basic assumptions once in a while to keep them from solidifying into personal dogma.

I have also used reinventing the wheel, on purpose as a kind of Kata to practice approaching problems from a new direction.

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.

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.

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