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'm currently maintain a large project with more than 100000 LOC. The code use the MFC as its framework, in genral, it only has interface part which heavily use the mfc api and a business logic part which full of bad code, confusing logic. The company has some small features delivered to the customer each year(most features are adding code to exisiting project, finding some reference of some api or variable and it' s no different with fixing 3-4 bugs ), most of the tasks are to resove issue and optimize performance . Like other company with maintaining position, it value people who knows much logic about its product. There are people who can quickly finish the job on such project, is it worth to train myself like such a programmer? Is there benifits to work on such project for a long time?

share|improve this question

closed as primarily opinion-based by gnat, Bart van Ingen Schenau, GlenH7, Kilian Foth, MichaelT Nov 13 '14 at 16:49

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

One major benefit is that it will teach you how to quickly and efficiently work on projects with "bad code".....because for the majority of developers in the world, you're going to need to be able to do that for the rest of your career. –  James P. Wright Dec 7 '12 at 16:43
imo, you learn more from working on bad code than you do from working on good code. You get to experience first hand the consequences of bad code, and learn to avoid those mistakes. –  GrandmasterB Dec 7 '12 at 16:47
The real world has lots of ugly code and so programmers who want to the work in the real world will need to learn the skill of dealing with code that isn't good. Being the guy who can take a mudpile of poorly designed code and deliver releases, or beter yet, refactor it into something better, can be very lucrative. –  Steven Burnap Dec 7 '12 at 17:34
Lets keep things civil everybody. Rudeness will not be tolerated. Thank you. –  maple_shaft Dec 7 '12 at 17:49
When you are faced with 100k lines of bad code and a deadline in a couple weeks, being able to balance a bit of refactoring and a bit of just "making it work" is a good skill to have. –  Steven Burnap Dec 7 '12 at 17:53

6 Answers 6

up vote 1 down vote accepted

Do you mean a long-term benefit to your career? It depends. If your mission is to bring the monster under control, maybe. Then you can become proficient all the techniques in Michael Feathers' Working Effectively with Legacy Code, and sell yourself as a consultant who can clean up messy code, in general.

But if your mission is to keep it working while changing as little as possible, then no. Instead of learning generally applicable skills, you will spend your time learning every detail of this mess, while it slowly degenerates further. Your market value will gradually decrease because you won't have any opportunity to apply new technology. Eventually the application will become unmaintainable, and the development of the replacement will be outsourced.

BTW, 100K SLOC really isn't very large. It should be possible to refactor this extensively in a year or so.

share|improve this answer

Getting in the habit of just making it work quickly and move on is a bad habit to have and leads to stagnation. This does not, however, mean that you should take the opposite tack and demand full rewrites. The ability to incrementally improve code as you get things done is good to have.

What I've tried to do in these situations is use deadlines as a time box to work in. If I have a month to do the task but I can do it in two weeks, I get the rough outline of the work done as fast as I can and then spend the rest of my time cleaning up as much as I can. The goal isn't to fix everything. The goal is to always leave things better than you found them.

The trouble with full rewrites is that they often take longer than you expect, which means you'll miss deadlines. And as you miss deadlines, you will be given fewer and fewer opportunities to refactor, and will become too rushed to accomplish anything. I've seen large-scale rewrites attempted and watched them fail because of time constraints, leaving the original code in an even worse state, and with the developers looking bad in the eyes of management. On the other hand, I have very successfully used the incremental approach, improving the code while meeting deadlines. The more deadlines I met, the more freedom I got from management to fix the mess.

Being a "just fix it" guy, never improving anything is a trap. There is a reason that we call it "bad code". "Bad code" is hard to work with. It creates schedule risk and makes schedules longer. Refactoring is an investment. By improving the code now, you shorten the schedules later. This is why the incremental approach can work well. Each phase makes the next phase easier.

In terms of long-term career benefit, there are really two things to consider. Delivering on-time gives you a reputation. Working with modern technologies makes your resume look good. I'd say the danger sign career-wise isn't that the code you are working on is bad, but rather the code you are working on is old, and therefore unlikely to give you a leg-up in the future.

share|improve this answer

You state yourself that there is value to it

Like other company with maintaining position, it value people who knows much logic about its product. There are people who can quickly finish the job on such project

However, that being said, it depends if you want to be a maintainer your whole career or be a developer. All code has bugs, so being able to find those and correct them quickly is VERY valuable. But, making that your career goal is not a mindset that makes developers. So, working on this project for a "long time"(being a couple of years) is not beneficial when you could be implementing your own projects. There is no substitute to writing your own code. Which will have bugs that you need to find and then correct and later optimize as you grow into being a strong developer.

I do NOT want to downplay the importance of those skills but spending an inordinate amount of time and not creating anything unique that can stand on its own will be detrimental.

Software Development requires you to be a good proof reader but that does not mean you ARE a proof reader. You are first a Software Developer and proof reading is just a tool at your disposal.

share|improve this answer

Bughunts matter, bad code is kinda awesome for that, 100k lines is a bit rough, all things considered.

Good part is that when you find a bug -log the cause-. A person who isn't clearing their variables at the right time will make the same type of error elsewhere.

Then you find the copious work spent poorly implementing a feature found in the STL..

You find 200 lines of a function that are just convoluted stream of thought coding.

Creating objects when functions are the right choice, forcing OO where it has no place.

After a while you have a black book of horrid things that are done to make bad code. This should have some notes on how to spot them.

Then look at your older code and figure out how to change your thought process to not make the same kind of mistakes.

Good luck!

share|improve this answer

One positive thing I can think of is "boredom". Boring can be good sometimes.

Once you have learned everything you need about the project, may not have to learn much new and you can relax and "just do your thing". I think it's a bad career choice, but if you are near the end of your career it may be the right choice for you.

What I would do is work on something new and interesting, and learn as little as possible about that huge ugly beast. Boredom sucks ;)

share|improve this answer
So you are kind of saying... If you are going to die soon, spend your remaining days in hell? –  Jason Sebring Dec 7 '12 at 18:22
No. Hell is just a perspective. Working on crappy code can be enjoyable if you have the right attitude. Stagnation can be preferable to learning new technologies if you're tired of learning. –  Minthos Dec 7 '12 at 18:48
OK, I understand what you mean. I just don't see boredom and stagnation as a positive thing as its not conducive to expanding your mind or learning new things as the older you are, the more you need this type of thing to keep your mind sharp and life interesting. The natural course of things is to become dull without this push similar to the effects of exercise on the overall health of a person. –  Jason Sebring Dec 7 '12 at 18:56

Working on this type of project is the opposite of what someone would do at Google. At Google, someone would be working on cutting edge experimental cool stuff, they are learning a ton of useful knowledge and are getting a lot of praise for it. At this position, you are learning about bad code that is a spaghetti rabbit hole. There is 0 innovation and creativity but lots of frustration and hair pulling.

I like having hair and I like feeling creative and happy. I also enjoy making lots of money which goes along with that as opposed to being under appreciated.

Hasn't Jeff Atwood already given us enough knowledge as to avoid needing to learn what not to do in terms of coding?

Seems like an easy one to choose from.

share|improve this answer
There is lots of value in seeing how it can be done wrong, if for no other reason than it teaches you very clearly the "whys" of why things aren't done that way. Sometimes when you get a room full of developers without that sort of experience, you end up with some very common mistakes. –  Steven Burnap Dec 7 '12 at 17:37
We have Jeff Atwood to tell us about these things already. Why must we work at a place which embodies bad practices to appreciate good ones? This is madness. –  Jason Sebring Dec 7 '12 at 17:43
@emeraldcode.com who maintains the code written in google? –  upton Dec 8 '12 at 12:53
@upton, I'll rephrase since you were the one asking. My point is not to say maintenance is bad. My point is to advise you the best way I know from my experience of moving forward so much faster than my piers and making so much more money than all my piers from college. I chose creativity and passion and fun over boredom and drudgery. It inspires your everyday and your brain and wallet will thank you for it. –  Jason Sebring Dec 8 '12 at 17:13
An analogy is that one touts the enormous benefits of "living in a dust-free world (i.e. cleanroom)", in which vacuum cleaners has no purpose to serve, even though the real world is still full of dust. We understand those benefits but also understand that the real world (business software) is slow to change. –  rwong Dec 9 '12 at 23:45

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