62

I have worked in software development for over 10 years now, and it's dawning on me that I rarely get to create anything "new". I realize that "new" is a vague term, but I would define it as anything from an obvious new large-scale project to a new large feature in an existing project (say something that would require some thought into its design, and that might take 2 weeks or more to complete). Maybe a rough guideline is something is new if it requires a written spec. I think most programmers know what I'm talking about - you're in the zone, writing a ton of code at a fast pace.

Anyway, thinking back to what I've done, I'd estimate that less than 10% of my time is spent on "new" work. There are things like "adapt this existing system to work in this new environment", which certainly requires a lot of planning, but the actual coding and "new stuff" comes down to making tiny changes in many places throughout the code. Likewise for small feature requests - if I know what to do, these can often be finished in under an hour, and if I don't, it's just a lot of reading code and figuring out what to do (which frustrates me because I learn much better by doing, not by reading).

In general I feel like I am not really creating anything most of the time. I kind of assumed that this was the case at most places - a new product would come out rather quickly and at that point everyone would be excited and banging out the code at a fast pace, but then once live it moves into maintenance mode, where few of the subsequent changes would be considered "new & creative".

Am I wrong? Am I accurately describing most programming jobs, or do most programmers feel like they are often creating new things?

Improve this question
15
  • 11
    @JamieTaylor Translated into your metaphorical terms, the question is: Is it typical to always be fixing someone else's Lego model and to rarely create a new one?
    – Caleb
    Apr 16, 2012 at 16:03
  • 22
    @Joe, hah! So you are the guy producing all those !*#@*&!% legacy systems we are to maintain forever?! ;-P
    – Péter Török
    Apr 16, 2012 at 16:15
  • 14
    @Joe, yes I do, thank you very much. Maybe if you could write just a tad more unit tests, I would be fully content :-)
    – Péter Török
    Apr 16, 2012 at 16:20
  • 8
    @Joe, that brings to mind the old adage, which I haven't found particularly apt - that is, up to now: "always code as if the next guy taking over your code were a dangerous psychopath who knew where you live" ;-)
    – Péter Török
    Apr 16, 2012 at 16:51
  • 11
    @JonMcdonald It shouldn't be depressing - no job is all roses, and maintenance of an existing codebase is possibly the fastest way to gain experience and improve your skills as an engineer. Spending time on maintenance will help you understand and avoid all the typical mistakes which lead to unmaintainable code in the first place, and will help you appreciate things which you otherwise probably wouldn't care about such as static code analysis and automated unit test creation.
    – Ben Cottrell
    Apr 16, 2012 at 21:32

16 Answers 16

Reset to default
66

A great deal of software work is maintenance. No hiring manager will actually tell you this, of course, but it's certainly the case.

Improve this answer
5
  • 13
    This is likely true, but maintenance is still really important, and can be intellectually challenging as well sometimes :)
    – joshin4colours
    Apr 16, 2012 at 19:05
  • 3
    There is absolutely nothing wrong with maintenance. But people find it less glamorous, so job descriptions tend to downplay it.
    – Scott C Wilson
    Apr 16, 2012 at 19:22
  • By maintenance you mean making the software perform as required by the ever-changing specification. Maintenance as a concept only applies to hardware and other things that can randomly break down due to physical factors. Software isn't maintained, it's redesigned and refactored.
    – user7433
    Apr 17, 2012 at 14:25
  • 3
    @omouse - sometimes yes, but sometimes it's just fixing blatant bugs in the implementation to meet the original specification. But you're right - a variety of activities are covered under the rubric of "maintenance."
    – Scott C Wilson
    Apr 17, 2012 at 14:36
  • @omouse, redesign and refactoring have meanings too and do not cover things we generally call "mantainance". If some software uses a now deprecated function, or an external api changes, the thing you're going to do is neither redesign nor refactoring.
    – cbrandolino
    Apr 17, 2012 at 20:08
59

Yes, your perception is accurate. It's an absolute truism that far more time, money and effort is spent on maintaining systems than on creating new systems. So obviously, the time allocation of most programmers is going to reflect that.

Part of the reason for this is that a lot of people, when they get to do "new & creative", they do it badly, so that maintaining the system is hard (this is especially likely if they've never done maintenance themselves - nobody who has constantly worked on small greenfield projects can really claim to be competent).

Another (probably bigger) reason is that most systems are designed to be continually useful, not just for an one-off event. So they keep getting used for much longer than it took to develop them. But during that time, requirements change (and are added to) due to changes in legislation, in the market, in research, in the users, whatever. And that means maintenance work.

Improve this answer
4
  • 15
    +1 for "nobody who has constantly worked on small greenfield projects can really claim to be competent"
    – mattnz
    Apr 17, 2012 at 0:25
  • 1
    What is "a small greenfield project"?
    – Vivian River
    Apr 17, 2012 at 18:37
  • @RiceFlourCookies: Greenfield is a term for a work endevour that is completely new. In this case, a project started from scratch.
    – Steven Evers
    Apr 17, 2012 at 19:16
  • @RiceFlourCookies and while small is relative, projects that can be done by one person could reasonably be considered small.
    – Scott C Wilson
    Apr 18, 2012 at 1:22
24

Legacy systems are the successful ones. They survived the initial development process where 50% of projects fail (even after success has been redefined!). They survived a changing business environment. They probably survived about ten proposals by young naive programmers to re-write the whole thing in Java or whatever was trendy at the time. They were lucky enough that whatever department, company or agency that the software was serving survived the various budget cuts, reorganizations, mergers etc.

Probably less then 5% of the software written will still be running ten years later.

So rather than moan about this see it as a privilege to work on such a Darwinian success story and an opportunity to learn what works in the real world and why.

Improve this answer
4
  • 8
    ...or they survived because there was someone with enough decision making influence and with a hidden interest in keeping the legacy mammoth going for 10 or more years, like securing his job, pension, or just being too incompetent and his skills being too outdated to find a new job
    – Marek
    Apr 17, 2012 at 10:37
  • @marek it can indeed be both.
    – nicolas
    Apr 17, 2012 at 11:46
  • 8
    The fact that something survives doesn't mean that it's optimal or even good. It only means that it's "good enough" that nobody has put it out of its misery yet. The major selective force in nature is competition; when there's little competition, you can get some pretty screwy organisms. Competition works in software, too, but internal systems usually don't have much competition. The result is that internal systems are often screwy to the max.
    – Caleb
    Apr 17, 2012 at 16:30
  • @Caleb -- As a general rule systems where the developers listened to the users and locked down the requirements survive. No matter how badly written! Systems where the developers are trying to match the latest design pattern, implementing the latest fads and obsessing over their indentation don't make it to the first release. Working code always beats pretty, buzzword compliant code.
    – James Anderson
    Apr 18, 2012 at 10:58
14

The term that's often used for new projects that aren't dependent on older development is greenfield project. You may occasionally see the term in job listings -- knowing that you get to start from scratch rather than inheriting somebody else's failed endeavor can make a job more appealing.

Successful software projects generally spend a lot more time being maintained than they do being built as new projects, so it's not at all surprising that you don't get to do a lot of completely "new" stuff.

Also, creating something completely new is a lot of work. Even on a greenfield project, you'll probably choose a number of tools to help you: platform, compiler, frameworks, libraries, etc. As soon as you make those choices, you've imposed certain constraints on your project. That's not to say that you're not doing new work anymore, only that "new" is a relative term here. It's not a big step from there to see adding a feature or module to an existing project as "new" even though you wouldn't call it a greenfield project.

Improve this answer
2
  • 7
    "somebody else's failed endeavor" -- legacy systems are the Darwinian success stories, failed projects don't get maintained!
    – James Anderson
    Apr 17, 2012 at 2:41
  • 2
    @JamesAnderson Point taken, but technical success isn't the only selective force in the software ecology. Who hasn't seen the half-finished dog of a project that's important to managers but deemed too far along to start over?
    – Caleb
    Apr 17, 2012 at 15:48
6

It depends on what work you seek out.

I have only once worked for a pure software product company where I worked on their single gold-plated application in a small start-up team.

Otherwise I have worked for technology companies that needed software to support their internal R&D or outside products.

The upside is I get to build complete start-finish products and pretty much build what I want. Sometimes you can also try newer technologies than if you were stuck adding features to a existing market leading application.

The downside is that you are part of the cost, not part of the product. So I have had projects canned because 'we aren't doing software"/"software isn't core business" = it's amazing how companies think they can sell a $100 K machine tool with no software to operate it!

Improve this answer
4
  • It also amazes me how companies think that they don't need a custom solution to their custom problem, and that a million rows of 278 columns each can be easily and quickly manipulated in excel, instead of a db.
    – Spencer Rathbun
    Apr 16, 2012 at 17:34
  • @SpencerRathbun What amazes me even more than that is when you give them an estimate to build the custom software they immediately begin to question you and ask, "Isn't their free open source software that can give us custom X feature for free?"
    – maple_shaft ♦
    Apr 16, 2012 at 18:41
  • 7
    @maple_shaft what's even more fun is when they say "we can buy X for $10K and this general purpose solution will perfectly fit our custom problem with no set up! BTW you will be in charge of getting it up and running and all problems/bugs with the software we bought are your fault."
    – Spencer Rathbun
    Apr 16, 2012 at 19:13
  • 3
    @SpencerRathbun You win, that is the worst situation to be in.
    – maple_shaft ♦
    Apr 16, 2012 at 21:02
5

Rather than seeing legacy code as continually cleaning up someone else's mess, look at it as an opportunity to work on a lot of new projects.

Think about it, every new feature added to a system is a small project within itself. You still need to apply the entire SDLC in order to ensure you have completed the job properly. Sure, you are likely given a specification for the feature, but usually the fine detail has been left up, so it is up to you to analyse the problem as shown, design the best method to apply the change, test it, code it, and then release it back to your version control system, and quite possibly maintain it in the future.

It's been my experience that you don't often get to work in a completely green field, and often when you have been lucky enough to do so, you will be expected to see the project through a good portion of it's maintenance and perhaps even for the lifetime of the product, or for the entire time you are with a given employer. This is because your intimate experience with a product means that you become a knowledge repository, and it can be seen as costly to move you on to other things. When you start on an existing product, it is because the employer has recently lost a resource or needs more resources on the project, and they business needs to ensure it doesn't make too great a loss on the investment it has made in its software. That is the reality of being a software engineer.

I've worked in IT for nearly 22 years with the last 15 as a Software Developer, and in that entire time I've only created about 5 new products, with most of my time either maintaining those products long term, or maintaining someone else's product. Each has given me challenges and problems to solve, and each has been treated not as simply a big project that I am merely a part of, but also as a HUGE series of micro-projects to complete.

It's amazing how a little mental calisthenics can totally change your perception and enjoyment of the daily work that you do. ;-)

Improve this answer
4

I think many software development jobs involving improving an existing product or adapting existing code to a new customer or market.

This isn't really 'maintenance'. For example, VMWare just released version 8, it's a major upgrade to their main product. I suspect few of the developers who did this work were there when the first line of code for VMWare was written. They built their major upgrade on the code written by guys who long since moved on.

Over in the Workplace Beta there is a question about how Google's 20% personal project system works.

I am sure that Google figured out that the best developers want to be there at the creation of new software products and will eventually tire of years of adding small features and tweaking gui's for the next point release.

By having the 20% projects I speculate that Google developer won't mind staying to improve Google's projects since he or she can still have the fun of being there at the start of something new.

Improve this answer
2

You will spend your time creating new functionality and changing the functionality of existing code in order to conform to the new specification.

Others are calling that maintenance but that's a horrible term. It's a redesign and a refactoring or re-coding of the software to make it conform to a new idea of what the program should do.

Improve this answer
2

I would say it depends on the company you work for.

My first job was an accounting software firm whose major product was an ERP system, competing at about the same level as Great Plains or Peachtree (as in you moved up to it from QuickBooks, or sideways when you got tired of GP's obfuscated schema or whatever you thought was wrong with PT, then you moved up out of the tier altogether into a package like SAP). That job was 99.99% maintenance, defined as fixing bugs and adding "small stuff", without fundamentally changing the way the software worked or what it could do. I left the company when the CEO wanted to do a page-one rewrite of the system, which would have been cool except he insisted on several design features that are clear anti-patterns, such as inner-platform (allowing a high degree of customization of the program by basically giving the customer a dumbed-down VS Designer, and customizing business rules by providing an expression language).

My next job after that was a contract firm that did "turnkey development"; the system the customer spec'ed was built from the ground up, hardware and software, then at the completion of the project it was all turned over to the client who could either maintain it themselves or retain the company's services for a monthly fee. My job was in development of one of these major projects, and so while I worked there pretty much everything I'd done hadn't existed before I started. Even then, development is inherently iterative; you're always adding to what you already have (even if what you have is nothing), and you have to avoid and fix regression problems (new stuff breaking old stuff). And once the project moved into "warranty" status, new functionality was complete and we were expected to fix any defects the customer found during their UATs.

My current job is back to in-house development, for a security company which uses video monitoring and audio feedback to provide alarm signal verification and other "virtual guard" services. This field is growing quickly and still developing; new equipment enters the market all the time, new customers are signed up who want us to do new things, and existing products no longer meet adapting UL and government regs. 99% of this job is "integration"; writing new software that never existed before, to make one new but pre-existing piece of equipment or software work with another probably older pre-existing piece of equipment or software, so that we can do new things with both.

Improve this answer
1

I'd say it depends very much on the nature of your role.

I'm part of a small team and as such, have to maintain and support everything I create.

5 years ago most of what I did was "new" - now I'd say maintenance of existing code takes up at least half of my time, with a further 25% being "new" versions of existing systems.

But if you worked solely as a developer with a team to take on maintenance and support after you release your code then technically everything would be "new". If you can find a job where maintaining your own code isn't required, take it!

Improve this answer
1

  1. It depends how danger is your job position: ;-)

    If you work for a new company that develops a new products with a high risk that the company is going to survive, you probably create some great new products.

    If you work for an old company that have a stable position on the market, it is more likely you will code in maintenance mode ;-) .

  2. The creation of new software is always very tempting. The truth it is hard to do this in a right way. Doing maintainable code is not a trivial task.

    If you think on these tons of aspects you must ensure to write good code: proper logging, proper monitoring and statistics acquiring, descriptive design that is efficient and helps even unfamiliar people to involve in your project, documenting, automatic testing and test driven developments.

No many people are doing it right so we must maintain their code and polish it to the proper state. ;-)

The good news is if you are in the company long enough, you can have an influence how new code is written :-)

Improve this answer
1

Whether you primarily do maintenance or not is at least partially under your control. In my case, most of my work for the past 15+ years has been new development. This is because I seek out jobs that let me do new development. I am not a contractor, and I genenerally don't do web development. I have almost always worked for small employers, and I usually work in niche areas (desktop GUI development, QA tools, developer tools, vertical markets).

I've also seen and experienced first hand that the best programmers on a team typically (though not always) get the best jobs. So, focus on being the best programmer at your company and you'll start to see new development come your way.

Improve this answer
1

Maintenance development is a difficult task, harder in many ways than new development. In my experience employers like to keep a developer doing maintenance, especially if they are good at it. Finding good maintenance developers in legacy technologies is harder than finding someone who can work with the latest tech.

I've worked at a company which was divided into a product team, which was all maintenance, and a project team, which was all new development. There was great developers on both sides, but the maintenance guys were definitely more specialised and used legacy tech.

Could I make a suggestion that you push back and ask for some new development work? And if your employer only does maintenance then maybe you need to move on?

Improve this answer
0

I would say that it depends on a lot of factors. Where do you work, what sort of products do you make, how is your team organized, etc.

The four years that I've worked at my company, I would say 70-80% of my time is spent creating something new. Probably 50-60% of that is spent on large projects that is entirely new code, while the rest of that time is spent on enhancements to current functionality.

Part of that I know is how my company works. Not everyone in my development team spends this much time building new functionality. There are a number that focus their time in nothing but bug fixing/hunting. If it is a brand new piece of functionality or they need help, then it gets kicked over to me to investigate. In general though, that small team of bug hunters is what allows the larger group of developers to press on without interruption.

Improve this answer
0

I've been working almost three years as the only developer in a company that used QuickBooks and Excel and nothing else when I started. Now we've got a Windows Forms application, a SharePointsetup, SQL Server + Reports, an Excel add-in and an Outlook add-in.

Just today, I setup for the first time a ticketing system because I lost the ability to manage email requests at a rate that kept users from complaining, so I view this is a sign that I've entered maintenance mode.

My previous jobs have been more like what the others have posted, but I figured I'd throw in my atypical experience just because it goes to show you never know what the next job will bring. I'm exhausted, but the amount I've learned on this job has been worth the work.

Improve this answer
3
  • Maintenance mode happened a long time ago... You just now need tools to help you.
    – user1249
    Apr 17, 2012 at 13:19
  • i'm glad i don't have feelings because they might be hurt by having the only answer on this thread to have negative points :(
    – Aaron Anodide
    Apr 17, 2012 at 18:09
  • Well, you don't answer the question asked.
    – user1249
    Apr 17, 2012 at 18:52
0

Some larger organizations like the Company I work for have a policy of decommissioning software after a number of years, perhaps because the development language it was written in is no longer used (Delphi anyone?), or the platform is being replaced (Windows XP), or regulatory requirements demand it. E.g. two tier programs that talk directly to a database are now being decommissioned in favour of three tier that use Kerberized connections for greater security.

Users still need that original functionality, and so a completely new version using the current state of the art techniques gets developed.

Expect a 5-7 year replacement cycle for this type of thing. Eg by 2020, I expect the WPF (Client)/Java (server) software I'm writing now will be old tech and being replaced by something newer.

Improve this answer

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