[Michael26]

Quote

I am newly employed as the sole "SW Engineer" in a fairly small shop of scientists who have spent the last 10-20 years cobbling together a vast code base. (It was written in a virtually obsolete language: G2—think Pascal with graphics). The program itself is a physical model of a complex chemical processing plant; the team that wrote it has incredibly deep domain knowledge but little or no formal training in programming fundamentals. 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.

Initially, I'm inclined to tutor them in some of the central concepts of The Pragmatic Programmer, or Fowler's Refactoring ("Code Smells", etc). I also hope to introduce a number of Agile methodologies. But ultimately, to be effective, I think I'm going to need to hone in on 5-7 core fundamentals; in other words, what are the most important principles or practices that they can realistically start implementing that will give them the most "bang for the buck."

So that's my question: What would you include in your list of the most effective strategies to help straighten out the spaghetti (and prevent it in the future)? Related: When is code "legacy"?

Source Link

This post has been edited by modi123_1: 07 August 2012 - 11:19 AM
Reason for edit:: fixed my added quote tag

[jon.kiparsky]

Some questions I'd be asking myself:

1 - who will be maintaining this when you're done? If that's not you, what are their competencies? This will determine large-scale stuff like whether you can consider porting to a more modern language, and also the style in which you rewrite. If you rewrite to patterns, you need to be sure the maintainers understand what you've done, or they'll just recreate the spaghetti by writing around your code.

2 - What's the budget, in time and in cash? Is this a wham-bam-thank-you-ma'am engagement, or something where you'll have time to really unravel it and put it on a firm footing?

3 - Is there design documentation, or are you pretty much working from the as-built code?

4 - Will you have a go-to person for resolving ambiguities? Is there a single person who can serve as your project owner?

5 - Can you institute unit tests to protect your work? This question both from a scope-of-work angle and also from a technical feasibility angle.

If you can unit test and you have either design documentation or an authoritative source, there's a clear path, which is easily explained by way of overview. If not, it's a little harder.

[modi123_1]

I fixed the post to accurately reflect that the OP wasn't asking the question, but merely bulk copying some one else's post that ars picked up.

[Michael26]

Yes, i wanted to know what do you do in situations like this.
The most extreme thing would be to start from scratch and plan ahead first

[Skydiver]

These two maybe good references: Working With Legacy Code, the paper, and Working With Legacy Code, the book.

If in his shoes, I would start off with getting some kind of SCM in place first as that is easily actionable. After that will be teasing out the design documents, specs, and any other documentation surrounding the legacy code. From that work out some kind of test framework so that any future changes can go through regression testing. Then the hard work comes in of training good coding habits.

[Celerian]

modi123_1, on 06 August 2012 - 02:32 PM, said:

I fixed the post to accurately reflect that the OP wasn't asking the question, but merely bulk copying some one else's post that ars picked up.

The last part you left out of the quote tag was actually a part of the quote too. The only thing that the OP added was a source link.

Source link also has a pretty detailed response to the problem.

[modi123_1]

*sigh*

[Ticon]

200 Lines of spaghetti code? . . . KILL IT!!! KILL IT WITH FIRE!!

But seriously if it were me, I would either rewrite the mess into something that half readable at least, or make a nice comment book. //go to line 36 to call foo()

[Skydiver]

Nuke it from orbit... it's the only way to be sure.

Unfortunately, that code base represents a multi-million dollar investment. You can't make that kind of decision. You're just a grunt.

The suits want you to bring that thing in to study. And so, study it you will before you start applying any code changes. It'll be doable, and you'll be calling the pile of crap b*tch more times than Ripley did, but you will succeed it making the code better.

To me, the harder part will be implementing a change in attitude with the long term owners of the code once you leave the project. You'll want to leave them with good tools, and far more important good programming skills to keep the code from devolving back into a mess.

This post has been edited by Skydiver: 15 August 2012 - 01:17 AM

[salindor]

Well I had something similar (thankfully though it wasn't for a job because well I kind of failed..., though as I write this I realize I have tackled smaller versions quite often actually).

Politics
- investigating the thoughts of other minions and managment is as important as delving in the code
- start by having a conversation with everyone who works with the code to find out
+ their current understanding
+ how adaptable they are (i.e. do they hate programming?)
+ bounce any ideas you think are practical off of them
- after talking to the minions talk to management to get a feeling for their expectations (or maybe sandwhich talking to managmenet)
- consider it an iterative process.
- start simple.
+ like scm is fairly low hanging fruit. get them into scm.
+ defensive coding is fairly low hanging. Maybe get them to start putting checks on functions to validate their input


Porting
- it is never as easy as you think
- sometimes the language has features the new language doesn't have (like FORTRANs mathmatical goto which was a pain to even find documentation as to what that was)
- sometimes the language construction forces a redesign. Like when porting a C++ to C# you may have to consider the garbage collection depending on the load of object creation.
- mistakes can be subtle (I found a few with the way the compiler did autocast in C and the assumption I made when porting to c++ can't remember the details anymore sadly)
- even when you know there is trouble waters like Fortan's array's are 1 based and C++ is 0 based when dealing with alot of code, you will still miss some formula somewhere that assumed the arrays are 1 based
- sometimes code works because the language has a bug in it (sad I know)

Refactoring
- think small (over time, larger and larger rewrites will occur as you become more familar with the code)
- look for isolated segments that could be brought up to date
- avoid thinking of multithreading a single threaded app unless you are completely rewritting the new multithreaded code (there is always a cross-refrence you just didn't see)

Anyways that would be my stab at it.

Salindor