Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming

How To Deal With 200k Lines of Spaghetti Code 236

Posted by Soulskill from the make-sure-it's-al-dente dept.
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!'"
This discussion has been archived. No new comments can be posted.

How To Deal With 200k Lines of Spaghetti Code More

How To Deal With 200k Lines of Spaghetti Code

Comments Filter:

  • ...no (Score:4, Funny)

    by Anonymous Coward on Sunday August 05, 2012 @04:25AM (#40884743)

    no comment...

    • Re:...no (Score:4, Interesting)

      by wmac1 ( 2478314 ) on Sunday August 05, 2012 @05:22AM (#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 (Score:5, Insightful)

        by DJRumpy ( 1345787 ) on Sunday August 05, 2012 @06:24AM (#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.

        • 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 (Score:5, Informative)

            by ralphdaugherty ( 225648 ) <ralph@ee.net> on Sunday August 05, 2012 @11:27AM (#40886767) Homepage

            G2 is being called virtually obsolete. I looked up G2 in Wilipedia comparison of programming languages http://en.wikipedia.org/wiki/Comparison_of_programming_languages [wikipedia.org] and it is listed as:

            Language: G2
            Intended use: Application, inference, expert system
            Paradigms: common graphical development and runtime environment, event-driven, imperative, object-oriented

            Plus the search on G2 shows there is a G2++. So what does obsolete mean to those calling it obsolete?

            btw, I'm an RPG programmer and I've been writing tons of new business software every day for the last 23 years, the whole time the language has been declared obsolete.

            Now get off my lawn.

            • G2 is being called virtually obsolete. I looked up G2 in Wilipedia comparison of programming languages http://en.wikipedia.org/wiki/Comparison_of_programming_languages [wikipedia.org] and it is listed as:

              Language: G2
              Intended use: Application, inference, expert system
              Paradigms: common graphical development and runtime environment, event-driven, imperative, object-oriented

              Plus the search on G2 shows there is a G2++. So what does obsolete mean to those calling it obsolete?

              btw, I'm an RPG programmer and I've been writing tons of new business software every day for the last 23 years, the whole time the language has been declared obsolete.

              Now get off my lawn.

              So basically similar to LabView? I'd be inclined to re-write this all in LabView rather than try to rewrite this all in traditional software programming.

        • 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).

          • 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.

          • I would guess 10-20 years.

        • Re:...no (Score:4, Insightful)

          by Rockoon ( 1252108 ) on Sunday August 05, 2012 @06:52AM (#40885307)
          Isnt this how Netscape died?

        • Good luck with that (Score:2, Insightful)

          by Anonymous Coward

          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.

          • As the other responder said, this doesn't appear to be the case for this particular project in TFA. However, you're right, what you describe is normal for most projects. The way to handle it is this: since management isn't interested in doing a re-write, you just do your best trying to figure it out, which of course is not going to be very successful. Keep making excuses about how bad the code is when deadlines fly by. All this time, be sure to be looking for a new job on Dice.com. As long as you're ma

        • There are certain advantages to doing the re-write that speed it up. Libraries and frameworks can make a project that used to be 200k of lines to 20-50k of lines. You also have the existing code as a reference, use it. Create tests that pass against the old code to verify the new code (note when they find bugs in the old code, but be careful that others might be depending on said bugs).

          Sometimes the code in question is too broken to keep and refactor; you just need to burn it.
        • Comment removed based on user account deletion

        • Re: (Score:2)

          by jhol13 ( 1087781 )

          I'd do completely opposite.

          I'd drop the old code 99-100%. Start from top to bottom, document everything and perhaps even use some other, modern, programming language.
          The resulting code base is almost certainly lot less than 100k lines (+ comments & documentation, depends how you calculate these).

        • Re: (Score:2)

          by Eraesr ( 1629799 )
          There's a good chance that functionality hidden in those 200K lines of code can be rewritten in half that much code. Such spaghetti projects tend to bloat in amount of code as time progresses and multiple coders are working on it.

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

    by PolygamousRanchKid ( 1290638 ) on Sunday August 05, 2012 @04:31AM (#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.

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

      by gl4ss ( 559668 ) on Sunday August 05, 2012 @05:20AM (#40884983) Homepage Journal

      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.

      • 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.
    • 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

    • All true

      I would add that one of the disappointing things about programming is that few people ever see let alone appreciate a job well done.

      If the application works or even works "good enough", nobody cares if the coding is done well.......they don't even care to look at it.

  • Easy! (Score:5, Funny)

    by blackicye ( 760472 ) on Sunday August 05, 2012 @04:40AM (#40884815)

    Outsource it to India!

    • Re: (Score:3)

      by mrmeval ( 662166 )

      Huh, they're getting to be as expensive as in-house development with just as sloppy code depending on which business you go to. There is also a substantial language barrier in some cases even though there are a lot who do speak English they do not comprehend some concepts. You then need a liaison who does and can translate your requests. That adds cost. We did find a very good software development company that is prompt, competent and who worked to understand our needs. We do save money but it's not nearly

  • 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 (Score:5, Insightful)

      by StripedCow ( 776465 ) on Sunday August 05, 2012 @05:47AM (#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.

      • That depends on whether it actually needs to be that complex. Implementing a project that is 200KLoC is not the same as implementing something that is functionally equivalent to an existing codebase that has grown to 200KLoC. If the project is as described, I wouldn't be surprised if it could be implemented in under 20KLoC, possibly less if there are some existing libraries that can be used.

        • You're right, but that would be speculative. Also, don't forget about possible migration of data from the old to the new system. That may take considerable effort too. And testing (the old system has gone through 10+ years of testing).

          • You're right, but that would be speculative

            True, although I've found that attempting to rewrite a system is a good way of determining how complex it really needs to be. In the end, it doesn't matter if you actually use the rewrite, or even if you finish it. Once you've spent a bit of time on it, you have a much better idea of how the original system should have been designed, and that can help refactoring immensely.

    • Inexact Results (Score:5, Insightful)

      by SuperKendall ( 25149 ) on Sunday August 05, 2012 @06:51AM (#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: (Score:2)

      by Fuzzums ( 250400 )

      "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 (p

      • Unit tests are not 'rewriteable'.
        A unit test is testing a compilation unit.
        You need high level functional (scenario/story based) tests, to test a rewrite.

  • 1. Lose the attitude (Score:5, Insightful)

    by Anonymous Coward on Sunday August 05, 2012 @05:14AM (#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: (Score:3, Insightful)

      by gbjbaanb ( 229885 )

      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.

      • I don't mean any disrespect, but you seem to imply that "those people" don't know what they are talking about and have a bit of attitude. It seems like your post has a bit of an attitude.

        Those are good techniques you are criticizing.

        You could have brought up the very good point that programmers should ask themselves why the former devs did something a certain way.

        • its too difficult to describe all the bad techniques that get used simply because they're fashionable, but that's what I meant - the kind of devs who read stuff on the web and suddenly think "we must have that too".

          I went for a job interview a while back and when I gave my reply to their question about test-driven development (that it wasn't a magic bullet that fixes all code quality issues) they weren't too impressed. Obviously they'd read something that said it was, and they weren't going to believe anyth

  • 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.

  • Don't touch it (Score:5, Insightful)

    by GrahamCox ( 741991 ) on Sunday August 05, 2012 @05:38AM (#40885031) Homepage
    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 (Score:5, Insightful)

      by ed1park ( 100777 ) <ed1park@ho[ ]il.com ['tma' in gap]> on Sunday August 05, 2012 @07:18AM (#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...

    • 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

  • 200K Lines not that much (Score:5, Interesting)

    by PerlPunk ( 548551 ) on Sunday August 05, 2012 @06:05AM (#40885127) Homepage Journal

    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.

    • Re: (Score:2)

      by mrjb ( 547783 )

      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 cod

    • 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 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 w

  • NOT like a chemical plant (Score:3)

    by Troyusrex ( 2446430 ) on Sunday August 05, 2012 @06:48AM (#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.
  • 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?
  • 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

    • Re: (Score:2)

      by gl4ss ( 559668 )

      that article is a big ball of mud.

      but it makes a good point, you need to first focus on that the wanted features work.

  • 200k lines isn't too much (Score:3)

    by SpaghettiPattern ( 609814 ) on Sunday August 05, 2012 @09:29AM (#40886073)
    In the past years I have been several times in such a predicament. Huge amount of code and the function of the system is not completely clear. The original developers are gone, the system isn't well documented and only a handful of people know how how it should behave. As a matter of fact, tomorrow I will start coding on one system we can no longer support as hardware, OS and used libraries and frameworks are outdated and/or discontinued.

    Reengineering and rewriting is usually the best option. However, you need skills and experience in order not to make the same mistake the previous developer did. Of course, management must trust and approve your actions.

    A few dos:
    * Learn at least UML use cases, components diagrams and sequence diagrams.
    * Make use cases and check these with affected parties.
    * Start of with a rough component model of the new system.
    * Make a clear picture which nodes (hardware + OS), subsystems (units performing a function), software components (modules containing data, modules performing a function, etc...) and agents (users, triggers/schedulers) are involved.
    * Draw the interactions between the subsystems and/or software components.
    * Clearly document which interactions are on-line and which ones are batch/background/off-line.
    * Specify interfaces. (Used file formats, protocols, software library interfaces if you will.)
    * Slowly refine your model until you feel comfortable with it.
    * Make a rough class model and keep usability and maintainability in mind. Backtrack if necessary.
    * Divide software components between "dumb" containers of information (e.g. plain Java beans) and components performing functions (business logic if you wish.)
    * Decide which interfaces to make public and which not.
    * Describe restricted/private bits of code just enough for maintainers to understand them. And nothing more than that.
    * Make as much unit as necessary for your components. Unit test enough functionality.
    * Communicate your results regularly and refine your model where applicable.
    * Define integration tests and do these very seriously.
    * Define regression tests and perform these very seriously.
    * Make involved parties accept parts of the system according to performed integration and regression tests.
    * Try to plan gradual decommissioning of the legacy system.
    * Document the system "enough". System architecture (from UML), references from architecture to code, installation manual and operational manual are the most important ones.
    * Try to achieve longevity in the documentation. Abstract details and convince involved people that that is a good thing.
    * Define 1st, 2nd and 3rd level support. Preferably you should remain 3rd level support to better enjoy sleep.
    * Conform to standards and practices if they reduce discussion and enhance clarity.
    * Use well established techniques. E.g. JPA and JAXB.
    * Allow well established component manufacturers to make your programming life easier. E.g. Apache Commons.
    * Be tidy.

    A few don'ts:
    * Avoid OO pattern overkill.
    * Don't take the quick and dirty option too quickly. Those decisions will haunt you eventually.
    * Avoid making everything public. Documenting and maintaining public interfaces is more expensive.
    * Try to avoid big bangs.
    * Avoid less well established component manufacturers. My next project did use components from less established component manufacturers and their sell by date has generously expired.
    * Don't allow babling "architects" to make a mess of your system. But don't alienate them either.

    I may have forgotten a few things but this is all stuff I consider even for smaller projects.

  • I've dealt with a number of legacy code bases, done poorly. Some of the worst examples were done by veteran procedural programmers who picked up an OO language via tutorials.

    The worst of their evils could be greatly reduced by all tutorial and book authors, by stating, promiently, the rule of thumb that if the module they are typing goes past one screen in height that they should start thinking about breaking it into another module.

    Almost every language has a module of some kind ( procedure, function, subr

  • The article is excellent. It's publishing guidelines very similar to those I use, and my colleagues use, when dealing with our business partner's accumulated software projects, and covers it very well: I intend to use it as a checklist for spaghetti code integration projects.

    I'd emphasize the switch to good source control management (SCM). too many workgroups have undocumented workflows, and benefit profoundly from switching to or learning to properly use a robust system. This process also helps identify wh

  • Reminds me of how as a young lad, I went to work for a jewelry company's "IT Department". I put it in quotes because the department consisted of me, a supervisor who couldn't code, and a department head that had no idea whatsoever as to anything that happened on the company computers. Someones nephew or son that got put on the payroll is my guess.

    Anyhow, they had about three billion lines of applications written in Dibol, all spaghetti code, no documentation, last time they had employed anyone who could c

  • Before you attempt to change this kind of code base, you need to understand what it does. The best way is to write unit tests that exercise system. Think of tests as very precise requirements. Once a decent test suite is in place (200 to 300 test cases) then you can start thinking about fixing, rewriting portions of the system.

    Rewriting from scratch is probably the worst thing you can do. See this article [joelonsoftware.com] by Joel Spolsky,,

  • I stopped reading shortly after "I am aggressive when it comes to coding conventions"

    The mention of Agile as a positive strategy and the volumes dedicated to "format" of code are only useful to scratch an itch. They are only valuable in the mind of the author and those who think like him and rarely have any effect on outcomes.

    Ridigity * is not a strategy in and of itself. It is the preference of someone who is anally retentive and change adverse.

    The wins from his scheme are like the wins from modern langu

  • Its not 200k Lines, more on the order of 10-20kLines (depending onf the count; its written in a highly compact language). It is not my main task to restructure it, as a matter of fact i have rediculously little time budget for it, give the current state of the code. My task is to integrate new features into the code. However when i looked at it an rewrite seemed inevitable.

    Let me break dow how i try it:

    a) Analyze why the problem is there. There are two aspects of it: Is there a fundamental problem with the

  • Good software is not designed by the central committee; The central committee screws up everything.

    Good software evolves.

    You need to forget all grandiose plans to fix the software, especially if the ideas come from academia. Become unprincipled with respect to practicality.

    The software has already evolved a lot. If you attempt to recreate from scratch, you will almost certainly repeat previous errors, even if you avoid the current maintenance mess.

    The problem is that the software has evolved towards ext

Slashdot Top Deals

Avoid strange women and temporary variables.

Close