Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I burned out last year (after a decade of fulltime programming jobs) and am on a sabbatical now. With all the self-examination I've started to figure out some of the root causes of my burnout, and one of the major ones is basically this: there was never any real closure in any of the work I've ever done. It was always a case of getting into an open-ended support/maintenance grind and going stale.

When I first entered the industry, I had this image of programming work being very project-based. And I expected projects to have a start, beginning, and END. And then you move on and start on something totally new and fresh. Basically I never expected that a lot (most) of software work involves supporting and maintaining the same code base for open-ended long periods of time - years and even decades. That, combined with generally having itchy feet makes me think that burnout is inevitable for me, after 2-3 years, in ANY fulltime software job.

All this sounds like I probably should have been a contractor instead of a fulltimer. But when I discuss this with people, a lot of them say that even THEN you can't really escape having to go back and maintain/support the stuff you worked on, over and over (eg. Coming back on support contracts, for example). The nature of software work is simply like that. There is no project closure, unlike in many other engineering fields.

So my question is - Is there ANY programming work out there which is based on short to mid term projects/stints and then moving on cleanly? And is there any particular industry domain or specialization where this kind of project work is typical?

share|improve this question
11  
Closures are available in most languages, the main exceptions being C++ and Java. ;) –  Mason Wheeler Feb 3 '11 at 23:11
1  
C++ has closures now. –  Crazy Eddie Feb 4 '11 at 0:11
1  
And Java has had them ever since anonymous inner classes. (Yes, anonymous inner classes do closer over their lexical environment.) –  Jörg W Mittag Feb 4 '11 at 1:54
    
@Jörg: But in a very ad-hoc way. –  FredOverflow Feb 4 '11 at 10:05

7 Answers 7

up vote 4 down vote accepted

Although contractors will be brought in on support contracts from time to time, there are a number of practical realities that would tend to prevent you from being in an indefinite maintenance mode.

  1. At the end of the engagement where the application was built, one of the deliverables is almost always documentation that would allow one of the client's employees to maintain the system. Frequently, there is a training phase where you're doing the knowledge transfer so that the client can support the system. No client wants to be in a position where they're permanently dependent on outside contractors to support one of their enterprise systems.
  2. If you're at a larger consulting company, even if there is a support contract, it's unlikely that the same consultants would be assigned to the project indefinitely unless that's what you wanted. It's relatively easy for the consulting company to tell the client "We're going to bring in New Guy to take over for Bobby Tables on the Foo maintenance contract. Here's our plan for the knowledge transfer" particularly when the contract is being renewed every N months. The large consulting company always has people on the bench so they should be able to bring a new person in if there are other contracts that you'd be better suited/ more interested in.
  3. If you're at a boutique consulting company, there may not be someone on the bench or coming off a prior engagement to transfer responsibility to, but it's also less likely that the client is going to want the boutique firm doing long-term maintenance. They're generally hiring the boutique firm at higher rates for their expertise in some area-- that area is very unlikely to be application maintenance. And the boutique firm has a greater incentive to keep you happy because they don't have a deep bench to replace you so if you hate something, they're likely to work hard to avoid making you do too much of it.

A software development company tends to have far fewer developers that are doing real "maintenance" tasks than a non-IT company's internal IT department. If the company is developing and selling a product, it's far more likely that the developers are going to be focused on projects that are adding significant new functionality (which drives new sales) rather than focusing on small bug fixes (which benefits current customers but doesn't drive sales). Internal IT departments don't generally have any new customers they can go after so there is much less push to add significant functionality as opposed to fixing bugs and fiddling around the margins. Of course, you'll have to fix bugs in a software development company and you'll likely work on the same code base on many projects, but it's a very different feeling when you're building the new FizBuzz module as part of Product 3.0 rather than tweaking the internal purchasing app to allow users to enter comments with their receipts.

share|improve this answer

Minigames. A project lasts one to six months and often requires support only shortly after launch. Coming back to write a sequel would be the main cause of lack of closure.

I did also once do a computer-assisted interviewing project which hasn't required any maintenance whatsoever since I trained the client on how to use it, but I can't generalise from that one project because it's the only one I've done in that field or for that client.

share|improve this answer

I find that I can gain "closure" from small scripts and plugins. Those sorts of projects tend to be self-driven because I have a need for it, but even when they're not I try to make sure I have a set number of goals/features. Once I've met those features, the plugin/script is complete.

I'm primarily a web-dev, so working on themes for other people's wobsites can also provide closure.

No matter what, there will always be those "small" projects that explode into something bigger, and I've never had a "big" project shrink into something smaller.

I would propose the following requirements for gaining a sense of "closure" in a project:

  • Well defined goals
  • Well defined features
  • Reasonable timeline
  • Allows for modularity
  • Allows for simplicity
  • Luck

If you don't know what the goals or features are supposed to be, you wont know when you've met them. If you do know what the goals are, but the due date is too far off, you'll have delays and likely never actually complete the project.

If the project is modular, you can come to a completion point, and then choose to work on a new module/plugin/feature, which allows you to feel closure at the initial project, and then again when the feature is completed.

If the code turns into spaghetti due to feature-creep/goal-changes, you'll lose more from stress than you ever will gain out of closure.

Finally, the most important feature is luck. Some projects are lucky, where you get to incorporate all the right parts in all the right ways. Others aren't lucky, where the client is a jerk, you break your wrist, and your computer gets bricked.

share|improve this answer

I don't think there really is closure on most software because software, as long as someone is using it, is a living document and there will always be things that can be fixed or improved.

However, project-based work does tend to be defined in beginnings and endings. And you are probably on the right track by thinking about the contracting angle. As a consultant in a specialty niche, you will have opportunities to have finite time periods on delivery projects. The software will reach a point that will likely still have much room for continued work, but consultants doing the first phase of delivery usually move on. In this way, you can keep moving from assignment to assignment, getting exposure to new projects and people (think Accenture or EDS). There is a steady run of change although that doesn't mean the experience will always be good (think Accenture or EDS).

Ideally, it'd be nice if companies understood the developer need to be challenged and to learn so that a full-timer could have a rich career without having to move around. In a good company there would be an effort to support education, keep interesting projects coming through the pipe, and find ways to better manage support and maintenance work. But I'm finding that lots of companies don't invest time in succession planning, which is really too bad. Good developers that aren't challenged eventually will move on, as it appears you have.

There are some good companies that understand what you want (I read wistfully of them in the annual Computerworld's Best 100 Companies to Work for issue). But these are far and few in between; most seem locked in the vicious cycle of releasing absolutely crappy internal apps, then being satisfied by spending forever on production support.

I think I agree with the others here on general advice. If you can get into a good company that develops its internal resources, great. Otherwise, look at consulting, a software-focused company, or work in an R&D role. The other thing you could do is move toward project management, but that will take you away from coding.

share|improve this answer

What you want is a more R&D oriented position where you develop a proof of concept and someone else handles the details of productizing it. You need to work for a software company like Microsoft where there is a position called Program Manager. Basically the Program Manager is the voice of the customer. He creates code that shows how he expects the customer to use it, and hands it to the team to refine (that's the watered down version read Sinofsky's blog to learn more about it).

The simple fact is, in industry, most development is maintenance. If you want to develop new stuff, you need to join a software company. And even then you're not guaranteed to have green fields all the time. But you'll have more opportunity to do so.

share|improve this answer

Please note that the following is generalizations, based on my experience, and I expect there to be exceptions.

Have you been working primarily at small companies? Or companies in non-software industries?

Large companies (Microsoft, Amazon, Google, etc.) tend to have lots of different teams, and it is normal and encouraged for employees to move around from team to team when they get bored (this helps transfer skills and experience throughout the company). People are rarely called back to help their previous team fix up old projects. I know at Microsoft it was normal for a product to be released, and then half the team would look for another product team to move to while the other half would hang around for the next release.

Contracting at large companies also has never resulted in me being called back, and rarely does for anyone I know, either (I can think of a PM who was an exception). There is always another skilled, smart person who can slide into your place in a large company.

Of course, large companies have other issues. But they do allow a large variety of experiences.

I find that agile teams (my experience is with Scrum) tend to have more of a sense of movement and closure. While you might be working on the same product, new features are added every sprint. You might try looking for an agile team that has a really good grasp on how to manage sprints to get that feeling of closure and movement. These will often be smaller companies that have a lot of momentum or web-focused companies that release new features regularly.

I also see evidence that some non-software industry companies tend to attract devs who want something more like our parents' world of working 40 years in a single job, then getting a pension. These companies may value loyalty more than expertise or passion, and that's what they get. Software industry companies - especially those started by techies, run by techies - seem to expect employees to get itchy feet after a year or two, and see that as a sign of passion, ambition, and a desire to be challenged. If you are expected to wear business casual to the interview, that's a sign that your "itchy feet" will likely be understood. If you are expected to wear a tie (or skirt), be concerned.

Ultimately, "getting into a grind" and "going stale" is usually mostly the result of poor management, poor feedback to your manager, and / or poor code. Poor management causes this when you are given too much work for deadlines or not enough support for your work, and you are unable to write maintainable code or find yourself working crazy hours to cope. Poor feedback to your manager causes this when you either don't complain about your manager's mistakes, or don't let your manager know that you are getting bored and need new challenges to keep your skills fresh. Poor code causes this by being hard to maintain, leaving you less time for interesting work. You might want to take a little time to think over your past experiences and figure out which of these caused your problems and how you can mitigate that problem in the future.

share|improve this answer

You don't burn out because the project doesn't end or is in indefinite maintenance mode you burn out because you're working unmaintainable hours or not having a balanced life. You say you had itchy feet, so I'm guessing you moved jobs and surely didn't have to touch code from previous employer after that so had a fresh start?

Maintenance mode (often indefinite length of time) for a project is quite normal, but it need not be stressful.

In my experience the only projects that are released and finished with are those that fail.

share|improve this answer
    
I think I actually DO burn out because of indefinite maintenance mode. I guess that part is basically just a recycled version of my linked question. What I'm trying to work out is if there is any type of software work which is naturally limited, and based on projects that have full closure. –  Bobby Tables Feb 3 '11 at 23:08
    
@Bobby edited my answer by adding an extra line at the end/ –  Alb Feb 3 '11 at 23:12
1  
+1 - When a project ENDS, it has failed. I guess one could seek out projects that they don't believe in or that they believe are doomed to fail, but I don't think I could sleep at night. –  jmort253 Feb 4 '11 at 6:52

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.