

I've inherited 200K lines of spaghetti code—what now? - nsns
http://arstechnica.com/information-technology/2012/08/ive-inherited-200k-lines-of-spaghetti-codewhat-now/

======
Groxx
This is worthless.

It's a copy and paste of this question on Stack Exchange:
[http://programmers.stackexchange.com/questions/155488/ive-
in...](http://programmers.stackexchange.com/questions/155488/ive-
inherited-200k-lines-of-spaghetti-code-what-now) but with broken formatting,
and _nothing else_.

~~~
vineet
Yeah. There is no value being added beyond just copying Stack Exchange.

Is Ars Technica in trouble these days that they are just copying content?

~~~
mattdeboard
I think every news wire service in the world would disagree with the
perspective that you and the GP are espousing.

edit: I have made the mistake of using an analogy on the internet. I realize
it's not exactly the same, ok?

~~~
Groxx
Hah! You're probably right. I'd be interested in the thoughts of the people
running this show, if they'd drop in :| It would be an interesting debate, in
any case. I'm really having trouble seeing how this (particular instance, not
necessarily in general) is a good idea, or at all in line with SE's design.

------
fredsanford
I'd update my resume and start looking for a new job. I've been in this
situation twice in my career and neither ended well even with me busting my
arse making real improvements.

You have to be the super-hero every day...

~~~
reinhardt
Fully agree with the solution. What I don't get is how one ends up in this
situation in the first place. "I am newly employed as the sole 'SW
Engineer'...". How on earth did he go through phone screenings, interviews and
finally accepted an offer without any idea of the mess he got himself into
from day one?

~~~
coliveira
Unless you're very senior, it is hard to know exactly what you'll be working
on when interviewing for a company. And even when information is released,
companies usually paint a rosy picture of your new position and
responsibilities.

------
tlb
G2 is hardly "Pascal with graphics". It's Gensym's expert system for real-time
process controls: <http://www.gensym.com/product/G2>

------
Zenst
Slowly over time clean up the code and educating though examples and approachs
and standards and all agreeing and understanding them would be a good start,
nomatter the direction. Also if its viable to document, albeit organicly in a
way that you have a process to control changes, it can only help. One day you
will have it fully documented or cleaned up.

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.

------
vineet
I have found a particular/simple solution very helpful and I am surprised that
people don't talk about it (or perhaps don't know it).

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.

------
snorkel
You can't teach old dogs new tricks. Introduce best practices slowly in order
of priority otherwise if you overwhelm the old timers with lots of new coding
policies that they don't understand then they'll just dismiss it all as
useless bureaucracy.

~~~
greenyoda
Since the guys who wrote the original code are scientists or engineers, they
probably learn new tricks all the time within their own profession. The fact
that they realized that their code has become an unmaintainable mess and have
hired a software developer to help them out seems to indicate that they might
be open to listening to what he has to say.

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.

------
Kilimanjaro
Dump it and rewrite it in ten thousand lines of beautifully crafted code.

~~~
eps
Also known as "Russian refactoring".

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.

~~~
YuriNiyazov
Where is it known as such? Googling "Russian refactoring" brings up nothing
related.

This is not strongly exhibited amongst me and my friends. Maybe we are not
self-respecting.

~~~
huhtenberg
You are young yet :) Virtually every Russian dev over 30-40 I know is like
that. I am myself that way too. It always seems easier to redo from scratch
than to waddle through someone else's code.

~~~
zeroonetwothree
This is true of non-Russians as well.

------
Zenst
A important question you have to ask yourself above all others:

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.

------
InclinedPlane
You'll want these:

[http://www.amazon.com/Working-Effectively-Legacy-Robert-
Mart...](http://www.amazon.com/Working-Effectively-Legacy-Robert-
Martin/dp/0131177052)

[http://www.amazon.com/Refactoring-Improving-Design-
Existing-...](http://www.amazon.com/Refactoring-Improving-Design-Existing-
Code/dp/0201485672)

<http://www.bevmo.com/Shop/ProductDetail.aspx?ProductID=1282>

------
smashing
Two words: Bath Salts.

