×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

How To Deal With 200k Lines of Spaghetti Code

Soulskill posted about a year and a half ago | from the make-sure-it's-al-dente dept.

Programming 236

An anonymous reader writes "An article at Ars recaps a discussion from Stack Exchange about a software engineer who had the misfortune to inherit 200k lines of 'spaghetti code' cobbled together over the course of 10-20 years. A lengthy and detailed response walks through how best to proceed at development triage in the face of limited time and developer-power. From the article: 'Rigidity is (often) good. This is a controversial opinion, as rigidity is often seen as a force working against you. It's true for some phases of some projects. But once you see it as a structural support, a framework that takes away the guesswork, it greatly reduces the amount of wasted time and effort. Make it work for you, not against you. Rigidity = Process / Procedure. Software development needs good processes and procedures for exactly the same reasons that chemical plants or factories have manuals, procedures, drills, and emergency guidelines: preventing bad outcomes, increasing predictability, maximizing productivity... Rigidity comes in moderation, though!'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

236 comments

...no (4, Funny)

Anonymous Coward | about a year and a half ago | (#40884743)

no comment...

Re:...no (3, Interesting)

wmac1 (2478314) | about a year and a half ago | (#40884985)

In several iterations, disentangle and break the code into smaller and more understandable chunks.

After breaking the code into smaller chunks clean them up (code conventions, algorithms, ...) and reorganize as needed.

Re:...no (4, Insightful)

DJRumpy (1345787) | about a year and a half ago | (#40885201)

I disagree. For 200K lines of code, You immediately start a new project to produce the next major release of said code.

200,000 lines of code is a large project, but very do-able for even with a small team or one person. Although you could go in an attempt to tighten up code in smaller chunks, the very fact that this code was written over the course of many years, probably by many authors and styles, means it probably follows no standard to general layout, declarations, etc. (hence the spaghetti).

I would simply support what's there with only a break-fix policy, and immediately start documenting all aspects of it's functionality to rebuild it from the bottom up. The very fact that this code would have so many styles would mean most of it would have to be re-written and documented anyway.

Document the functionality, re-implement with standard code to guidelines, include any feature enhancements that may exist, release new version.

Re:...no (1)

Stormthirst (66538) | about a year and a half ago | (#40885241)

What's more, there may well be libraries to do some of the functionality. According to the article, it's written in G2 which is all but obsolete. Find a modern language that more closely matches G2's functionality and move to that.

Re:...no (2)

kestasjk (933987) | about a year and a half ago | (#40885281)

It depends what sort of thing it is, how complex it is, whether the software is the kind of thing that can be tested easily or if the rules are embedded in the spaghetti, etc, etc.

One person given 200KLOC of complex spaghetti to rewrite though, if with little documentation outside of the code, and software that doesn't lend itself to automated testing, where the spaghetti logic is of consequence to the business.. that could be a very, very long project (years, easily).

Re:...no (2)

DJRumpy (1345787) | about a year and a half ago | (#40885343)

Yes and no. Part of the complexity of a new program is missing here. The full functionality is mapped out, albeit they will have to have to glean some functionality from the code and most from the end users. That's a huge boon as long as the end users can effectively comminicate or demonstrate that functionality.

In short, the map is already written and scope creep can be largely minimized with some proper expectations and management.

Re:...no (1)

eugene ts wong (231154) | about a year and a half ago | (#40885297)

Hi. What is a "break-fix policy"? I skimmed through the first page of Google's results, and Wikipedia had nothing.

Re:...no (4, Informative)

DJRumpy (1345787) | about a year and a half ago | (#40885495)

A break-fix policy is simply stating you will support code to fix any breaks in functionality, while denying any enhancement requests. In short, the only changes you make to the old code would be to fix production issues.

It lets you focus efforts on implementing new code while avoiding supporting enhancements on the old code.

Re:...no (3, Insightful)

Rockoon (1252108) | about a year and a half ago | (#40885307)

Isnt this how Netscape died?

Re:...no (1)

Anonymous Coward | about a year and a half ago | (#40885579)

Netscape failed because they failed to get the open source community to commit to the project, and management failed to set proper guidelines ( the rigidity mentioned in TFA).

You have to have proper expectations, milestones, a project map. You can't 'wing' these things, which is similar to the rigidity TFA mentions.

In this case, they have a controlled group of actively engaged people who are interested in doing things the 'right' way, rather than 50 different voices all claiming they know the right way. It makes a huge difference.

Good luck with that (2, Insightful)

Anonymous Coward | about a year and a half ago | (#40885819)

Your employer probably isn't interested in spending the time and money on a re-write. Nor are the clients going to be interested in waiting that long for new features, either.

You will be made to figure it out and add features, or you will be shown the door.

Re:Good luck with that (0)

Anonymous Coward | about a year and a half ago | (#40885885)

Read TFA. This is a group of people who appear to be interested in getting it done correctly, and understand that the current code is largely unworkable for ongoing maintenance and future enhancements. Although they don't appear to have a clear idea about the best approach to fix it, they do appear to be willing to do things properly.

They've recently learned some hard lessons about the consequences of nonexistent configuration management. Their maintenance efforts are also greatly hampered by the vast accumulation of undocumented "sludge" in the code itself. I will spare you the "politics" of the situation (there's always politics!), but suffice it to say, there is not a consensus of opinion about what is needed for the path ahead.

They have asked me to begin presenting to the team some of the principles of modern software development. They want me to introduce some of the industry-standard practices and strategies regarding coding conventions, lifecycle management, high-level design patterns, and source control. Frankly, it's a fairly daunting task and I'm not sure where to begin.

Farm out OP writing, too. (1)

Impy the Impiuos Imp (442658) | about a year and a half ago | (#40884767)

I advise rigidly farming it out.

Re:Farm out OP writing, too. (0, Redundant)

Anonymous Coward | about a year and a half ago | (#40884825)

This. The worst impediment to productivity is not lack of "processes", but idiots who don't know how to do the job so instead try to tell other people how to do it.

Good developers know how to untangle (or simply reimplement) bad code. And then they document their work going ahead. They with their team develop a method to suit the particular application.

If someone says something like "agile" or "extreme" or "rigid" or "process" or "productivity" then you know that they're interested in everything but actually getting the job done. In the best case, they're just trying to make some money for themselves. In the worst case, they actually believe what they're saying. "Efficiency" drives in the public sector are even worse than in the private sector, FWIW - targets are always simplistic and their achievement does not necessarily mean that things are working any better than before.

Re:Farm out OP writing, too. (3, Interesting)

symbolset (646467) | about a year and a half ago | (#40884927)

I advise printing it out and posting it in the hall in printed form, annotated with contributors. Paper the walls with it. You would be surprised how much more efficient that makes a coder even if it's not ever read.

Also, for debugging sometimes you have to get down on the floor with 50 pages of fanfold and work it out. Decorum be damned. A PC only has so much vertical resolution and sometimes you need more than to peek at the code through a sliding window.

Re:Farm out OP writing, too. (1)

h4nk (1236654) | about a year and a half ago | (#40885161)

I have totally done this. I use hightlighter markers to identify chunks of purpose/responsibility/function per file and then set to refactoring with UML and CRC cards. Usually it's a complete rewrite, but you may be able to make slight refactorings and iterate over the code as releases go out.

read this book:
http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672 [amazon.com]

CRC cards:
http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card [wikipedia.org]

Re:Farm out OP writing, too. (2)

Sulphur (1548251) | about a year and a half ago | (#40885483)

I advise printing it out and posting it in the hall in printed form, annotated with contributors. Paper the walls with it. You would be surprised how much more efficient that makes a coder even if it's not ever read.

Also, for debugging sometimes you have to get down on the floor with 50 pages of fanfold and work it out. Decorum be damned. A PC only has so much vertical resolution and sometimes you need more than to peek at the code through a sliding window.

You can also flip through fanfold like a book and see two pages at a time with an option to turn several pages at once.

"Cobbled together over 10-20 years . . . ?" (5, Insightful)

PolygamousRanchKid (1290638) | about a year and a half ago | (#40884773)

Wouldn't that be Linux? It seems to work fine for me.

If something has become spaghetti over 10-20 years, then no one cared that it became spaghetti over 10-20 years. And it will still be spaghetti over the next 10-20 years. Fixing something like this requires a commitment from management, which means money. If the management of the project aren't convinced that cleaning up the development process is worth the initial investment for the long term, then they choose to deal with the constantly higher costs forever.

Something like this makes me think that this is one of those problems that get pushed off for someone else to deal with later. And the next person perpetuates this, by doing the same.

Don't put up with it. (0)

Anonymous Coward | about a year and a half ago | (#40884903)

I'd rather be homeless than be in charge of a project my boss doesn't really care about. Talk about the fast track to nowhere. Even if by some maricle you do pull it together, nobody will know or care.

Re:Don't put up with it. (3)

rmstar (114746) | about a year and a half ago | (#40885049)

I'd rather be homeless than be in charge of a project my boss doesn't really care about. Talk about the fast track to nowhere. Even if by some maricle you do pull it together, nobody will know or care.

If things go well, your bank account will know, for example.

What does it even mean "my boss doesn't really care about" a project? Is his vision somewhere else, but has given you the job of guarding the crucial machinery on which everything else builds?

(And being homeless sucks badly, by most accounts.)

Re:"Cobbled together over 10-20 years . . . ?" (0)

Anonymous Coward | about a year and a half ago | (#40884905)

Linux is pretty well-written and widely documented (because so many people use it). Compare it to some first year CS students' project code and you'll see what I mean. Extrapolate the latter to 10-20 years of development: that is spaghetti code.

Re:"Cobbled together over 10-20 years . . . ?" (1, Insightful)

sourcerror (1718066) | about a year and a half ago | (#40884953)

The really frightening tought is that there are many 40 year old first year CS students.

Re:"Cobbled together over 10-20 years . . . ?" (3, Insightful)

Anonymous Coward | about a year and a half ago | (#40885167)

When I was taking my 2nd degree in Computer Science years ago, there was quite a few mature students. They are actually doing well in class in spite of other distractions in life such as family.

There was nothing wrong with people deciding to learn new things or switch career later in life. Are you biased or just like to discriminate people for their age?

I would think that matured people are more suited for computer science as they are not as much distracted by the new "Shiny" new thing that comes along and constantly have to redo things not because they don't work, but they are not the "latest and greatest".

Re:"Cobbled together over 10-20 years . . . ?" (-1)

Anonymous Coward | about a year and a half ago | (#40885257)

Are you biased or just like to discriminate people for their age?

He's probably American - ergo bias and discrimination are his first amendment rights - along with racism, sexism. Etc. It's the curse of the first amendment - they're thinking is stuck in the 17th century.

Re:"Cobbled together over 10-20 years . . . ?" (1)

Anonymous Coward | about a year and a half ago | (#40885305)

I think that wasn't meant literally. It's more like that there are many 40 year old who still write code as if they were 1st year CS students.

Re:"Cobbled together over 10-20 years . . . ?" (1)

Sulphur (1548251) | about a year and a half ago | (#40885517)

Are you biased or just like to discriminate people for their age?

He's probably American - ergo bias and discrimination are his first amendment rights - along with racism, sexism. Etc. It's the curse of the first amendment - they're thinking is stuck in the 17th century.

Our former mayor was fond of saying that "people don't suffer in silence."

Why? (1)

Anonymous Coward | about a year and a half ago | (#40885219)

The really frightening tought is that there are many 40 year old first year CS students.

Why?

It's not like they're wearing a Speedo in class or anything.

Re:"Cobbled together over 10-20 years . . . ?" (1)

Anonymous Coward | about a year and a half ago | (#40884971)

Usually because of budgets. I love the courses in college that tell you how you should do something to make maintenance easier but then ignore the real world contraint of time and money (probably the most underrepresented part of making software). Making something with care takes more time (and therefore money) thank hacking something together. Sometimes a lot more, but always at least a noticeable amount. And rewriting 200k lines of code, no matter how you do it (refactoring or complete rewrite from the ground up) is not going to be cheap. Unless the current program directly and obviously causes a perfect shitstorm, that's just not likely to happen. Sure keeping it increases cost every quarter, but even if you could accurately quantify the increased cost for this, it won't be as much in any quarter or year as fixing the entire problem, and while fixing the problem NONE of that budget is actually adding new end user features. So under most conditions you are asking for something that the users of the software won't even be able to see when you finish, and managers will only be able to see several months after you finish, and only if they look back AND can accurately figure out how much faster you were able to add new features and how much less time you spent fixing problems.

Re:"Cobbled together over 10-20 years . . . ?" (3, Insightful)

gl4ss (559668) | about a year and a half ago | (#40884983)

would fixing it to not be spaghetti be any better though? would fixing it to be really non-confusing depend on changing real world processes of clerks etc?

spaghetti turned into OO is going to be spaghetti too, just with a lot more of sauce and different bits which look almost the same but turn out to be tomato or minced meat upon closer inspection and when you take plunge into the platter and eat something you don't really know what you ate or how it got there, what I'm trying to get at is that if it's spaghetti because of already re-using lots of the code in lots of places then the rewrite could end up being 2 million lines (commercial rewrites of sw for gov. have a habit of ending up like this..).

at least he can probably feel good about it not being knights capital trading system.

but he's asking how to deal with it, with good development tools(that have good find/locate) and good memory. start exploring what the sw really does and guessing where you might be asked to do modifications.

Re:"Cobbled together over 10-20 years . . . ?" (1)

AmberBlackCat (829689) | about a year and a half ago | (#40885085)

I think, at least for open source projects, making the code easy to follow would bring in a lot of help from people who are good at writing code but don't want to spend years trying to figure out how to pick up where somebody left off in a pile of obfuscated goo.

Re:"Cobbled together over 10-20 years . . . ?" (1)

evil_aaronm (671521) | about a year and a half ago | (#40885337)

I agree with you, to an extent. I inherited a monstrosity, as well - twice, in fact - and each time it was, "I can fix this so that it's easier to maintain," and the first manager said, "But that means we'll have to test it even more to find any newly introduced bugs." The second said, "Your proposal is too complex; make it the way it was," even though almost no one but me could figure it out in the first place. The second manager, however, was the type of guy who would cut and paste a block 10 ten times, changing a single parameter for each block, rather than just build a loop around the code block. As such, his "It's too complex," was a reflection on his inability to understand abstractions, and we generally fear that which we don't understand. I don't work for that dickhead anymore, and I'm so thankful. Unfortunately, he's still managing a medical device that impacts peoples' lives, and his code is still shit.

Re:"Cobbled together over 10-20 years . . . ?" (0)

Anonymous Coward | about a year and a half ago | (#40885489)

The Windows kernel is, of course, about 2.2 Mb of undocumented spaghetti. It's been a mess since Dave Cutler threw a demo together that Gates shipped!

linux? (-1)

Anonymous Coward | about a year and a half ago | (#40884779)

Linux? how many lines.?. just 200k?

Easy! (4, Funny)

blackicye (760472) | about a year and a half ago | (#40884815)

Outsource it to India!

Re:Easy! (0)

Fuzzums (250400) | about a year and a half ago | (#40885253)

Yeah. A phryd y cewch eich cod yn ôl, bydd angen cyfieithu google i ddarllen eich sylwadau ;)

Re:Easy! (0)

Anonymous Coward | about a year and a half ago | (#40885283)

You can spot Welsh from a mile away :P

Re:Easy! (1)

Sponge Bath (413667) | about a year and a half ago | (#40885735)

You can spot Welsh from a mile away :P

When I could not find "cewch eich cod" in my Klingon dictionary, I assumed he was just posting while drunk.

Better solution (0)

Anonymous Coward | about a year and a half ago | (#40885699)

Nuke it from orbit.

It's the only way to be sure.

in my experience... (0)

Anonymous Coward | about a year and a half ago | (#40884827)

... it are usually the bad and inexperienced programmers who upon taking over a project condemn the existing
code to be a mess and wanting to do a rewrite.

Re:in my experience... (0)

Anonymous Coward | about a year and a half ago | (#40884915)

No surprise.
1) the bad and inexperienced programmers make up the majority of programmers in the world.
2) because most programmers are bad, most projects also end up being a mess.

And 1) is why rewrites usually don't work either. The other reason is even good programmers usually have no time to rewrite everything. Everybody cares about new features, only a few care about old bugs that they grumble about but have lived with for years - until the system gets pwned...

Re:in my experience... (2, Informative)

Anonymous Coward | about a year and a half ago | (#40885543)

Usually when the inxperienced programmer does the rewrite, "initial results are promising".
That is, it is possible to quickly build a basic framework with badly designed error handling and
only part of the requested features.

When it is tested in real life, lots of omissions and problems are found.
Once these are fixed, the result is as messy and unstructured as the initial system was before
it was rewritten.

Re:in my experience... (0)

Anonymous Coward | about a year and a half ago | (#40885771)

.. it are usually the bad and inexperienced programmers who upon taking over a project condemn the existing
code to be a mess and wanting to do a rewrite.

I'll bite.
Firstly, I'm technically out of the IT game now, but money is money, so I still do the occasional paying IT job. I'm currently debugging some Perl code for a client, I'm about 1/10 of the way through, and I've found two major howlers so far;
1. a block of 30 lines of code called in such a manner that it occasionally processes an intermediate data file before that data file is fully populated/generated, and it does so in a somewhat quasi-random manner, leading to all sorts of unpredictable fun and games later on in the code and the eventual output files. (whilst I've been typing this, I've been debugging the most recent changes I've made to fix this..and probably will be doing so for the next week).
2. a failure to check that a number of these output files already exist means that it regenerates needlessly 5,400 files every time it runs (and this number increases weekly), increasing the code running time by a significant factor (fair amount of number crunching and graphics generation involved). Fixed that one yesterday, that was trivial..so trivial, in fact, that even a tyro programmer would have spotted it immediately.

At this point I'm looking at suggesting a rewrite to the client as, based on what I've found so far and some other suspicious looking blocks of nonsense within the code, I cannot guarantee that any of this code I'm looking at truly works as per the original spec (all nicely documented btw..the spec, that is, not the code - it's the usual 'someone-else's-Perl-hell' ).

Sometimes it isn't about wanting to do a rewrite, but needing to do so based on circumstances.

I'm also going to add here, much as the state of the current code I'm looking at pains me, I'll not be the one doing the rewrite if my client does go down that path, I'm just identifying/fixing the problems with their code that they already knew was faulty from the anomalous results it occasionally produced , I'm not massaging my ego/whatever by 'dissing' the existing code as being 'messy' or inadequate for the sake of it..it just IS.

Ach, I'm off for a cup of tea...EOR.

Why? (0)

Anonymous Coward | about a year and a half ago | (#40884867)

Is it broken? Why does he need to fix it?

Re:Why? (1)

maxwell demon (590494) | about a year and a half ago | (#40885851)

FTFA: "They've recently learned some hard lessons about the consequences of non-existant configuration management. Their maintenance efforts are also greatly hampered by the vast accumulation of undocumented "sludge" in the code itself."

stackexchange. (-1)

Anonymous Coward | about a year and a half ago | (#40884881)

I knew I read this before:
http://programmers.stackexchange.com/questions/155488/ive-inherited-200k-lines-of-spaghetti-code-what-now

Rewrite it (1)

ddt (14627) | about a year and a half ago | (#40884937)

Rewrite it from scratch using the spaghetti code version to run correctness tests to verify you haven't changed the behaviour.

200k lines is about how large the Doom codebase was, and it wasn't uncommon for John Carmack to rewrite most of his game engine in a couple of weeks, a week, or even a weekend when he felt it wasn't going on a good path.

Re:Rewrite it (4, Insightful)

StripedCow (776465) | about a year and a half ago | (#40885069)

200k isn't something you're going to rewrite in a couple of weeks. I think the absolute maximum you could get (for one very skilled person) would be about 5k-10k per week. Rewriting would take on the order of half a year.

Re:Rewrite it (1)

bosah (2117736) | about a year and a half ago | (#40885285)

Probably not true. If its truly cobbled together as described, and therefore a lot of it has been created 'key to disk', then most of it is probably unnecessary code. Replacing it with a rewrite would more than likely require code that is a considerable order of magnitude lighter than 200k (say between 50-100K). I've seen this kind of crap before a few times, and have succesfully replaced with rewrites, and in reasonable time frames. The main key to doing a rewrite succesfully however is NOT to look at, or replicate the code as it is (but just a bit tidier). The best approach is to go through a proper design to functional specification process, just as if it was a new application. Doing it that way you'll probably find far more elegant coding solutions than are currently being used by the 200k mess and these will cut down on coding time. Moreover it will produce better and more maintainable code, more than you ever would through a tidy and document process. If you think about it, documenting what the spaghetti is doing would probably take as much time, if not much longer, than a fresh design/spec process. Basically the time taken to do a good rewrite is very rarely going to be longer than it would be to unpick the mess. Just keep your team very, very small and make sure everyone including your programmers are involved from the first design/spec discussions onwards. Things go much faster, and you get a far better design, if your coders are invested fully in the project.

Inexact Results (5, Insightful)

SuperKendall (25149) | about a year and a half ago | (#40885301)

Rewrite it from scratch using the spaghetti code version to run correctness tests to verify you haven't changed the behaviour.

And just how are you supposed to write "tests for correctness" when the very concept of what is "correct" is embedded in the code?

Any such tests would embody your own notions of what is correct based on your understanding of a codebase that cannot be understood.

Furthermore, Doom is quite a different thing. You have an end result that can be somewhat different and it doesn't matter - it could render textures such that they appear rather different but if you find it visually OK then it's fine.

No such luck with business software which usually has extremely rigid and exactly output, often output other systems are depending on being just so. There is no room for alteration of behavior, yet as I said no-where exclaims all of the features of the output you cannot possibly understand....

I agree with a few responses that the only way to proceed is to re-write tiny parts, that at most affect one other system in the company - with the explicit buy-in from those other groups something may change, and the understanding you may have to back out your changes wholesale if you cause too much disruption.

Can't get buy in to proceed? Then quit or work with the code as is.

Re:Inexact Results (0)

Anonymous Coward | about a year and a half ago | (#40885723)

You don't write new tests for correctness of the new code based on your understanding of the old code, you use the old code exactly as it is as a reference implementation of the business requirements.

If your new code does what the old code did when both are fed the same input, you're good to go. Exactly how you go about setting up these tests can be a nightmare worse than dealing with the original spaghetti code, but at least that is the idea.

Re:Inexact Results (1)

maxwell demon (590494) | about a year and a half ago | (#40885893)

And just how are you supposed to write "tests for correctness" when the very concept of what is "correct" is embedded in the code?

Simple: If the original code is the specification, then the tests have to be written such that they pass with the original code. That is, the original code is the test suite for the test suite.

Re:Rewrite it (1)

Fuzzums (250400) | about a year and a half ago | (#40885329)

"correctness tests to verify you haven't changed the behaviour"

So apart from rewriting, you will also have to write a lot of unit tests. Depending on the complexity and type of code, that will take a lot of time too.

I've rewritten 15 year old Fortran code. It has now some the features that were the reason for the rewrite. That wasn't cheap, but now we have software that can be maintained by a lot more people AND it has unit tests :)
But writing those unit tests required diving into the old code to produce (partial) data sets to test with. That required actually understanding the old code very well.

It was a lot of work, but worth it: customer is very satisfied with the result.

1. Lose the attitude (5, Insightful)

Anonymous Coward | about a year and a half ago | (#40884963)

Well step 1 would be to lose the attitude.

It's code, it may be in an obsolete language, it may be not to the best industry standards, but its code and it's got enough knowledge in it, that nobody wants to throw it away, and they hired you to maintain it.

Step 2, I don't know why you would define a process before you understand the code you are to apply the process too?
Seriously, wtf is all the process stuff about, you're the sole programmer, any rules you set are rods to break your back when you first hit a piece of code you have to break the rules.

Step 3, you serve them. If you want to port it to a more modern maintainable language, choose one that's easy for THEM to transition to. They've got the knowledge that drives the company, not you, you are the cleaner here. If the phone rings your turn off your vacuum and let them do their job, Mr Cleaner. Nobody gives a fork if the cleaner has best industry procedure for cleaning an office.

Step 4, break it down. tiny bit by tiny bit, port to a new CLEAN structure, bit by bit. They wrote it, they can identify the core stuff.

Step 5, once you've ported it, along comes an engineer with a code written to the old language and old methods. Again, that's fine, put away the process manual, these are the experts, if that's the language he can communicate to you in, it's fine, you can understand it, you can port it, you can help him speak the modern lingo. Don't quote your processes to him, you're just the cleaner.

As for this:
"Software development needs good processes and procedures for exactly the same reasons that chemical plants or factories have manuals"

That's someone who *implements* things, typically a bolt together module manager. He is not someone who creates *new* things. Because news things don't come with manuals. You don't know the rules of how they work till the problems needed to make them work are solved. One assembles Microsoft IIS blocks, the other works for Google on image processing. Which are you?

Re:1. Lose the attitude (2, Insightful)

gbjbaanb (229885) | about a year and a half ago | (#40885667)

unfortunately, I think most devs (especially the kind to complain about someone else's "crufty" code) will spend months rewriting, refactoring and introducing today's "best practices" like IoC and Dependency Injection and come up with 300kloc of even worse spaghetti code, that now has extra bugs to be fixed too.

A bit like how a discussion on stack overflow ended up discussed on ArsTechnica for some (probably advertising-related purpose) and now has come to Slashdot for further adoption. 4chan, you're next.

Re:1. Lose the attitude (0)

Anonymous Coward | about a year and a half ago | (#40885949)

all bow to the arrogant one preaching humility!

A meal fit for a programmer. (0)

Anonymous Coward | about a year and a half ago | (#40884973)

How To Deal With 200k Lines of Spaghetti Code

Well some good spaghetti sauce and a nice wine.

Re:A meal fit for a programmer. (0)

Anonymous Coward | about a year and a half ago | (#40885075)

You misspelled 'whine'.

Re:A meal fit for a programmer. (1)

galaad2 (847861) | about a year and a half ago | (#40885341)

don't forget a fork.
all spaghetti needs a fork, even spaghetti code. /:)

Re:A meal fit for a programmer. (0)

Anonymous Coward | about a year and a half ago | (#40885561)

And don't forget a table with some dining philosophers !!

Fix the most urgent problem first (1)

tramp (68773) | about a year and a half ago | (#40884987)

Look at what the software is supposed to do and what it does not do at the moment. Fix this first and after that document the main functions and start replacing them one by one in an orderly fashion and document them this time. It will take time but at the end you 'll have eaten the spaghetti and your project is saved. The biggest problem in software usually is that there is no time to do it right but there is always time to do it over again.

Write a program that rewrites the code (0)

Anonymous Coward | about a year and a half ago | (#40885017)

Use basic AI procedures. Remember that simulations of the code will be necessary for the re-write. Also, the result might be too complex for humans to understand. That's no worry, just have a sandbox ready where you can simulate stuff.

Ravioli? (1)

Anonymous Coward | about a year and a half ago | (#40885027)

To a ravioli coder procedural code will often look like spaghetti.

Don't touch it (4, Insightful)

GrahamCox (741991) | about a year and a half ago | (#40885031)

All the advice to rewrite it is misguided. Maybe rewrite small parts that you need to to keep it working on new hardware, or whatever, but if it works, I would think that wholesale rewriting is asking for trouble. The Ars article is full of great advice about what you should do to manage a large codebase going forward, but actually it doesn't really address the question of what to do about a large legacy codebase that wasn't written with best practice. The best software is written by incremental improvement of what went before (no matter how badly written, as long as it meets its specification) - big projects written from scratch usually fail.

Re:Don't touch it (0)

Anonymous Coward | about a year and a half ago | (#40885107)

Fire some barbs at the management who let become this way. The peopel you crossed the cost/benefit line, and made those decision need to be personally accountable, not some crap that the IT boys are lazy and not up to the challenge.

Bring in the big names to see how much a rewrite will cost. Let those number fly.
Going to look good, manage on this and pay this much, or rewrite and pay 30-50 times more for something with less functionality.
Unless the message short term slash and burn does not pay in the long run, they will treat you like a walmart droid.

Re:Don't touch it (1)

wvmarle (1070040) | about a year and a half ago | (#40885475)

Not just management, you should also blame the developers that wrote it that way.

It's a manager's job to tell how to do it; it's a developers job to implement it properly. You can't expect a manager to write perfectly modular, readable software - that's the developer's task, and blame failing to fulfill that task should be largely on the developer.

Re:Don't touch it (0)

Anonymous Coward | about a year and a half ago | (#40885375)

Sort of agree.

Although I often see that a large project reaches a kind of homeostasis wherein the most painful bugs and missing features are gradually fixed by the aforementioned gradual improvement process, but the lesser bugs and annoyances are kept in forever because people get used to working around them, and fixing them might entail re-writing a lot of the now 'good' parts for uncertain results.

And it's a very important process, the incremental improvement loop: In most real-life deployments there are things couldn't be taken into account beforehand, experience that needs to be gotten before a version 1.1 can be made..

Re:Don't touch it (4, Insightful)

ed1park (100777) | about a year and a half ago | (#40885441)

Beware of the second system effect.
http://en.wikipedia.org/wiki/Second-system_effect [wikipedia.org]

Rewriting code can kill you in the short term.
http://www.joelonsoftware.com/articles/fog0000000069.html [joelonsoftware.com]

Or help you in the long term.
http://notes-on-haskell.blogspot.com/2007/08/rewriting-software.html [blogspot.com]

I recall another similar article about a rewrite of MS Office, and what a mistake it was...

200,000 lines ISN'T THAT BIG (rewrite)... apk (0, Insightful)

Anonymous Coward | about a year and a half ago | (#40885035)

Try projects of "enterprise class" that span into the MILLIONS of lines of code.

* I'm serious here...

Yes, there's a BIG difference between walking into a system with 200k lines (this is REWRITE territory still imo, & it's a professional one with over 17++ yrs. & around 30 projects of the MILLIONS OF LINES sized code for information systems)

vs.

One with millions of lines in it (not so simple to just rewrite).

APK

P.S.=> There's a time to rewrite, and a time not to, and when you're sub 500,000 lines, a rewrite IS possible and if it is as "bad" as this article *tries* to make it out as, then you rewrite when it's THAT small (& yes, 200k lines is TINY)...

I've done my assessments here based on doing smaller stuff from:

---

1.) The shareware/freeware level (most of mine here maxed out at around 5,000 - 10,000 lines of code tops)

2.) Commercially sold code in utilities I am part of in THAT market (usually midrange size 10,000 lines - 100,000 lines)

3.) Finally, and yes, "Enterprise Class/Industrial Strength/Mission Critical" information systems (these had millions in front end code alone, toss on SQL Stored Procs & more? You get the picture!)

---

The latter's where I've made the largest part of my livelyhood professionally since 1994 ( these definitely can often be quite large into that MILLIONS of lines of code range, with MANY "moving parts" in libs, main code, SQL stored procs, and tables/devices on DB's galore + more)...apk

You need to break the problem up into chunks (0)

Anonymous Coward | about a year and a half ago | (#40885043)

Take bits of the code and rewrite them one by one. Tackle a function here and a function there and over the course of a few years you'll have 400k lines of spaghetti code since modern coders don't need to worry as much about memory limits and processing constraints.

Agreed 110% on rewriting sections (-1)

Anonymous Coward | about a year and a half ago | (#40885093)

Exactly on the rewrite sections part (I like how you think in that part per my post here that just preceeded yours) -> http://developers.slashdot.org/comments.pl?sid=3026933&cid=40885035 [slashdot.org]

This part I am NOT sure I agree though - as I've done rewrites vs. maintenance MANY times since 1994 on many kinds of code - you're NOT always writing from scratch on fresh new projects after all...

Sometimes, you're reworking or adding onto existing ones (I actually find THIS harder to do, because of having to not only understand the data & process flow, database schema and WHERE the data comes from + why, but also another person's logic - I've sat there & said "Who was the NUT who wrote this?" & other times said "WoW... now I get it & see WHY the guy did it as he did - he could think & HAD to do so!" where I actually learned by others' work in that latter case too. bonus!):

"and over the course of a few years you'll have 400k lines of spaghetti code since modern coders don't need to worry as much about memory limits and processing constraints" -.by Anonymous Coward on Sunday August 05, @06:40AM (#40885043)

Ever heard the saying "IF you want a job done right, do it yourself?"... sometimes, that's how it goes!

With a relatively TINIER system (& 200k lines IS TINY by comparison to many I've maintenanced OR written from scratch that went into the MILLIONS of lines ranges)?? It's often good to do.

The hard part's understanding what it is supposed to do, and the database schema & data itself, & process flows...

Most times, especially in the case of an "over-maintenanced" by 50++ diff. coders over time spaghetti code system, you're better off with a rewrite!

APK

P.S.=> Lastly & largely? It's ALL about budgets for said projects too... can you do a rewrite in time, and on or under budget! Money talks people...

Yes - t's largely WHY systems like the one in this article exist (cob-jobbing/hack-after-hack fixes on existing systems by diff. coders over time especially CAN be cheaper than entire rewrites OR freshly done NEW systems)... apk

be selective (1)

roman_mir (125474) | about a year and a half ago | (#40885065)

Be selective, identify the key areas, where the most business logic is happening and centre around it. Set up a wiki, have a main page describing the application's purpose, then branch from that and describe the areas (files, components, resources) that take care of major functionality, not 'how' it's done but mainly 'why' it is done.

Don't forget to fill the new information into your wiki and eventually you should be able to create a map from a structured wiki document to your 'Spaghetti' application.

It doesn't really matter actually if the code itself is convoluted if you can map a maintained, structured document to your code, where the key pieces of functionality are described.

If you do this, eventually it wouldn't matter that the code itself is awful, because if the code does the job, then it can be awful but still an important resource, a piece of capital. If it works and gives proper results, does what it is supposed to do, then it's good code (even if it is ugly and badly structured). Document it with wiki and have pointers and explanations in your documentation.

Re:be selective (2)

udachny (2454394) | about a year and a half ago | (#40885215)

Open documentation? Pfffft. That's a lame advice. No no, what you want to do is mix it up some more, obfuscate the code, change variables to make them global and reuse them everywhere but all for different purposes. Merge large files together and brake small files into even smaller ones.

Remove any useful comments from the code, but add plenty of comments like this:

// adds 1 to i, waits until i is greater than 10 then adds 2 to a.

Now that's a comment!

Then leave the project and see the other guy come in and pull his hair out. Life is hard, make it funny.

Re:be selective (1)

maxwell demon (590494) | about a year and a half ago | (#40885925)

// adds 1 to i, waits until i is greater than 10 then adds 2 to a.

Now that's a comment!

Didn't they teach you that comments which re-state exactly what the code does is bad? Here's how that comment should look like:

// increments i until large enough, then adjusts a

Everyone who wants to know the details can refer to the code. The comment shall not give the what (10) but the why (large enough).

SCNR :-)

Sequence Diagrams (0)

Anonymous Coward | about a year and a half ago | (#40885111)

Make sequence diagrams based directly off the code.
This will make your life so much easier.

Then have a separate project that you rewrite.
If you aren't being paid to do this and you just want to do this because it is awful to work with, spend maybe 2-5% of your time a day doing it.
Even do it at home if you wish to. (this is more of a case of if you live and breath programming as to whether you would want to or not. I would)

But make sure that you let your boss know how great a job you done since most likely that recode will boost the speed and efficiency several times over when you replace the old file(s).
That will likely get you a big fat bonus or possibly even a raise since you never went and asked for any resources to do it in the first place. Forward thinking people are always loved in business. (unless your boss is a really terrible, horrible person, which most actually surprisingly aren't when it comes to this, most are just the horrible person part)

Obviously make sure to do your usual project coding stuff as well, documentation is key here since the entire thing became a mess likely because of poor documentation
The problem now is the others, which the first post on the SO link describes how to deal with very well. (really well in fact. I like that guy)
It is going to be long and hard, but there is a very good opportunity in it for you if you handle it right.
Good luck.

Re:Sequence Diagrams (1)

mrjb (547783) | about a year and a half ago | (#40885403)

Even do it at home if you wish to

Don't fall for it, it's a trap. Before long, it will be expected from you. At home, I don't get paid for the hours I put in. At home, I don't receive any recognition for the work I've put in. Using home-made stuff at work puts the ownership of your stuff in question. I choose to keep home and work separated. At home is where I work on MY stuff.

200K Lines not that much (4, Interesting)

PerlPunk (548551) | about a year and a half ago | (#40885127)

I have spent most of my career as a software developer inheriting and updating such spaghetti code bases. Here are few remarks and some of my experiences around this:

  1. 1) 200K lines is not such a formidable size. If your average module size is 1000 lines of code, that's 200 separate modules. Or if the module size averages 2000 locs, that's 100 modules. Gradually getting your head around the modules is not as big a problem as it seems, even if there are many interdependencies between modules. However, if the average module size is something on the order of 10K or 20K, then you really are dealing with spaghetti code, and that's quite a bit harder to figure out than if the module size on average were around 2 or 3K.
  2. 2) For the time being, treat the whole application like a black box, which means not worrying too much about how well it works until you have to fix some "bug". At that point, figure out how it works only insofar as you need to in order to get your bug fix in, and record your lessons learned in a wiki and in comments in the code. Refactor as you go along, if feasible.
  3. 3)Being able to step through code is really helpful when trying to understand a poorly documented code base--even if the code is well structured. A number of technology platforms (like Java JVM) offer remote debugging.
  4. 4) You can reverse engineer these things and produce a set of business specs with which to port the application to a new platform. Right now, I'm on a project that is porting 125K lines of COBOL code that ran on OS2 to an Apache/mod_perl technology stack. Our team consists of 2 cobol developers, who are producing the specs from the code, and 3 perl developers who are porting it. The key here is to capture the business requirements and the user interface behavior. Once you do that, how you implement it on the new platform is quite straightforward. HOWEVER, this approach is not advised unless your company or gov enterprise has lots of time, deep pockets, and a commitment to seeing the project through to its eventual success.

In summary, don't be too scared of a legacy spaghetti code base. These things can be understood well enough in time to refactor or port to a new platform.

Agreed (we think alike & have BEEN there) (0)

Anonymous Coward | about a year and a half ago | (#40885159)

http://developers.slashdot.org/comments.pl?sid=3026933&cid=40885035 [slashdot.org]

* I'd look it over, make an estimate of the time needed to get its process/information flows down + a rewrite, vs. sticking a customer with a cobbled-together wreck that rubberbands, paperclips, & superglue are holding together (for now).

APK

P.S.=> I average around 400,000 lines of code over 10 - 12 month projects since 1994 on mid-to-large scale information systems (up to "industrial size/enterprise class/mission critical systems into the millions of lines of code)!

Taking into account you have to get the database schema, information flows, and process down as well, I'd say what's needed is a rewrite here... & it is around 6++ months work, tops!

Yes - and, of course, money talk$, & it depends on what the client wants & is WILLING TO PAY FOR too.

Sometimes, those "cob job" maintenence jobs (yes, plenty of those here too professionally in info. systems/db work both as fresh or rewrite &/or maintenance jobs too) are all they can afford, so you are STUCK with it and after oh, 10 diff. guys have worked on it, you get those "spaghetti deals" (which suck to understand even at times) because of money & timeframes... apk

Re:200K Lines not that much (1)

mrjb (547783) | about a year and a half ago | (#40885357)

1) 200K lines is not such a formidable size. If your average module size is 1000 lines of code, that's 200 separate modules.

What are these "modules" that you are speaking of? And "separate" - could you elaborate? I've seen code where one couldn't help to ask the above questions. Asking the architect about what modules the system had yielded the answer "It's complicated, you'll just have to get used to the system". Which meant, committing the full 200k lines to your brain and needing to understand the code as a whole, rather than as pieces and modules. In the end I found out there's a design pattern they followed. The official technical name of that design pattern is "big ball of mud".

Re:200K Lines not that much (2)

wvmarle (1070040) | about a year and a half ago | (#40885457)

1) 200K lines is not such a formidable size. If your average module size is 1000 lines of code, that's 200 separate modules. Or if the module size averages 2000 locs, that's 100 modules.

You make a very big assumption here, and that is that this code is written in neatly separated modules. The submitter asking for help; calling it "spaghetti code" that has been "cobbled together" over a long period and presumably by many different developers; those points make me doubt you can make such an assumption.

It can very well be a single "module".

I'd say he meant THIS... apk (0)

Anonymous Coward | about a year and a half ago | (#40885567)

That's why step tracing of ANY code (spaghetti or not) for a rewrite especially, matters (or even when maintenancing a mess).

You need to get the programmatic "flow" down, either way. Then, if you're shy of a business analyst? You have to do the legwork on checking the information flows needed (which means investigating db design/schema, and what comes from WHERE in tables in the DB Devices).

A LOT OF LEGWORK COMES IN WHEN YOU'RE "NEW" TO ANY PROJECT (especially in info. systems work).

APK

P.S.=> IF it's a "single module" (possible), then you do what I stated above!

Which is basically what the poster I replied to here whom you are replying to also, in breaking down said single drop-down inline code (dumb many times, especially for maintainability) that's "spaghetti" into manageable parts/logic engines!

(Be that functions OR just subroutines/procedures inlined in the SAME module, busted OUT of a single monolithic "driver" main module).

You then even can separate OUT those methods/functions (or subs/procs, whatever you call them, clarifying what puts out return types (functions) vs. straight 'modules' (procs/subs)) into separate:

---

1.) UNITS (e.g. Pascal UNITS, C/C++ .h headers, or Basic modules ala VB) if need be

OR

2.) Even further, into instanceable objects (any OOP languages can do that)

3.) OR EVEN FURTHER, into custom controls (ala .OCX from VB or MSVC++), or LIBS/DLLS (OLE type or std. type) out of it, and other languages like Delphi or C++ of varying vendor type))

---

Sorry for responding for someone else, but I wager THAT's what he meant... he knows what he's up to, I can tell, as it "takes one to know one"...

... apk

Re:200K Lines not that much (I disagree) (0)

Anonymous Coward | about a year and a half ago | (#40885761)

I agree with the idea of using (and the necessity) of having analysts familiar with the legacy coding environment writing business specifications for the existing code (and as well the dependencies between modules) and having multiple developers port it to a new language as a way of moving the code base to something more maintainable. Again, I am assuming that the porting developers are using source code management tools, following a standard, and are adhering to a common design philosophy (coding for exceptions, using a consistent naming standard, comments that address the what of the code (not the how), and indenting code for readability) .

I disagree with the idea that 200k lines not that much. I'd estimate that a better than average developer would be able to read and port between 100 and 200 lines per day, so this project would take between 1000 and 2000 developer days to port. Even factoring in having 5 resources means that this project would take 1 to 2 years at a US cost of $600K to $1200K.

I would not bother with the rewrite part, I'd focus on identifying the business requirement along with the associated code functionality. The code is maintainable once you know what it is supposed to do and where it does it. I'd also require any changes to be documented to the newer standard. In order to avoid making the problem any worse, I'd put in a SCM, and controls around releases to the production environment.

Re:200K Lines not that much (1)

loufoque (1400831) | about a year and a half ago | (#40885961)

I'd have to agree on this.

As a software developer I've experienced this most of the time, working with code bases much larger than this without any sort of documentation. It's not unusual for single files to be more than 4,000 lines of code and to have thousands of files, with the occasional crazy branching 10 levels deep within a single function.

It's just something you have to deal with as a professional software developer. It's not really a problem. Knowing how to use your tools efficiently comes a long way. I personally use grep and find a lot.

Abject terror! Rewrite or leave alone. (0)

Anonymous Coward | about a year and a half ago | (#40885131)

The trouble with really bad spaghetti code is that, if you change anything, something else will break in an unpredictable way.

The good thing is that you don't have to re-write the code in its original language. If you can use Python, the resulting code will be much smaller (as much as 90% smaller).

You can also use tools (Simulink, Matlab) to avoid actually writing code. Some industries are standardizing around model-based design [wikipedia.org] . It's a good way to visualize, create and document complex code.

If the spaghetti code is a maintenance problem, it is costing the company money. You can make a strong economic argument for re-writing it. If the code isn't causing a maintenance problem, leave it alone.

In the above, I have assumed that the code is truly bad. If it isn't that bad, you should refactor. link [wikipedia.org] link [sourcemaking.com]

Excellent point - Agree 110% (breakage potentials) (0)

Anonymous Coward | about a year and a half ago | (#40885211)

See subject-line, and, SO true (on possibility of breakage when doing partial maintenance of code only vs. rewrite from scratch when YOU get full understanding AND full control).

APK

You lucky one! (0)

Anonymous Coward | about a year and a half ago | (#40885267)

I was hired as a reviewer of a project most members think it's not as bad as it is. Some are professional programmers and the code they write isn't too bad. But not abyssmally bad isn't enough. They started to write code a second time unknowingly as the code is a mess and they don't know about the code. They use the mailing list to compensate missing documentation. They use classes, modules, packages, but the API is sometimes missing or - even worse - plain wrong. The biggest problem - at least some of them think they know what they are doing...

Standard procedure (1)

WinstonWolfIT (1550079) | about a year and a half ago | (#40885269)

Per John Lakos, almost any bad interface can be wrapped in a good one. Slice off an appropriate slice of dodgy code, wrap it in a testable interface, write the test code to baseline its behaviour, and then when it makes business sense, you can refactor that slice of code. If it doesn't make business sense, you don't touch it.

NOT like a chemical plant (2)

Troyusrex (2446430) | about a year and a half ago | (#40885289)

The difference between software development and most manufacturing is that they produce the same or very similar product thousands or millions of times where we produce a different product every time. This "building an app is like mass producing a chemical" philosophy is one reason why most software shops have insane amounts of unneeded documentation and overhead. I certainly agree that some standards, processes and documentation is needed but it should be kept to the bare essentials as every bit of work done that doesn't directly build a product could well just be a waste of time.

Re:NOT like a chemical plant (1)

Anonymous Coward | about a year and a half ago | (#40885685)

I think you misunderstand. The software is not being likened to the chemical (i.e. the output of the chemical plant), it is being likened to the plant itself. The data output by the software would be the equivalent of the mass produced chemical. The software engineer would be the plant designer, not the shop floor worker.

No idea what the big deal is (0)

Anonymous Coward | about a year and a half ago | (#40885445)

First, rewriting from scratch is obviously a foolish suggestion. Only somebody completely separated from goals-based performance and the economy of the application would suggest such a move.

If it is 200K lines of code, it obviously has a fairly wide range of functionality so just tackle it in pieces, rewriting the sections towards a common spec or employing a framework. You'd simply have to allow for extra time for each project, where the development team would simply combine their iterative development of the section being expanded/improved with migration from spaghetti to common form. Where it crossed with other spaghetti, a compromise or facade connection would suffice until everything was brought into line.

Interface should be the last worry, as a) a spaghetti application is a much more serious long-term drag on any ongoing development, b) the users are already used to the existing interface and c) changing interface means retraining people. Better to build a facade between the existing interface and improved code in the interim, than to have to begin dual-training people on multiple interfaces.

With a consistent approach, the development team would claw back so much extra time from standardization that those early, extra 'migration' hours would be quickly wiped off the slate.

rewrite from scratch or accept the mantra.. (0)

Anonymous Coward | about a year and a half ago | (#40885521)

Everybody's code is spaghetti except your own. That is until the next guy see's your code...

They didn't teach you this in college? (0)

Anonymous Coward | about a year and a half ago | (#40885557)

And I thought CS was trying to be more 'relevant'.

At the very least (1)

NotSoHeavyD3 (1400425) | about a year and a half ago | (#40885581)

Instead of multiplying how long you think something will take you by 2 when you give your estimate(since everybody underestimates how long it takes to do something) multiply it by 4. (Since if the code is that bad you'll need the extra time to A:Find it and B:Find out the first way you fixed a problem broke something else because the code is garbage.) Can you tell I'm working on spaghetti code now?

Big Ball of Mud (1)

QuietLagoon (813062) | about a year and a half ago | (#40885623)

A commentary [laputan.org] on spaghetti code and why it gets that way.

.
A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We’ve all seen them. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems.

Still, this approach endures and thrives. Why is this architecture so popular? Is it as bad as it seems, or might it serve as a way-station on the road to more enduring, elegant artifacts? What forces drive good programmers to build ugly systems? Can we avoid this? Should we? How can we make such systems better?

We present the following seven patterns:.....

don't rewrite (0)

Anonymous Coward | about a year and a half ago | (#40885833)

Anyone who tells you to rewrite this from scratch should not be working with software. There are no shortcuts. You have 200k lines you don't fully understand. If you try to replace this with a system written from scratch so that you don't have to understand each and every part of the current system, you will fail. It will take years and still never reach a releasable state. Sooner or later you or the guys paying you will lose patience and either scrap the incomplete and misguided rewrite (good) or release it out of fatigue (bad). That is the kind of thing that kills a company.

On the other hand 200k isn't that big. Live with it for a while until you understand its basic layout, have successfully fixed some bugs and added some features. Then you can start gradually improving parts of it; taking care to understand the code well before you touch it.

The fact that you do not immediately understand this makes it highly likely that you are not good enough to do this work yet. Find another job where you have less freedom to break things and try to gain some experience.

captcha: rational

done in one hour. (1)

Anonymous Coward | about a year and a half ago | (#40885945)

just put it all inside a class
now you have nice object-oriented code

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...