I've inherited 200K lines of spaghetti code—what now?
arstechnica.com
arstechnica.com
It's a copy and paste of this question on Stack Exchange: http://programmers.stackexchange.com/questions/155488/ive-in... but with broken formatting, and nothing else.
Is Ars Technica in trouble these days that they are just copying content?
edit: I have made the mistake of using an analogy on the internet. I realize it's not exactly the same, ok?
If you think it's worthless, complain to them.
If you want to argue that increased visibility is reason enough for its existence, then you're arguing in favor of every single copy and paste job on the internet. If so, that's your opinion - there are definite benefits for increasing quantity. But I wholeheartedly disagree that it is good.
To be painfully specific why, it's making a static copy of something from a site which was built because static answers were deemed bad, and it's splitting the feedback for little or no gain (note how there are more possibly-valuable responses in Ars' comments, but they're not on SE).
That it was apparently done by Stack Exchange is even weirder - they're willfully contributing to data-rot, when one of their major reasons for existence is to prevent it. It has already fallen behind the original answer, which has some significant edits since this was posted.
edit: unless you meant something like them having a SE 'user' to categorize posts? I think all Q&As are under CC, so they're legally capable of doing that, but it certainly looks to me like it's SE doing the posting, since that's how they display authors too.
I think the spreading of good SE Q&As is great. There are problems with it that essentially can't be resolved (stale data), but it does spread good information to people who may not have seen it otherwise. But this is sheer laziness, and ends up with something significantly less valuable than if they had just embedded the question in an iframe.
source: http://meta.photo.stackexchange.com/questions/2195/ars-techn.... (I couldn't find an official post specifically about their arrangement.)
You have to be the super-hero every day...
Of course the problem has a technical solution but the huge red flag is that there is no consensus. This means that whatever solution is put forward is going to upset someone and guess who the target of that ire is going to be.
The only way this is viable is if someone with real power is backing the project and what he/she says goes.
Of course that is the fairy tale and in reality the technical dragon will eat the knight and use his sword as a toothpick.
Slowly, slowly catch the monkey was a comment a COBOL programmer I worked with in the 80's would put in all his code (along with naming all his procedures after drinks, but lets not go there - shudder). I now, know why.
Knowledge based systems are great, but they do end up mixing the data into the code in a way that over time is fun.
I had to work on a real crazy bit of C code once that was larger than I cared for. I mearly found the parts that effected what I needed to do and changed that. It worked, no idea what most of the code did but the aspect of being to work with more than one radio controler was easily enough to change. No documentation and was a bit spag bowl. But it was a easy change and in many ways it was due to design of the programmer who had written it. He had allowed for such a change, not documented but was easy and changing a few variables mostly. Leason there is you can have code that makes no sence, but it gets the job done and if you need to change a particular part, if you can locate that part then you can read the effecting code and change what you need. If when codeing you plan ahead of possible future changes. Well nobody can ask any more.
If it works, why argue. If you can slowly and saftly make it work better then fantastic. Remember not all new wheels go faster or better than the ones they replace. Think about that incase you argue a rewrite. Rewrites for the sake of it one day and next you will be flying with the seagull managment.
Also worth factoring in that spaghetti code saves jobs and lives, I understand that joke now.
The basic idea is to, try to spend 1 hour on each of: 1. examine the code very quickly (try to do it in an hour or so), and based on the scan to guess what the top 4-5 subcomponents of a system are. 2. do quick code examinations to figure out what each subcomponent is supposed to be doing, and how each subcomponent is supposed to depend on the other subcomponents. 3. Now modify the code to reflect the above components. At the simplest, just move code into new directories for each component, but at more detailed levels you can make sure that there is never any single source file that has implementation for more than one component.
Now you are done. You can clean up code more if you want, but do that slowly. Just make sure to not put new code in bad areas. Yes, you will possibly have spent more than 1 hour on each part. But you should have a much better grasp of the code, and the code will not keep on deteriorating.
I am not really talking about badly documented code or code with bad naming conventions, or other related problems. However, when the big problem is the 'spaghetti' (and cyclic dependencies) - this has really been the only solution that has worked well.
If the software guy comes in and starts insulting the scientist guys' code, the game is over. If the software guy shows no desire to listen to what the scientist guys have to say, or learn anything about the problem domain, the game is over. But if the two sides can learn to work together toward a common goal, they might have a chance of success.
Every self-respecting Russian programmer will always try and convice you to rewrite everything from scratch. Regardless of the context. I'm pretty sure it's in their DNA.
This is not strongly exhibited amongst me and my friends. Maybe we are not self-respecting.
(I can't tell you how many times I have heard the same advice being given seriously)
Especially if your goal is not to duplicate the functionality of the old software precisely, but to provide a significant upgrade. It really depends on the requirements.
Understanding 200K lines of complex code well enough to be able to rewrite it is hard enough, even if it's just pure database or graphics software. If it's about something you know nothing about you're going to have to learn something about the domain first, just to understand if the output you're seeing is anywhere close to correct. You're going to need to know whether some odd behavior of the code is essential to its correctness and must be preserved, or an accident of its particular implementation which can be changed or removed.
Also, you can't just dump some system that people depend on to get their work done. You have to maintain it and fix bugs while writing its replacement. Given that he's just a lone developer and doesn't have the budget or authority to hire a large team of professional hackers to help him, his only chance for success is to start learning about the system, adding tests and making small refactorings.
Is this something that is portable skills wise, will you learn about the subject and will that skillset be something of interest and marketable down the line?
Reason I ask that is if your not interested in it and/or if it is such a niche feild that the knoweledge you will gain on the subject is not portable. Well, unless its a pasion, just remember one important thing: probation periods work both ways.