Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

Saving The Project From Hell

By S1ack3rThanThou in Technology
Fri Jul 26, 2002 at 02:20:58 PM EST
Tags: Help! (Ask Kuro5hin) (all tags)
Help! (Ask Kuro5hin)

Software engineers out there, I implore you, please come and rally to the cry of a fellow engineer in peril.

Picture this scenario:

A lone junior software engineer has been cruelly outwitted by his senior engineers. They have created a monster and have run before our hapless hero has realised what they've done. They have committed the cardinal sin, they didn't "Keep It Simple, Stupid". When they realised their creation had grown beyond all control they left. But no! As if that wasn't bad enough this is no normal software project... This is a project of some 50,000 lines of C that has a small though expensive user base that requires updates on a regular basis (monthly), the ability to respond quickly to ANY bug and worst of all that the software has a reliable 24/7 uptime. He needs help. Can you save our hero before he crumbles into a stress ridden dribbly wreck?

Now that is not a good scenario, and unfortunately one that I appear to be in. In order to fix some of the large and nasty problems with the software some large parts have to be redesigned and/or pulled out. How do I do this when I must maintain a degree of stability in the project? I've already tried to make a large change twice and had to can it because it would have made the software too unstable to be able to do the constant small bug fixes and feature releases. It has to continue to be sold, the existing customers (about 40 odd) must be kept happy, and I wish to remain sane!

The whole thing is built upon linux and I have at least managed to get some form of version control in place. Despite all my training I don't know how to deal with it. I could come up with solutions or tactics if it was a normal P.C. based product that went to lots of customers, but this is an embedded system with a small user base that doesn't fit any of the styles of management I know of. I was always taught how to plan a project from scratch, how to prevent it becoming out of control and how to spot the signs of a project that is close to being a disaster. Unfortunately no-one ever explained how to rescue such a disaster.

Do any of you have any ideas? Are there any theories or good techniques for dealing with the maintenance of an inherited project that is in a state?

Hopefully this is a tale we can all learn from...


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Related Links
o Also by S1ack3rThanThou

Display: Sort:
Saving The Project From Hell | 127 comments (121 topical, 6 editorial, 0 hidden)
Start now.. (4.33 / 9) (#1)
by kb5 on Fri Jul 26, 2002 at 05:03:09 AM EST

1)Study the code and identify possible test cases and build a test harness.. Use code coverage tools if necessary

2)Build a working baseline, keep that always ready.. Use your VCS, learn branching /merging, etc..

3)Add more people & train them.. you cant do it all by yourself..

Boy would I like more people! (3.50 / 4) (#2)
by S1ack3rThanThou on Fri Jul 26, 2002 at 05:07:53 AM EST

Also do you know of any good resources for CVS to deal with branching merging etc?

"Remember what the dormouse said, feed your head..."
[ Parent ]
Re: (4.80 / 5) (#6)
by kb5 on Fri Jul 26, 2002 at 05:51:32 AM EST

CVS manual at cvshome.org

That should be a good enough start.. Also as a lone developer, CVS is ideal for you, as dont have to worry about multiple checkouts etc..

BTW, the problems you have described are not unique to you, millions of people are doing similar maintenance work..

So quit slacking, and get to work ;)

[ Parent ]

I agree they aren't unique (3.66 / 3) (#7)
by S1ack3rThanThou on Fri Jul 26, 2002 at 05:54:36 AM EST

BUT, there isn't anything out there talking about maintenance work that I am aware of. There are plenty of theories and techniques for design, are there none for maintenance?

"Remember what the dormouse said, feed your head..."
[ Parent ]
Outsourcing ;) [enty] (3.00 / 2) (#10)
by kb5 on Fri Jul 26, 2002 at 05:59:24 AM EST

[ Parent ]
Seriously.. (3.50 / 4) (#15)
by kb5 on Fri Jul 26, 2002 at 06:36:01 AM EST

this is like trying to fix the shape of a clay pot after all the burning and annealing is over..

All you can do is plug it when it leaks..Make a new pot if you have the time&money.

[ Parent ]
rubbish (4.83 / 6) (#23)
by codemonkey_uk on Fri Jul 26, 2002 at 08:41:07 AM EST

What a load of codswobble. Source code is infinitely manpulatable. If he was working with a binary, and no source code, *then* it might be like "trying to fix the shape of a clay pot after all the burning and annealing", but even then its a crap metaphor.

True story: When I was working on Magic & Mayhem, the publishers sent a copy of the binary to a Chinese contractors for an analysis report on porting to use Unicode or multibyte characters. Instead of a report, the sent us back a Kanji/unicode build. They had reverse engineered the binary, translated the text and added the necessary support code.
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]

Whoa. Now THAT is some hardcore coding! [n/t] (5.00 / 1) (#38)
by S1ack3rThanThou on Fri Jul 26, 2002 at 10:08:26 AM EST

"Remember what the dormouse said, feed your head..."
[ Parent ]
Re: (3.66 / 3) (#64)
by kb5 on Fri Jul 26, 2002 at 12:40:41 PM EST

I never said code cannot be manipulated.. My point was it would need substantial re-engineering to get to a point where you are satisfied. [if the code was as bad as the author made it out to be]

The chinese contractors may have reverse-engineered the binary. But I wouldnt be wasting my time in re-engineering, especially when an application needs 24/7 support and constant updates.

Agreed the metaphor was crap, i havent heard of claypots being plugged either:)

[ Parent ]
Chinese Kanji? (5.00 / 1) (#66)
by decaf_dude on Fri Jul 26, 2002 at 01:45:20 PM EST

Must be something new, different from the Japanese Kanji we all know about...


[ Parent ]
Chinese kanji (5.00 / 2) (#81)
by Shpongle Spore on Fri Jul 26, 2002 at 04:09:22 PM EST

Japanese kanji are just Chinese characters, identical to the ones used everywhere until this century and still used everywhere but mainland China, where they're adopted simpler versions of a lot of characters. "Kanji" is Japanese for "Han characters"; in Chinese they're called "hanzi", or usually just "zi" (pronounced more like "zz").
I wish I was in Austin, at the Chili Parlor bar,
drinking 'Mad Dog' margaritas and not caring where you are
[ Parent ]
wincvs (4.50 / 2) (#65)
by eurasian on Fri Jul 26, 2002 at 01:03:47 PM EST

if u are doing any dev on on a windoze box, i find wincvs to be quite useful. it's great to visualize branching and merges and sticky tags, all that fun stuff.

tortoisecvs (integration of CVS with your explorer) is also quite nice.

a quick list of commands

the CVS FAQ-o-matic!
cheers, J

[ Parent ]
Alternatively... (2.66 / 3) (#3)
by ariesboi on Fri Jul 26, 2002 at 05:08:33 AM EST

And possibly easier - run like they did.

[ Parent ]
A nice idea but... (3.50 / 2) (#4)
by S1ack3rThanThou on Fri Jul 26, 2002 at 05:18:26 AM EST

If I can fix this, its really good experience and will look great on my C.V. Also I've left three jobs previously a little quickly and should do at least two years here. Finally, and most importantly, I really like it here!

"Remember what the dormouse said, feed your head..."
[ Parent ]
Yeah... (3.50 / 2) (#5)
by ariesboi on Fri Jul 26, 2002 at 05:20:58 AM EST

I figured you wanted to stay, you didn't mention the possibility of leaving in your post... I'm just being silly at 5:30am before the coffee kicks in ;)

Good luck & best wishes

[ Parent ]
What are code coverage tools? [n/t] (3.50 / 2) (#9)
by S1ack3rThanThou on Fri Jul 26, 2002 at 05:59:12 AM EST

"Remember what the dormouse said, feed your head..."
[ Parent ]
Code coverage (5.00 / 1) (#106)
by sigwinch on Sat Jul 27, 2002 at 09:54:50 PM EST

It's a particular use of a profiler to find out which lines of the source code are not being executed. Knowing that lets you add tests so that more of your code is tested. If you find code that cannot be easily executed (such as weird exception handlers) you can give it extra attention during the code review.

I don't want the world, I just want your half.
[ Parent ]

Q: wtf is "Code Coverage?" (none / 0) (#123)
by Nyarly on Tue Jul 30, 2002 at 06:58:07 PM EST

Answer: http://faculty.erau.edu/towhid/cem.html

Damn I'm lazy. Okay, penance:

Picture you're automated testing tool. How do you know what whether you tested everything that could be wrong? The tautology is that a test can only prove that your code is wrong, not that its right. Coverage is a measure of how close to the impossible ideal of testing: that the tests test for everything that might be wrong.

The page linked to is a list of 100+ different ways of measuring coverage. All in all, its a way of evaluating your tests, automated or not.

As far as automated tools go, I'm dubious about their real utility. Maybe for management.

"The believer is happy. The doubter is wise" --Hungarian Proverb
[ Parent ]

Yup (4.83 / 6) (#16)
by Rogerborg on Fri Jul 26, 2002 at 06:41:02 AM EST

    identify possible test cases and build a test harness.

If you're embarking on a re-engineering, this is the most productive thing that you can do.

If you have a test harness that can automatically test the entire product as a black box, then you can be a lot more confident about making major code changes. If the test cases run OK before and after the change, you can generally sleep easy. It doesn't remove the need to do white box and code coverage testing, but if you can come up with a critical list of the inputs and outputs that your software is supposed to produce, then you're half way to being in control of it.

Always push for enough resource to write the test cases before the code. After all, if you can't test it, how do you know when it works, or when it's done? That will probably mean that you don't do any of those rapid bug fixes and feature releases for a while, but the pay off is in long term savings and stability.

And incidentally, 50,000 lines is very small as software project go, even for an embedded system. You can tame this.

"Exterminate all rational thought." - W.S. Burroughs
[ Parent ]

This is your opportunity. (4.66 / 12) (#8)
by crzm on Fri Jul 26, 2002 at 05:55:45 AM EST

Take charge. Quit fucking around. You have two choices here; you can be a junior engineer and do a lot of talking, or you can be a senior engineer and help fix the problem.

Consider yourself lucky, in a way. You already have a working prototype to base your future work on. Most likely, when the current code was written, the scope of the problem that it was trying to solve was not as defined as it is now.

You're misidentifying your current emotion as 'overwhelmed'. From now on, classify it as 'opportunity knocking'. You seem to know where you want to go. So try to disappear off the radar for a bit, and try to get a 2 week refactoring session in on your favorite module. Then it's time to announce your changes, but be careful. Management has to have a reason to accept the change (bug fixes, extra functionality), while you also want the seniors to respect your changes and judgement. Pick your first project wisely. If you move a tiny bit against the grain with good success, you put yourself in a leadership position, which is what you want. A couple months of this and you will be a senior engineer yourself. You need to prove yourself. Trial by fire.

FWIW, I'm a senior engineer myself, currently contracting on a 100,000 line embedded codebase. I almost guarantee this will work, I've done it. The majority of people out there are gutless bastards. Rise above 'em.

I agree, I do see this as an opportunity (4.00 / 3) (#11)
by S1ack3rThanThou on Fri Jul 26, 2002 at 06:00:21 AM EST

I was just asking for help as to how to tackle it. You must've have learnt some do's and don'ts in your time?

"Remember what the dormouse said, feed your head..."
[ Parent ]
Don't let... (3.20 / 5) (#20)
by Trollificus on Fri Jul 26, 2002 at 07:56:17 AM EST

...one of those "gutless bastards" try to take credit you rightfully deserve. It's like a shark tank in the tech world. If you don't watch your back, you're going to end up with a knife in it.

"The separation of church and state is a fiction. The nation is the kingdom of God, period."
--Bishop Harold Calvin Ray of West Palm Beach, FL
[ Parent ]

Sharks have knives? (n/t) (none / 0) (#125)
by unDees on Mon Aug 05, 2002 at 07:08:26 PM EST

Your account balance is $0.02; to continue receiving our quality opinions, please remit payment as soon as possible.
[ Parent ]
Yup (5.00 / 1) (#127)
by jayhawk88 on Tue Aug 06, 2002 at 11:21:02 AM EST

Some even have freakin laser beams on their heads.

Why, then, should we grant government the Orwellian capability to listen at will and in real time to our communications across the Web? -- John Ashcroft
[ Parent ]
Ok... (4.00 / 1) (#108)
by crzm on Sat Jul 27, 2002 at 10:56:47 PM EST

First things first. From the sounds of it, nobody expects you to immediately resolve most of the underlying issues. This works to your advantage here.

First, spend at least a week auditing as much of the core/critical path code as possible. But do not write any code; just think. Deeply think. The more hurried you are, the less effective you will be, so think big picture. And take good notes. While browsing the sources, think:

1. Which code areas are strong candidates for immediate, quick cleanup? Some people really don't seem to understand what header files are all about. If you're seeing 'extern' in places other than header files, it's a strong indication that the code needs a cleanup.

2. Which code can be extracted close to 'as is' and combined with other code throughout the codebase to form a logical module? Parsing-related code is the most common culprit in my experience. How long will it take to extract the code and introduce a common naming style within the module? Probably shorter than you may think.

3. Which multi-thousand line functions are a candidate for splitting up into smaller, static functions? When code is poorly designed and then maintained for a length of time, these functions grow like a cancer. Similarly, which files would best be broken up into multiple files?

4. Code factoring. Similar to #2, but deeper. Think of it as factoring polynomials. So two modules internally use balanced binary trees. Think: would a shared AVL or red-black library simplify things? Probably.

5. Deep underlying issues. Do the shitty and confusing makefiles prevent people from splitting files up? Are the header files so disorganized and scattered that nobody can make sense of them? Does management excessively meddle in code patches, resulting in discouragement of refactoring? What's going on here: why did things get so bad to begin with? Without at least considering the deepest issues, you may fall into the same trap as your predecessors. Don't be afraid to go against the grain a very slight amount. They hired you because they know you can think for yourself.

These points are in order, so after each point, try to think about the code as though you'd already done it. And if you're smart, you'll do small changesets, and avoid merge-from-hell syndrome down the road. Also, you need to have your own, private version control tree for whatever you're refactoring. I've witnessed months of work go to waste because management was hesitant about a huge changeset adversely affecting the bottom line.

There's plenty of other things to do that I haven't mentioned here, but I think that this is a good start. Remember that if it feels wrong, it probably is, and you should immediately take a coffee/tea/water break and think things over. It's an order of magnitude easier to change your code while it's fresh. Also, static and const are your friends.

Hope this helps the situation. I think you'll do just fine, you're already on the right track.

[ Parent ]

Refactoring? (4.25 / 8) (#18)
by bodrius on Fri Jul 26, 2002 at 07:09:51 AM EST

I haven't faced that situation yet, so don't take this advice as coming from experience, but it sounds like you should get a copy of Fowler's "Refactoring" (or any other good introduction to refactoring) and build a refactoring schedule for your project.

Refactoring is supposed to exist as a methodology precisely for these situations, either to solve them when they present themselves, or to stop them at some point in the process.
Freedom is the freedom to say 2+2=4, everything else follows...

Design in your Image (5.00 / 1) (#88)
by cam on Fri Jul 26, 2002 at 08:32:55 PM EST

Refactoring is supposed to exist as a methodology precisely for these situations

On small codebases that you end up with code ownership of, it is also useful for redesigning to your image. Like some other posts have mentioned the first reflexive action of most software engineers upon getting onwership of an existing codebase is to say, "this is stupid, it all sucks, I will redesign it better than this, and make it rock dude....!".

Design is pretty personal and small companies end up being influenced by a gifted designer or developer in their office. I know in our office, that gifted developer is influenced heavily by the Jakarta opensource projects and the design methodologies of those projects.

With small codebases that havent the time, the money or the customers to redesign to a new codebase, refactoring is also useful for putting a personal or office design imprint on the codebase that will make it easier to maintain in the future. Especially if it is poorly documented.

It might not be the best thing to do, but two of the most successful projects I have been on have had a less than 8 month development time but a plus 60 months in support, maintenance and change orders. That is in telecommunications, I am sure the banking industry can beat that hands down.

Codebases which arent supported disappear quickly and are forgotten just as fast, but supported codebases of very successful applications in my experience hang around for a long enough time to warrant looking into refactoring to your personal/office's design and management style.

Freedom, Liberty, Equity and an Australian Republic
[ Parent ]

Cleaner first implementation too (none / 0) (#99)
by bodrius on Sat Jul 27, 2002 at 03:50:25 AM EST

Well, as I said I have not had to cope with a monster project yet so as to apply Refactoring for neither damage control yet, nor redesigning dramatically an existing codebase; that's where it seems most of the benefit lies.

I still have found Fowler's book immensely helpful while coding even the first implementation of each class on my own codebase.

Basically, even when I have a fully functional class, I don't consider it a deliverable first implementation unless I spent an extra 10-20% development time refactoring it.

Sometimes I end up just cleaning up the code a litte, but sometimes I change dramatically the code, I think for the better. A few design patterns are simply easier to apply in hindsight, and the refactoring methods help to be more methodical than just "reviewing the code".  

Of course, this doesn't count when someone is desperately waiting a "deliverable" (in that case I'll have to refactor for another release), but when there is time, I think it's worth it.
Freedom is the freedom to say 2+2=4, everything else follows...
[ Parent ]

Don't redesign (3.40 / 10) (#19)
by psychologist on Fri Jul 26, 2002 at 07:46:20 AM EST

I'm no programmer, but common sense will tell you that
  1. What is inexplicable to you is obvious to others.
  2. If you rewrite the thing, so that you understand it perfectly, the next programmer that comes along after you have left will want to rewrite the entire thing once again, because he cannot understand it.
In other words, don't start afresh. Just try to understand what is already there.

don't throw out old code (4.44 / 9) (#21)
by tps12 on Fri Jul 26, 2002 at 08:28:41 AM EST

My only advice is to think carefully about what everything is doing before you change it or replace it. Large, messy projects tend to have plenty of confusing chunks of code, and if you don't know why it's there then you should find out.

A mysterious piece of code could be cruft, or it could be a workaround to a subtle bug that may or may not still be relevant, and if the comments don't reveal which of these is correct then you'll have to do it yourself. The absolute most effective way of doing this is by asking someone who knows: "hey, so why are you using this data structure here rather than this one?"

If you start cutting stuff out right and left, then you will end up reinventing many, many wheels. Since the whole point is to save time for you and other developers in the future, don't negate your efforts by wasting time when you can avoid it.

Yeah, but.... (none / 0) (#126)
by unDees on Mon Aug 05, 2002 at 07:37:11 PM EST

All the non-obvious pieces of code whose purpose is to work around some other subtle issue are documented as such.... Right?

*returns to real world* 'Course, who knows whether or not the guys who wrote all these lines of code our hero hopes to untangle were so courteous.

Your account balance is $0.02; to continue receiving our quality opinions, please remit payment as soon as possible.
[ Parent ]

Been there, done that, got new job. (4.12 / 8) (#22)
by wiredog on Fri Jul 26, 2002 at 08:31:25 AM EST

My first job out of college (this was in early 95) I inherited a 100,000 line C program that was originally written to run on a (16 bit) 8088 on MS/DOS 1. There were few comments, the ones that were less than helpful. Along the lines of:
/*Why did I do this?*/

He did it because he was setting bits in a 16 bit int to track whether a value was set. Why? Well, it was designed to run on an early 8088, so using an array of 16 bytes instead of one 16 bit int would have taken too much RAM. Of course, when it came time to migrate the crawling horror to 32 bit I had to go through and find every occurrence like that and convert 'int' to 'long'. Arrgh. Oh, and the same code had to work on 16 bit DOS and 32 bit extended DOS. Thank K&R for typedef and #define. Do not assume that the size of a type will remain forever unchanged.

Comment everything. Yes, i and j are usually loop variables. You should still comment them. "int i,j;//loop counters" will save you, and your successors, much heartburn.

That crawling horror I worked on? It's still running. And, thanks to the typedefs and #defines, it will be reasonably easy to port to a 64 bit architecture in the future.

Can't sleep. The clowns will get me.

Inherent problems with C (2.33 / 3) (#47)
by RyoCokey on Fri Jul 26, 2002 at 10:30:21 AM EST

I'd argue that the sizes changing with the platform is an inherent error in C. More consistant languages such as Pascal and Assembler have variable types remain constant across all versions.

The troops returning home are worried. "We've lost the peace," men tell you. "We can't make it stick." - John Dos Passos
[ Parent ]
Ummm, no. (3.75 / 4) (#49)
by wiredog on Fri Jul 26, 2002 at 11:04:24 AM EST

We're talking word size here. This has little to do with what the language datatype size (assuming there is any (assuming it even has such a thing, i.e. perl, python, basic)) is.

On the 8088/80186/80286 a word was 16 bits. 386 and above (IA32) it was 32 bits, IA64 is 64 bits. Word size frequently changes with platform. A Pascal integer may, depending on compiler and platform, be 8, 16, 32, or 64 bits. Well, the "size" of "integer" may have been fixed, but then you need different integer types to accomodate the different word sizes. The Windows API (for C) does this with INT_8, INT_16, ..., INT_64. "short" is always (now...) 16 bits and "long" is 32. x86 assembly doesn't have 'integer' per se, it just uses words or bytes.

If you aren't interacting with hardware, this usually doesn't matter. If you do embedded programming it is vital.

And then there's the whole "endianess" issue...

Can't sleep. The clowns will get me.
[ Parent ]

*tap* *tap* (4.00 / 3) (#51)
by pb on Fri Jul 26, 2002 at 11:08:14 AM EST

I too try to give people the benefit of the doubt, wiredog, and he's making a very good point about C which some people do perceive to be a flaw.  But if he were going to cite lanaguages that don't have variable-sized types, then he'd site Java, not Assembler (since Assembler is entirely platform-dependent, you might have 9-bit or 36-bit types, whereas Java does its best to ignore the underlying platform entirely, and also pays the price for this...).

Therefore, you were either dealing with a stupid troll or a remarkable moron, and either way it probably wasn't worth your time...
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]

Probably neither (4.00 / 3) (#58)
by wiredog on Fri Jul 26, 2002 at 11:24:36 AM EST

troll nor moron, just someone who hasn't done any programming that requires knowledge of these things.

Although the assembler "versions" idea is rather funny.

Can't sleep. The clowns will get me.
[ Parent ]

no, it's definitely one of those... (5.00 / 2) (#59)
by pb on Fri Jul 26, 2002 at 11:34:20 AM EST

Well, if you have no knowledge of the subject, but yet you post about it anyhow, then that would make you a moron.  :)

The only assembler I know that's consistent across all "versions" or "platforms" would probably be "C", and then we're back to where we started...  ;)
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]

No need to be insulting (2.00 / 2) (#75)
by RyoCokey on Fri Jul 26, 2002 at 02:52:36 PM EST

I wouldn't cite Java because I'm unfamiliar with the language. As for assembler, one generally means x86 assembler by default, just as if you said "I'm coding this project in C." people would probably think VC++ even though insufficient information was provided. I should have specified, sorry.

As I mention farther up in the post, the size of variables in (x86) assembly is always fixed. A word is 16-bits regardless if you program it on a 8088 or a Pentium 4. I imagine it is similiarly fixed on other platforms, as I can't imagine an assembler that would let you float the variable size, since references to exact locations are frequently done, which would be broken by altering the variable size by platform.

Altering the variable size based on platform, along with case-sensativity and in general poorly legible language structure and reasons I despise C and it's offspring. I do a fair amount of programming, including several programs entirely in x86 assembler. I'd include my programming page, but it's offline at the moment due to hosting issues.

Your last line is simply insulting. If anything is to be learned from kuro5hin.org it's that morons are so common as to be unremarkable. :P

The troops returning home are worried. "We've lost the peace," men tell you. "We can't make it stick." - John Dos Passos
[ Parent ]
oh well (4.00 / 3) (#86)
by pb on Fri Jul 26, 2002 at 07:52:44 PM EST

When people say they're coding a project in assembler, they mean just that; no platform is specified.  I know a guy who programs DSP's for TI, and they have assembler instructions that we've never heard of for very special purpose tasks, just as the x86 architecture has MMX and whatnot.

Similarly, when someone says they're programming something in C, they might mean ANSI C (in the past, they might have meant K&R C) but again you can never assume the platform--C is designed to run on different platforms, and to be easily ported to them.  And you can never assume that if someone says they're writing in C that they're actually writing it in C++! (unless they enjoy casual deception)

Words (and bytes) can be different sizes on different platforms, and sometimes there are restrictions on what size variable can be used with what operation.  C alters the variable size based on the platform because it's efficient, but usually you can use a typedef to get around this. However, I don't see how it matters if you only use x86, although the rest of the world might not.

I'm not a huge fan of case-sensitivity, but I think it's really a non-issue--I generally keep things in lowercase, except for constants.  What do you mean by "poorly legible language structure"?  Both of those are really just syntax and grammar issues, and have nothing to do with the actual language, but of course you have a right to your personal preferences.

The reason I cited Java is because its types do not vary based on platform; this can make things slower, but with Java I guess that's really not the point.  You might like it, although it does share some syntax with C; personally, I like C and can't stand Java.  :)

I'm sorry if you feel offended, but I'm still not convinced that you realize the depth of your ignorance here; therefore, I'm not sure that an apology is in order on my part.
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]

Novel Definition of Efficiency (none / 0) (#96)
by RyoCokey on Sat Jul 27, 2002 at 01:36:47 AM EST

How is shrinking a variable below it's required size (porting from high bit machines to older ones) or expanding it to consume more memory (older machines to newer ones) efficient? If you wish to alter your code for the width of the registers, you should change your alignment settings during compilation.

Words and bytes are never different sizes on any platform where the code would be relevant. If you are aware of a system that shares the same instruction set, yet has a varying definition for byte/word size, please do post a link.

The troops returning home are worried. "We've lost the peace," men tell you. "We can't make it stick." - John Dos Passos
[ Parent ]
what? (5.00 / 2) (#97)
by pb on Sat Jul 27, 2002 at 01:49:38 AM EST

What the hell are you talking about?

The reason C "changes" the size of a word is because it uses the size of the system word, and multiples thereof.  This is efficient, because it's what is done on the host platform, i.e., a 16-bit machine works better with 16-bit values, as opposed to a 32-bit machine, etc., etc...

If you're really worried about having a 16 bit value as opposed to an "int" in C, you should use a typedef of some sort, like uint_16 or something.

This is really the most important when you're switching between completely different platforms; for example, 64-bit code on the Alpha.  The width and endianness can break a lot of x86-specific code, which is why code should be written with an eye towards portability in the first place.

However, we'll have 64-bit x86 machines soon enough, and it isn't that much trouble to port a properly-written C program to use them.  Much less trouble, I'd imagine, than the retrofit a language that wasn't designed to be as portable as C is.
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]

That's exactly what the problem is (5.00 / 1) (#103)
by RyoCokey on Sat Jul 27, 2002 at 12:07:21 PM EST

In the example he gave the author incorrectly used the int type, which then changed size when he ported it, breaking the rather unusual application he was using it for. He should have indeed used the fixed-size declaration, but he did not. My point about it changing sizes being a disadvantage was:

Your 16-bit int becomes a 32-bit int. You've wasted 16-bits, and if you do an operation to fetch the highest bit, it will return one of the 16 unused (zeroed, I imagine) bits. If you're concerned about losing clock cycles because you're accessing a 16-bit word on a 32-bit computer, you need to set the data alignment on your compiler to DWORD aligned (4 bytes).

If your 32-bit int becomes a 16-bit one, you have even greater problems. If you needed the whole 32 bits, your operations will now overflow.

In addition to both these cases, calculating the size of data structures (For memory allocation, size on disk) needs to take into account the size of the variables (Which is not constant.) You can generally get around this with the sizeOf() function, but if apparently this guy encountered a case where he couldn't do so.

I'm just having a little trouble seeing the advantage of these "floating-size" variables.

The troops returning home are worried. "We've lost the peace," men tell you. "We can't make it stick." - John Dos Passos
[ Parent ]
right (5.00 / 1) (#105)
by pb on Sat Jul 27, 2002 at 01:09:05 PM EST

It's easy to write non-portable code, and that's just what he did.  You can't rely on the fact that sizeof(int) will be 2 or 4 or whatever; rather, you're supposed to use sizeof() to find out what it is in the first place.  :)

The advantage is that you're aware of the underlying platform; the disadvantage is that your code has to be aware to some extent as well.  In assembler, some might argue that you're too aware of the underlying platform.  :)
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]

The evils of endianness... (4.33 / 3) (#52)
by porkchop_d_clown on Fri Jul 26, 2002 at 11:10:13 AM EST

I'm working on lowlevel networking protocols and prerelease hardware these days. Constantly dealing with x86 guys who have no clue what "network byte order" means and why they have to care...

In anticipation, John licked his own lips.
- A. Lloyd -

[ Parent ]
byte order (3.66 / 3) (#53)
by wiredog on Fri Jul 26, 2002 at 11:12:55 AM EST

It's fun when you're working with a board, writing the driver, and the docs are unclear as to which is the high byte or, for that matter, the high bit.

Especially if the board controls moving parts.

Can't sleep. The clowns will get me.
[ Parent ]

Oooo yeah. (none / 0) (#69)
by porkchop_d_clown on Fri Jul 26, 2002 at 02:08:01 PM EST

Ummm... Which way is the motor turning now?

In anticipation, John licked his own lips.
- A. Lloyd -

[ Parent ]
Attach a Diode (n/t) (none / 0) (#76)
by RyoCokey on Fri Jul 26, 2002 at 02:53:31 PM EST

The troops returning home are worried. "We've lost the peace," men tell you. "We can't make it stick." - John Dos Passos
[ Parent ]
This is outright incorrect (1.00 / 5) (#74)
by RyoCokey on Fri Jul 26, 2002 at 02:42:50 PM EST

I rarely rate the comments of people who disagree with me, but in your case, you've posted a completely false statement.

A word is always 16 bits. It is a fixed size regardless of platform, and further larger data structures are defined as multiples of it (DWORD, QWORD, etc.)

You quote the Windows API, but this is where the variable size floats. It is a complete and fictious artifact of the language. Compilers translate the meaning of "integer" or other terms into the actual variable size, based on the platform. It is not a natural adaptation at all, but a intentional modification.

Pascal in it's original form also did this, however later and generally used versions of the language abandoned "floating" variable sizes. You can see this is modern versions of the Pascal such as TMT-Pascal and Free Pascal.

Hence, his problem regarding the variable size is due to language shortcomings, not any inherent problem with the code.

The troops returning home are worried. "We've lost the peace," men tell you. "We can't make it stick." - John Dos Passos
[ Parent ]
However you define word... (5.00 / 3) (#79)
by Farq Q. Fenderson on Fri Jul 26, 2002 at 03:04:14 PM EST

does not have any impact on how much data a given CPU will be capable of handling as an atom. This size is frequently referred to as a "word" - correctly or no, it doesn't change functionality any.

If you reread the original post there, you'll find that the only shortcomings were in the machine itself (maximum word size, availability of RAM, etc.) You can explicitly declare your integers to be of any legal size, but generally, going with the architecture is most useful.

Besides, real programmers don't need baby-sitters.

farq will not be coming back
[ Parent ]

In that case, the original mistake... (1.00 / 2) (#82)
by RyoCokey on Fri Jul 26, 2002 at 05:21:12 PM EST

...would have been made by the guy who he inherited the code from. Needing a boolean flag for 16 values, he used a 16-bit variable. However, the variable type floated (Did not remain 16-bit) so the top 16-bits were now different. This also adjusted the size of his structures, as he mentions.

The maximum register size has nothing to do with this problem, as he could have performed this same task with 8-bits, with two bytes serving as the boolean "arrays." The problem was that the actual space used to store the variable altered thanks to (what I consider) a fault in the language.

The troops returning home are worried. "We've lost the peace," men tell you. "We can't make it stick." - John Dos Passos
[ Parent ]
Oh. (4.00 / 1) (#93)
by Farq Q. Fenderson on Fri Jul 26, 2002 at 10:45:25 PM EST

Well, I personally like that feature. It's a handy definition of the highest maximum-wordsize integer. There's explicit definitions for other int sizes, so I don't see the problem. It's bonus functionality. You can hardly blame C for a programmer's mistake.

If there's anything I'd do about C, it's to completely redesign the typecasting and take out the stuff that causes pointers to pretend C knows what you want to do with them. I can handle pointers and types better in my own mind than I can by letting the compiler do it for me. (What part of void don't you understand?!/)

farq will not be coming back
[ Parent ]

Type checking (1.00 / 1) (#94)
by RyoCokey on Sat Jul 27, 2002 at 01:15:15 AM EST

Perhaps it's the background in assembly, but I've always wanted a compiler option to turn of type checking altogether. If I wish to add 47 to 'h' why shouldn't I be able to?

If you like C, however, tell me this: What purpose does case sensitivity serve?

The troops returning home are worried. "We've lost the peace," men tell you. "We can't make it stick." - John Dos Passos
[ Parent ]
A few things... (5.00 / 1) (#95)
by Farq Q. Fenderson on Sat Jul 27, 2002 at 01:26:35 AM EST

W.R.T. type checking, agreed, though I'd rather just have a typeless type that wasn't such a hassle to use. That way any type checking I wanted would still be there.

As for case sensitivity, I'll often do this:

typedef struct something {
// blah

so that I can do this:


instead of:

struct something foo;

This way I know what the stuct is called, even though I'm using a typedef.

In addition, everything I #define is in all caps, since I wouldn't want it to interfere with a potential variable or whatever of the same name.

But philosophically, in C you have to take care of things, and this imposition helps to put you in the habit.

farq will not be coming back
[ Parent ]

Word size (5.00 / 3) (#107)
by sigwinch on Sat Jul 27, 2002 at 10:16:11 PM EST

A word is always 16 bits. It is a fixed size regardless of platform, and further larger data structures are defined as multiples of it (DWORD, QWORD, etc.)
This is an erroneous and exceedingly provincial point of view, probably taken from the tasteless and ill-conceived usage adopted by a small team of people at Microsoft in the late '80s. The fact that it later became wildly popular does not make it correct.

A word is a the "natural" data size of a particular digital data processing system. A multi-drop RS-485 (IIRC) communication system I once worked on had 9-bit words. The PIC 16F84 microcontroller has 14-bit program words, but 8-bit data words! Plenty of classical RISC CPUs have 32-bit words (any many are physically incapable of addressing a smaller unit of memory).

Also, I find the statement earlier that assembler generally refers to IA-32 (a.k.a. x86) assembler to be provincial too. My colleagues write assembler for all sorts of processors -- Microchip PIC, TI MSP430 family, various TI DSPs, Motorola 68HC11, a wide variety of 8051- and 80251-compatible microcontrollers -- but I would be surprised if the company has even a single line of IA-32 assembler in the source control system.

I don't want the world, I just want your half.
[ Parent ]

loop variables (5.00 / 2) (#92)
by bolthole on Fri Jul 26, 2002 at 10:28:14 PM EST

The thing about

int i,j; /* loop variables */

is that they're fine, as long as they are only used for trivial stupid little loops like

for(i=0;i !=1000;i++)){ /* cant use &lt here */


The trouble is, the kind of people who use "int i", almost never stick to only using it in the trivial case. So rather than "commenting your loop variables", make the variables your comments!!!

int arrayndx;
for(arrayndx=0 ...)

if you cant type fast enough to make the extra letters unnoticed effort, then you're not a professional programmer. Go learn to type, then start coding!

[Reason i,j are bad: you cant search or replace on them reasonably. Well, 'j' isnt usually too bad for search. but 'i' is horrible]

[ Parent ]

Loop variables (none / 0) (#112)
by Razitshakra on Mon Jul 29, 2002 at 07:59:12 AM EST

[Reason i,j are bad: you cant search or replace on them reasonably. Well, 'j' isnt usually too bad for search. but 'i' is horrible]

Use ii and jj then! Searchable and easy to type.

Lets ride / You and I / In the midnight ambulance
- The Northern Territories
[ Parent ]
ii and jj (none / 0) (#118)
by bolthole on Mon Jul 29, 2002 at 09:28:19 PM EST

but, I get dizzy looking at ii and jj


[ Parent ]

no, use i and j (none / 0) (#129)
by NotZed on Wed Aug 14, 2002 at 04:48:01 AM EST

Dont use arrayndx or arrayindex or any other horrible concoction.

i, j, and k work fine. arrayndx is just hard to type, and even worse, completely meaningless for anyone who isn't an english speaker (or confusing for someone who isn't good at it).

If you're going through searching and replacing such variables often, you probably have other poor design processes in place that should be fixed.

[ Parent ]

Cometh the hour, Cometh the man. (3.42 / 7) (#24)
by noogie on Fri Jul 26, 2002 at 08:51:50 AM EST

Been said already, but yeah, get your arse in gear and put in a good show.

Ok, it might be hard, youre gonna have to work like a bitch, but you'll learn a pack of stuff and it will be great experience, and will only help your career.

Or alternatively, If it gets too much, just say bollocks to it and quit like the others.

I shall see this one out, I can assure you. (3.00 / 1) (#28)
by S1ack3rThanThou on Fri Jul 26, 2002 at 08:59:09 AM EST

Mind you, it'll prolly only exist as an active product for another two years.... thus spake b.gates I guess!

"Remember what the dormouse said, feed your head..."
[ Parent ]
2 years? forget it... (none / 0) (#101)
by Caton on Sat Jul 27, 2002 at 05:25:24 AM EST

You won't get any funding to improve the product in that case. Get the hell out from that company.

As long as there's hope...
[ Parent ]
Cometh the emacs. [nt] (none / 0) (#109)
by Stick on Sun Jul 28, 2002 at 07:17:33 AM EST

Stick, thine posts bring light to mine eyes, tingles to my loins. Yea, each moment I sit, my monitor before me, waiting, yearning, needing your prose to make the moment complete. - Joh3n
[ Parent ]
Adding emacs to a late project (none / 0) (#113)
by rdskutter on Mon Jul 29, 2002 at 08:19:08 AM EST

will make it later.

Stick with VI - its less painful in the long run.

If you're a jock, inflict some pain / If you're a nerd then use your brain - DAPHNE AND CELESTE
[ Parent ]

Two words: automated tests (4.73 / 15) (#25)
by richieb on Fri Jul 26, 2002 at 08:52:13 AM EST

Before you can go redesign and refactor, you need an automated test suite that will keep you honest. So, first I'd spend some time writing tests that excercise the most critical system behaviors. These tests must run automatically (i.e. you type "make testall" and they run).

It's important that yout test suite prints "Success" when all tests work, and "Failed" when any of the test failed. You should not have to examine the output of your tests to verify that they all succeeded.

For your 50K LOC application try and write about 100 tests. Once you have the tests running, you can start refactoring and redesigning. Just make sure that after every change all the tests still work. Even "Stupid" tests are useful (eg. make sure that routine that opens files, really opens files and try to see what happens if a file does not exist), as they find "stupid" bugs.

Never ever(!!!) live with broken tests.

See Junit.org for example of a testing framework in Java and read up on Extreme Programming.

Also the book "The Pragmatic Programmer" has many useful hints. Check out their web site.

It is a good day to code.

testing for what? (5.00 / 5) (#31)
by codemonkey_uk on Fri Jul 26, 2002 at 09:10:45 AM EST

Okay, that's basically good advice, but, and this may sound like a silly question, but what should he test against?  The spec as documented?  Or the existing functionality?  Either way, there is a chance that he won't be testing against the right thing, and may change something that someone is depending on.
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]
Always test existing functionality first! (5.00 / 4) (#61)
by greyrat on Fri Jul 26, 2002 at 11:55:06 AM EST

Then go after the spec. The users are going to expect it to do what its done before. Reviewing the spec will expose scope creep and changes in requirements that will require review by a CCB, or the user community.
~ ~ ~
Did I actually read the article? No. No I didn't.
"Watch out for me nobbystyles, Gromit!"

[ Parent ]
What to test (5.00 / 1) (#71)
by richieb on Fri Jul 26, 2002 at 02:24:33 PM EST

Okay, that's basically good advice, but, and this may sound like a silly question, but what should he test against? The spec as documented?

Certainly write test to compare against the spec (if you have one). You can test against current behavior. Just write a test case, see what the output would be and make that the expected result.

If the program is divided into functional modules, write tests for each module. Let's say you have to do some calculations, and all calculation routines are in one module, then write tests for each calculation.

...and so on.

It is a good day to code.
[ Parent ]

Is the code *really* that bad? (4.36 / 11) (#26)
by codemonkey_uk on Fri Jul 26, 2002 at 08:58:16 AM EST

Or is it just that your fresh out of collage, and you've never worked on a big project before?

Don't be sucked into the ego trap.  These senior guys who have left did not necessarily "flee the monster".  They did not become "senior guys" by chance.  There are probably very good reasons for most of what they have done.  

Now, thats not to say that it could not have been done better.  Sometimes those "very good reasons" is "We had to get the feature in on time - that code is rapid prototype code, which was supposed to be replaced.".

The most important thing to remember when refactoring is that before you can replace any code, you have to understand what it does, and why it does it that way.  You should never rewrite code that you do not understand - and that does double for refactoring code because you don't understand it!

Okay, once you have studied the source code, and convinced yourself that it absolutely must be fixed, here is what your going to do:  

  1. Maintain a working build at all times.  The clients will want features added and bugs fixed at short notice.  
  2. Buy a good book on refactoring (say, for example "AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis")
  3. Learn CVS - or whatever version control system you like that supports branching & merging.  This will help you with objective (1).
  4. Refactor a little at a time, and only where there are gains to be made.
I hope that helps.
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
I've been at this game for only a couple of years (4.66 / 6) (#29)
by S1ack3rThanThou on Fri Jul 26, 2002 at 09:06:17 AM EST

However the opinion of the last guy that left was that its core was an irrepairable mess and should be pulled down and restarted. He was twenty years in the game and left his position of director of R and D.

Unfortunately a lot of the problems came from internal power struggles. The software talks to another device we produce and neither of the two engineers involved would work together. There are grim workarounds to get these two projects to talk to one another when all it really needed was a bit of co-operation.

The guy that originally designed the beast I'm dealing with was apparently quite a primadonna that would never take anyones advice. From what I've heard of the projects history it sounds a bit like it was always doomed to become a project in trouble. Over-ambitious, no co-operation, no communication and marred by people leaving throughout its life.

This is coupled with the problems of the company going through bad growing pains at the moment.

I'm not making excuses, I like the challenge, I just need tips! I'd never even heard of refactoring until today!..

"Remember what the dormouse said, feed your head..."
[ Parent ]

Someday (4.75 / 4) (#57)
by wiredog on Fri Jul 26, 2002 at 11:22:44 AM EST

I'm gonna dig up the code from the project from hell I worked on and write a story about it.

The scary thing is, it's still in use. I heard (but haven't been able to confirm) that the original programmer died. Of old age.

Like you, I had to update it frequently, and fast. Any changes had to be backwards compatible, at least in the data files it generated. It should have been tossed out and rewritten from scratch, but that would have taken too long. So we just kept patching it. Eventually it reached the point where it was, essentially, unpatchable. Everything affected everything else and if you changed one thing you had to test everything.

That's when I found a new job.

Can't sleep. The clowns will get me.
[ Parent ]

What are the chances? (3.00 / 1) (#114)
by rdskutter on Mon Jul 29, 2002 at 08:52:53 AM EST

What are the chances that the code you left is the same code that this poor sod is stuck with now?

If you're a jock, inflict some pain / If you're a nerd then use your brain - DAPHNE AND CELESTE
[ Parent ]

As I said (4.00 / 1) (#115)
by wiredog on Mon Jul 29, 2002 at 09:41:58 AM EST

The scary thing is, it's still in use.

I was there a couple weeks ago, and they don't have a programmer. The company specialized in making parts that are used in timing and frequency generation applications, mostly used in the telco sector. When telco cratered so did the company's sales.

A really scary thing is this company, and its software, were among the best in the industry when I was there. We had automated things that others did by hand and got a better product, faster, at lower cost.

Can't sleep. The clowns will get me.
[ Parent ]

That bad... (4.66 / 6) (#32)
by wiredog on Fri Jul 26, 2002 at 09:12:04 AM EST

My first project was. Sounds like what he's stuck with. Uncommented. Undocumented anywhere. The original programmer long gone. No one ever rewrote it, just added 'features' to it. Bugs needed fixing, and features needed adding, Right Now. All the variables, and functions, were global. Touching one thing affected everything.

It was a tremendous learning experience. I learned why comments are good, and that too many are far preferable to too few. I learned why global data is a Bad Thing.

Can't sleep. The clowns will get me.
[ Parent ]

global data (4.25 / 4) (#33)
by codemonkey_uk on Fri Jul 26, 2002 at 09:16:51 AM EST

Global data does have it's place. ROM.


"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]

Even there... (4.66 / 3) (#54)
by wiredog on Fri Jul 26, 2002 at 11:15:06 AM EST

The program should copy the data from ROM into local variables and pass those to the various functions.

Unless it's volatile data such as a timer, then it should be accessed via a function.

Can't sleep. The clowns will get me.
[ Parent ]

Never assume there was a good reason for anything (4.00 / 6) (#78)
by mingofmongo on Fri Jul 26, 2002 at 03:04:01 PM EST

I'll grant there was a reason for all the evil looking code you see, but not necessarily a good one. It all depends on the people who did the coding. Did they care? Did they write for maintainability or for a deadline? (the diferance is staggering)

Look for code cut-and-pasted throughout the program. If you see much of that, you'll know what you are up against.

Good luck.

"What they don't seem to get is that the key to living the good life is to avoid that brass ring like the fucking plague."
--The Onion
[ Parent ]

Antipatterns (4.16 / 6) (#27)
by FunkMasterK on Fri Jul 26, 2002 at 08:58:53 AM EST

You should really read the book AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis.  It list dozens of different ways projects can "go bad" and ways to refactor them into  more manageable, sane systems.

Think of it as a companion to Design Patterns...just don't get the books too close together or they'll annihiliate themselves.

overwhelming? (4.77 / 9) (#30)
by j1mmy on Fri Jul 26, 2002 at 09:09:40 AM EST

I'm currently the lead developer on a project that encompasses multiple programs (20 and growing) in multiple languages (c,c++,java,php,python) and totals in the hundreds of thousands of lines of code. Furthermore, my development team consists almost entirely of academic types who don't know encapsulation from polymorphism.

It's been over a year since I inherited the entire codebase. My first step was to get everything in CVS. That was crucial for me, at least. The old code repository was a bloated src/ directory on one of our development machines. Some of the dev team still hasn't quite figured out how to do updates (and are constantly committing code with bugs that other people have corrected and committed in the past).

The next step was to standardize our utility libraries. The old library was a home-grown database and filesystem abstraction layer that had an overwhelmingly bloated and completely undocumented API. As much as I didn't want to, I ended up rewriting that almost from scratch, then updating all the other programs accordingly. That took time, but it was definitely worth the effort in the long run.

The rest of the applications have been mostly left alone. Some of the more critical ones have been getting most of my attention over the last year, with new features going in and the myriad of bugfixes.

My biggest (and least fun) push has been documentation. Until I started, there was one word document (all our code is developed and runs in unix environments) that discussed some bits and pieces of the utility libraries and one of the applications. That was it. All of it.

I've since been flooding our codebase with doxygen-style comments (even stuff in SQL and other languages that it doesn't necessarily support) and started some detailed documentation of our data model, APIs, and architectural thing.

My advice to you is to make as few major changes as possible. Whatever needs to really be redone, do it offline, test it thoroughly, and bring it online when it's ready. Then document like a madman. The better described a project is, the easier it is for you and others to maintain.

Portland Patterns Repository (3.75 / 4) (#34)
by Scrymarch on Fri Jul 26, 2002 at 09:37:39 AM EST

As others have mentioned, you might want to test the existing functionality, so at least you know when you're in refactoring hell.

You might also want to read a few other things on that site.  It's heavily XP / agile biased, but a pretty good collection of wisdom.

50k lines of code is overwhelming? (2.50 / 6) (#35)
by porkchop_d_clown on Fri Jul 26, 2002 at 10:00:51 AM EST

Heck, dude, that's not even a big project!

Come back when you break the million line mark.

In anticipation, John licked his own lips.
- A. Lloyd -

Its not the size, it is the quality. (3.00 / 1) (#36)
by S1ack3rThanThou on Fri Jul 26, 2002 at 10:02:41 AM EST

I can guarantee you I could come up with 50kloc that you would find overwhelming.

"Remember what the dormouse said, feed your head..."
[ Parent ]
Right. (4.00 / 3) (#37)
by porkchop_d_clown on Fri Jul 26, 2002 at 10:07:49 AM EST

Sorry, I made my rep on projects like this. One time, the project had over 5 million lines of code. I wasn't solo on the whole project, but *my piece* was larger than 50k and included such gems as a single function that was 2k lines and had 37! gotos. Gotos into and out of loop structures.

When I was finished, the result was a third smaller (it would have been 50% but I added lots of comments) and 75x faster.

In anticipation, John licked his own lips.
- A. Lloyd -

[ Parent ]
Did you JUST code on that... (4.00 / 2) (#40)
by S1ack3rThanThou on Fri Jul 26, 2002 at 10:10:51 AM EST

Or have to manage as well? I have to manage and support as well, so I rarely get more than a half hour in one go to concentrate. It bites.

"Remember what the dormouse said, feed your head..."
[ Parent ]
Manage? Support? (3.50 / 4) (#43)
by porkchop_d_clown on Fri Jul 26, 2002 at 10:20:26 AM EST

You have direct reports? Then you're hardly a "lone junior engineer" are you.

Support: Well, yeah - who do you think supported the existing system while I designed and wrote the new one? You think our customers were going to let the existing bugs go unfixed for a year while I dorked around with "partially ordered heaps"?

In anticipation, John licked his own lips.
- A. Lloyd -

[ Parent ]
Manage yes... (3.66 / 3) (#44)
by S1ack3rThanThou on Fri Jul 26, 2002 at 10:24:10 AM EST

Support, upgrade, document, plan. Does that not count as manage? I look after the entire project, therefore I'd say that there was a certain amount of management in it.

By lone junior, I mean I have no-one I can ask to help or assist. There is no "senior" to ask or guide.

"Remember what the dormouse said, feed your head..."
[ Parent ]

No. That's not management. (2.33 / 3) (#46)
by porkchop_d_clown on Fri Jul 26, 2002 at 10:25:21 AM EST

"Management" means subordinates. The rest of it is just engineering.

In anticipation, John licked his own lips.
- A. Lloyd -

[ Parent ]
um... (4.00 / 2) (#56)
by pb on Fri Jul 26, 2002 at 11:18:31 AM EST

I guess he's talking about "Project Management"; since he's coming at this from a "Software Engineering" perspective, don't be surprised if the terms are somewhat different from what real people use.

Yes, most of us would think that management is what managers do, which has to do with managing people, but that isn't the only meaning of the word, just the most commonly used one...
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]

"Project Management" isn't management ei (5.00 / 3) (#73)
by porkchop_d_clown on Fri Jul 26, 2002 at 02:39:01 PM EST

If you're talking about PERT charts and so on, why would a single engineer waste time on such things (management could require them, I suppose) they are for helping coordinate a team, not planning out your work day. As for documentation, design and planning - hey, it's all part of being a real engineer and not just a student with an assignment.

In anticipation, John licked his own lips.
- A. Lloyd -

[ Parent ]
Oh, and the new version (3.00 / 3) (#45)
by porkchop_d_clown on Fri Jul 26, 2002 at 10:24:14 AM EST

Was a drop-in replacement for the old component. However - I will admit that the original designers left me a clean break between components, if they hadn't things would have been worse.

In anticipation, John licked his own lips.
- A. Lloyd -

[ Parent ]
holy moly! (4.00 / 1) (#90)
by martingale on Fri Jul 26, 2002 at 09:00:46 PM EST

37! gotos? That's 1.376375e43 of them. I'm not worthy! *kneels head on ground*

[ Parent ]
Oy. (none / 0) (#117)
by porkchop_d_clown on Mon Jul 29, 2002 at 03:28:03 PM EST

The worst part is they were all labelled with comments like "This needs to be changed before we ship". The code had gone on the market two years before.

In anticipation, John licked his own lips.
- A. Lloyd -

[ Parent ]
I can beat that (4.00 / 2) (#41)
by codemonkey_uk on Fri Jul 26, 2002 at 10:11:53 AM EST

How about less than 2048 bytes?
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]
In any case (4.50 / 4) (#42)
by porkchop_d_clown on Fri Jul 26, 2002 at 10:18:09 AM EST

You've already gotten all the advice you need. Here's my version of it:

  1. Review the code, document everything as you figure out what it does. Highlight what seems to be the bonehead problems, but don't touch them (yet)
  2. Source control. The ass you save may be your own.
  3. Test! Code-and-test, regression test, feature test. Identify what's broken and don't break anything else.
  4. Once you've done all that, if you think you can do it, then design a new system while continuing to maintain the old one. If you can, evolve the old system into the new one with incremental clean ups. If you can't make sure that you can swap the new one in without the users noticing.
  5. If you don't think you can manage a redesign, then do your best to incrementally clean up the existing system and resign yourself to being "indispensible".
  6. People here are using buzzwords like "refactoring". Buzzwords are handy but they don't substitute for sense or intelligence. If a techinique or process makes your life easier, use it. If it doesn't, don't sacrifice yourself on the altar of computer science.

In anticipation, John licked his own lips.
- A. Lloyd -

[ Parent ]
quit (3.66 / 6) (#39)
by turmeric on Fri Jul 26, 2002 at 10:09:21 AM EST

before they start blaming YOU for it screwing up. if you try to explain what happened they will label you are a whiny incompetent loser.

Versioning (4.42 / 7) (#48)
by n8f8 on Fri Jul 26, 2002 at 10:38:36 AM EST

This is why they invented versioning. Fork the code and start a new branch that is more modular. Maintain the old version and apply updates to both. In the short term things will reall suck, but in the end you'll wind up with a new version that is modular and more maintainable.

A recent article at SlashDot has a link to an interresting document about MS software development. In particular, pay attention to how they reorganized their code into many dlls to make the code more maintainable and to minimise bug cross-project complications (Implemented halfway through Win2K development.).

What kind of Software Configuration Managment (SCM) methods/tools are you using? I'm not saying you have to go overboard with red tape, but it sounds like you need to standardize how you do things and maybe organize your code a little.

Sig: (This will get posted after your comments)

Asking for advice (1.71 / 7) (#50)
by porkchop_d_clown on Fri Jul 26, 2002 at 11:05:39 AM EST

And then downrating people you disagree with is fairly moronic, wouldn't you think?

In anticipation, John licked his own lips.
- A. Lloyd -

er, yeah... (1.00 / 1) (#111)
by werner on Sun Jul 28, 2002 at 02:31:32 PM EST

...it sounds pretty stupid.

[ Parent ]
From my POV (3.00 / 2) (#62)
by MKalus on Fri Jul 26, 2002 at 12:03:56 PM EST

In a smaller enviorment I came into a similar situation as a PM.

The right thing to do would be (I guess) find the person who own's the product / project (let's hope it's not you).

Detail to them the implication and try to build a Programmerteam and then start to build an improved product besides the one you have to support right now.

It really is a no win situation, it seems to take extensive rewrites in order to be usable in the future but to do so you need time and people and the only one who can get you that is the owner of the app.
-- Michael

I own the project. Damn. [n/t] (none / 0) (#63)
by S1ack3rThanThou on Fri Jul 26, 2002 at 12:27:29 PM EST

"Remember what the dormouse said, feed your head..."
[ Parent ]
Been there, done that.. (4.55 / 9) (#67)
by Caton on Fri Jul 26, 2002 at 01:52:45 PM EST

Here's what's written on the t-shirt:

Your real problem is getting the funding to do the job.

That's what I learned from my first Project from Hell. After that, I started developing a method to get the funding. I ended up with this.

Step 0:

Start looking for another job. You might need it when you reach step 7.

Step 1:

Go through the code. Comment everything. Document everything. 50K lines -- shouldn't be long.
During this phase you will find badly written code, obvious bugs, stupid algorithm, ugly workarounds... whatever. Don't touch anything! You don't know what you are doing yet. And you shouldn't be doing it: remember, your target is to get the funding.

Disclaimer: I went through those exact steps a dozen times, got the required funding immediately in one case, after the initial modification nine times, and resigned immediately when funding was refused twice. I know it worked for me. I don't guarantee it'll work for anybody else. Step 2:

Using the documentation written in Phase 1, document the structure of the application, the global design - basically, write specifications that fit what you have.

Step 3:

By now you understand what the application does. Find out what the application was supposed to do: get the original specs. Design an application that make sense.

Step 4:

Compare the outputs of steps 2 and 3. Look at what's not been done in the way you think it should have been done. Each time there's something different, study what's been actually implemented. Keep in mind that you might have overlooked something: the implementation may well be right. If you can prove it's wrong, document that. Change your design as required.

Step 5:

Go back to step 1. Now you know a lot more about the application. Take another look at those stupid lines of codes that ought to be changed immediately. Are they still bad? Make a list of what should be changed, in what order, and why.

Step 6.

Now assume that your changes (from step 5) have been implemented. How would you go from there to the application you dream of, the one you designed in steps 3 and 4? This is a major overhaul, so you have to explain what are the benefits for the company.

Step 7:

Write a proposal to your management, complete with planning and workload. State the faults of the applications, as well as the work-arounds from step 5. State the benefits of changing it to your "dream" application.

Three possible outcomes:

  1. Your management disagrees with everything. You won't even be allowed to change the obvious flaws. See step 0
  2. You management agrees with the list of changes, not to the major overhaul. Implement the changes. Slow down on step 0, but keep it going. When the changes are implemented, you need to go back to your management. If they disagree again with the major overhaul, see step 0. If they agree, see below.
  3. They agree with the whole proposal. Suddenly you can get the resources you need. Freeze step 0 till the end of the project. Problem solved.

As long as there's hope...
Sorry... (5.00 / 3) (#68)
by Caton on Fri Jul 26, 2002 at 01:56:20 PM EST

Looks like I did something wrong when pasting the text to k5... the disclaimer should be before step 0, not before step 2.

As long as there's hope...
[ Parent ]
Oh my, my; oh hell, yes! (5.00 / 4) (#89)
by Nicht Ausreichend on Fri Jul 26, 2002 at 08:56:43 PM EST

That's the right way.

Unfortunately, back when I was in that situation, my (unpaid) nights and weekends were totally eaten up with the short-term patches it took to keep the thing limping along so that I could keep getting paid.

I guess I did use this process, though, because I ended up changing jobs.

Best of luck to anyone who's in this kind of bind right now; I know from personal experience how tough it can be.

[ Parent ]

Sounds VERY much like my current situation! [n/t] (none / 0) (#100)
by S1ack3rThanThou on Sat Jul 27, 2002 at 03:58:04 AM EST

"Remember what the dormouse said, feed your head..."
[ Parent ]
sounds like the 1-800 telephone system (3.50 / 4) (#70)
by alphabit on Fri Jul 26, 2002 at 02:09:44 PM EST

I once worked on a 1-800 telephone system that had more code than we could understand. It sucked. The solution was to get another job.

'It is better to light one candle than to curse the darkness.' -unknown
The first thing you should do... (3.75 / 4) (#72)
by Farq Q. Fenderson on Fri Jul 26, 2002 at 02:30:35 PM EST

...is go through all of the source code and write up a tree, or a flowchart or whatever you prefer, (I actually do best with trees,) describing how the program works. Until you know how each portion works, you can't hope to maintain the code.

Just start with the the most obvious systems in the program and go until everything is in one of those systems. You'll probably have to narrow down, describing sub-systems as well.

In the event that there are no definite systems in the code, go the other way around. Look at the program's functionality, and document how that has been implemented. This is harder to do, of course, and more time consuming.

Having done this, it should aid any attempt you make to maintain the code, no matter how you go about doing that, since you've now got a whole lot more information about it.


farq will not be coming back

Ummm.... don't forget the CD (3.50 / 2) (#77)
by MickLinux on Fri Jul 26, 2002 at 03:00:20 PM EST

Don't forget to write a CD with all the old code, exactly as it is.  Actually, since CD-Rs lose a bit here and there every year (1/100k), I'd write a 2-3 copies of the CD with the same data 5-10 times, and  then store them in different places.

That way -- JUST IN CASE someone wants the old version -- you will have it there.  Especially if that someone is you.

I make a call to grace, for the alternative is more broken than you can imagine.

Similar situation (3.66 / 3) (#80)
by vadim on Fri Jul 26, 2002 at 03:57:27 PM EST

Now I'm trying to make a 55000 line VB program behave properly. It's used by the company to manage what it sells.

Right now I'm trying a quite complete redesign. A lot of code is badly written, there's a lot of duplicated code (I saw the same function with exactly the same code pasted in 20 forms!) and most variables are strings.

An additional problem is that I don't have any "formal" CS education, and I've never worked with anything so large before, so I'm quite glad there is no fixed deadline, although of course the sooner I fix it, the better. I have almost complete control over it, which makes the job somewhat easier.

What I'm doing now is:

  • Get some decent versioning system. I tried SourceSafe but didn't like it at all. We had to set up a VPN and it works really slowly with an ADSL connection. I'm trying to move to CVS now.

  • Find code that could be implemented as a generic component/library and reused instead of having slightly different versions of it everywhere

  • Clean up the coding style, add comments

  • Switch from ODBC to ADO. The other people who sometimes write small separate programs that could be integrated already use it, and I generally like it better than the ODBC mess we have.

  • Hopefully, remove all the non-standard GUI behavior. It has been written to emulate a DOS program, and doesn't look like a normal Windows program.

  • Add some code to make debugging easier

  • Try to move all logic to a library. Then the main program would just be an interface to it, and it'd make it possible to write tests for it.

    Don't take my opinion very seriously, but I think that a redesign is needed sometimes. I'm trying to do it by migrating parts of the application to my new design while keeping the old stuff untouched. To keep compatibility some functions are replaced with one line calls to a replacement.

    A versioning system is definitely a must. It'll save you hours of wondering why something that worked yesterday doesn't work today, and will also be very useful to see how was the program before your changes so you can revise them in the future. I showed some of my ideas to people who work there and they seem to like them much better :-)
    <@chani> I *cannot* remember names. but I did memorize 214 digits of pi once.

  • Sounds like NIH (3.25 / 4) (#83)
    by svanegmond on Fri Jul 26, 2002 at 05:25:15 PM EST

    NIH = Not Invented Here.

    You didn't write the code, so it all sucks, it's crappy, it's got no design, and it ran over your dog last week.

    Resist the urge to throw it all out and start over. Even experienced developers make that mistake, though hopefully they only make it once.

    I suggest you start learning about tags, and branch tags, in CVS. When you make a release, create a branch for it so that you can continue hacking. If someone with that version comes back and asks for one change, revert to the branch, make the change, commit to the branch, and ship them a new version.

    I also suggest that you read up on refactoring, perhaps buy the book "Refactoring: Changing the design of existing code", and try to understand unit testing. Write unit tests for anything new, or any code that you're going to restructure.

    Buy and read "Large Scale C++ Software Design".

    Install a bug database, and make your users start using it. If they e-mail you a bug report or feature request, return the mail, and firmly tell them to post it in the bug tracking system. Work with whatever management there is to prioritize things.

    Lastly, I suggest you change your attitude. You're all fringerpointing and blame, and you need to get into a non-victim mindset so that you can work rationally on the system and do decent work. You are finding out what software development is really like. The calm, easy project that begins with requirements, then moving onto design, then construction, then release, is a fraud and a lie perpetrated by software engineering academics. There are some jobs out there where such a software process happens: it's usually at NASA, the military, or other safety-critical systems. But for the rest of the world, shifting requirements are a fact of life that you need to learn how to adapt to.

    -- Steve van Egmond http://svan.ca/

    what, (2.50 / 2) (#84)
    by aphrael on Fri Jul 26, 2002 at 05:40:42 PM EST

    do you work at TiVo?

    Refactoring (3.75 / 4) (#85)
    by smallstepforman on Fri Jul 26, 2002 at 06:40:18 PM EST

    Refactoring, by Martin Fowler.  The greatist thing about this book is that its like Algebra - it keeps on beating example after example onto you, until just like Algebra, the final message 'just kicks in', and causes you 'to see the light', so to speak.  

    Get yourself a copy of this book, and your life as a maintainance programmer will be much much much more sweeter.

    Ideas (4.87 / 16) (#87)
    by epepke on Fri Jul 26, 2002 at 08:27:50 PM EST

    OK. I'm a senior software developer/engineer/programmer/artist/whatever, and my last job was senior client/server architect in-house with about a thousand users (well, 6000 if you count the time-clock users), so it isn't too dissimilar. When I came on board, there was some crap code I rewrote. There was a lot that I didn't. You have to know the difference.

    Young grassahoppa, you must learn The Tao of Programming.

    In order to fix some of the large and nasty problems with the software some large parts have to be redesigned and/or pulled out. How do I do this when I must maintain a degree of stability in the project?

    The following may seem insultingly simple, but it is not; even many experienced programmers do not understand it. Your job is not to engineer software. Your job is to facilitate the jobs of the users. Sometimes this means engineering software. Other times it means SCPing a text file once a week. Other times it means doing nothing. It could be worse. You could be working for a shrink-wrapped software company, in which case you would regularly be required to write ugly software for marketing reasons. At least, with a user base that has to take what you give them, you have the freedom to write good code. But that is not your job.

    You will at times feel a strong disgust at the code you work with. You will see atonishingly bad programming. You will feel an overwhelming impulse to rewrite large chunks. Resist this temptation. When you are no longer filled with disgust, when you can look at the code with a calm and accepting eye, then and only then should you even consider rewriting it.

    Regardless of what you might find wrong with the code, there is one thing that is right. It works. Its value is that it works and has worked. Find a way to respect that value before you do anything.

    Also, respect your users. Listen very carefully to what they say, but don't do what they say. You must make a synthesis, finding out what they need, which is often very different from what they think they need. If they say, for example, "This screen takes too long. I have to go through fifty of these things a day. A couple of extra seconds means a lot," do not simply make the screen faster. Find out what they need to do and figure out why they need to go through fifty screens to do it.

    The stability is not a degree. The stability is what is important. You must maintain stability, while also maintaining a degree of the design of the code.

    Let me tell you a parable. When I was training my replacement for my last job, I gave him our Book of Knowlege, a 250-page document I had been accumulating for about a year. He came upon a section I had written about how to produce spreadsheets using the SYLK format. He came excitedly to me to ask me if we had used any of the Perl modules. I nodded and said that, yes, we had, and it had used OLE. And then Ram had to produce a spreadsheet and spent three days trying to get the old module to work even given changes in OLE. And so, when I needed to produce a complex report and didn't have three days, I just wrote it out in SYLK. It may not be pretty or modern or even good, but it got the job done. He then asked about modules that didn't use OLE. I said, fine, use what you like. But make sure that some poor sucker three years from now isn't going to have an experience like Ram did.

    I've already tried to make a large change twice and had to can it because it would have made the software too unstable to be able to do the constant small bug fixes and feature releases.

    These are lessons, not problems. Many people have suggested refactoring as a way of making large changes to code. Others have suggested that you understand the code completely. Both are right. However, refactoring only tells you how to do it, not whether or why.

    Any change requires testing (sometimes known ironically as Quality Assurance, ironically, because it is more about assuring rather than ensuring quality). Respect your testers. If you don't have any, go out there and get you some. Especially respect the testers who know nothing about the system. In any group of users, there will be some who will be willing to help.

    Any major change requires an initial, limited release to a limited set of users and an overlap period where the old system is still entirely in place for backup. You should go out there and watch them use the new system.

    I was always taught how to plan a project from scratch, how to prevent it becoming out of control and how to spot the signs of a project that is close to being a disaster. Unfortunately no-one ever explained how to rescue such a disaster.

    So, you have been taught all the easy and fun stuff. This is one of the problems with education. In the old apprenticeship system, there was a lot of "wax on, wax off" before the student was taught the theory. Now, you get the theory straight away, but the thing about theory is that it's the same in practice, but only in theory.

    I assume that you already know all about the nature of programs, how some small changes require big rewrites, how some large changes require small updates, how cruft accumulates and increases the difficulty and cost of bug fixes. What you haven't learned is that, sometimes, you just have to eat it.

    The truth may be out there, but lies are inside your head.--Terry Pratchett

    <A HREF="http://www.terrible.cx/tao/" (none / 0) (#102)
    by Caton on Sat Jul 27, 2002 at 07:57:20 AM EST

    This is great stuff! Thanks.

    As long as there's hope...
    [ Parent ]
    I'll emphasize unit tests... (4.88 / 9) (#91)
    by mahlen on Fri Jul 26, 2002 at 10:00:28 PM EST

    Much of what i'll say here has been said below, but here's the order of execution that I'd use. I've included relevant buzz words so that you can Google for them effectively.

    1. Build a solid testing framework. If you aren't testing the various features of your system, you'll have no confidence that any change you make is effective. This is true of any system, but especially true of a poorly understood system. Unit tests (of individual modules or blocks of code), frequent automated builds and test suites, a speedy and effective QA department; all of these increase your confidence that the system is still working while you fix the internals. Any amount of this better than none, and updating and adding to the suite of tests you have should be an ongoing project (even if your bosses don't know about it).

    2. Refactoring. As many people have mentioned, this is the best way to create the structure you need to the code. Take what works now, then move code/functionality/methods into a slightly more comprehensible arrangement, and then prove that it still works (see #1). Repeat until code is understandable by you, is flexible, layered, and so on. Write down somewhere else (perhaps in a Wiki on your intranet) what you've now got. And so on... As mentioned elsewhere, Fowler's book is the original text on the subject

    3. Figure out where the code needs to go. Since you don't provide many details of the system itself, some of the following will not apply, but ask the other people in the company what's likely to need to change (implementation language, DB schema, DB engine, target devices, etc...). Which ones are not important to the customers, and thus can be left as they are. Do refactoring with that in mind.

    Now some non-code related tasks:

    1. Ask for help. Let managers and your peers know that you're in over your head, and see if any resources can be diverted your way. QA team members, engineers, contractors, IT personel; all can assist you at various points along this journey, and your management (which presumably wants you to succeed, and influences the availability of these resources) should be looking for opportuinites to make you more effective. But don't take help just to get warm bodies; non-stellar contractors (for example) will only be a hindrance, and will expend budget and your political capital.

    2. Let management know that you've had a ton of bricks dropped on you, and that steps 1-3 above will need to be happening on an ongoing basis. See if they can forstall feature requests. Getting from chaos to order takes time and energy.

    3. It doesn't really sound like you'll have much time to read, but I'll throw in a couple things:
    a. It sounds like you have a Big Ball of Mud (http://www.laputan.org/mud/).
    b. The Pragmatic Programmer: From Journeyman to Master (http://www.amazon.com/exec/obidos/ASIN/020161622X/mahlenorg-20). It sounds like you are primed to heed the lessons in this book.
    c. The WikiWikiWeb (http://www.c2.com/cgi/wiki?WelcomeVisitors). Many old coding masters dwell here. But be warned, the many, many pages here can suck up your time Hoovermatically.

    4. Good luck. Even from this short description, I feel for you. Do write back with updates on how things progress!


    The men sat sipping their tea in silence.  After a while the klutz said, "Life
    is like a bowl of sour cream."  "Like a bowl of sour cream?" asked the other.
    "Why?"  "How should I know?  What am I, a philosopher?"

    Tools. (3.00 / 1) (#110)
    by Phillip Asheo on Sun Jul 28, 2002 at 11:17:26 AM EST

    Get hold of "sniff++" and or software Emancipations "Discover". This will at least enable you to see the structure of the mess you have inherited.

    "Never say what you can grunt. Never grunt what you can wink. Never wink what you can nod, never nod what you can shrug, and don't shrug when it ain't necessary"
    -Earl Long

    Are you the only one who can do your job? (2.00 / 1) (#116)
    by jforan on Mon Jul 29, 2002 at 01:48:26 PM EST

    Time for a raise.

    Tell them that this thing needs your over time (as much as you are willing to spare at $100/hr).

    Do the best you can to modularize and replace one module at a time.  Or perhaps it is time to move to version 2.  Put on a new UI and a few features, and get the company to increase their charges.


    I hops to be barley workin'.

    :-), already done the version 2 thing! [n/t] (none / 0) (#119)
    by S1ack3rThanThou on Tue Jul 30, 2002 at 04:54:43 AM EST

    "Remember what the dormouse said, feed your head..."
    [ Parent ]
    One trick I sometimes use.. (3.00 / 1) (#120)
    by tonyenkiducx on Tue Jul 30, 2002 at 06:48:39 AM EST

    ..is to convince whoever manages the project that to make essential changes/bug fixes, you will have to also do X. X being an unrelated change that will improve the code generally(Mod something off, Re-write most of it, etc..). This has the added advantages of working no matter what the manager/client says. If they say yes you get extra time/resources and you can work your changes. If they say no you can do the changes anyway(In your spare time), and then blame any subsequent problems on you not making the change, that you actually have made. You then also get extra time to make those changes, which you can use to tidy up/repair/bugfix the code you originally put in.

    Does that make sense? It realy does work :P

    I see a planet where love is foremost, where war is none existant. A planet of peace, and a planet of understanding. I see a planet called utopia. And I see us invading that planet, because they'd never expect it
    One Tiny Suggestion: tags/etags/ctags (5.00 / 2) (#121)
    by Lagged2Death on Tue Jul 30, 2002 at 02:06:34 PM EST

    You've had lots of good advice here, but there's one tiny thing I'd like to mention.

    Learn to use tags, etags, a source code browser, or some equivalent, if you do not use something like that already.

    I've found these types of tools to be indispensable when working on someone else's code. When I'm reading Funky_Call() and see a call to ThatBooty_ShakeIt(), I can find out what ThatBooty_ShakeIt() does with a single keystroke.

    This is especially helpful when the previous maintainers didn't use a naming scheme, or used naming schemes that are unclear or counterintuitive - maybe instead of ThatBooty_ShakeIt() they called that function DoBootyStuff() or something equally unhelpful. They may even have done something like written two calls, My_FunkyCall() and MyFunky_Call(), something that can become very confusing when using a human-steered tool like grep, but which is quickly made obvious with a source browser.

    I think the immediacy of a source-browsing system helps me learn my way around the system far better than grep type tools. A source-browsing lookup is so fast, it becomes second nature, the way the cursor movement keys do. But grep, especially if you actually use the regular expressions, is always a distraction, and usually spews as much noise as it does information.

    I'm always surprised that more people don't use these tools, so that's why I mention it.

    Starfish automatically creates colorful abstract art for your PC desktop!

    Good start (4.00 / 1) (#122)
    by twh270 on Tue Jul 30, 2002 at 02:18:32 PM EST

    You've made a good start: you haven't messed things up. In an application that requires 24/7 reliability, this is probably the best thing you can do.

    Of course, it's not the only thing you can do. But anything you change should keep reliability in mind. In your case, this means:

    • Make only small changes.
    • Change only what you understand.
    This isn't exciting. But small changes made over a period of time will get you much closer to where you want to be than making a few large changes.

    The Blame Game (none / 0) (#124)
    by thogard on Sun Aug 04, 2002 at 10:06:39 PM EST

    You may have seen this going on before the others left.  People spent more time in CYA mode than working on the project.  This happens when the round peg isn't going in the square hole.  99% of this is a direct result of miscommunication between departments (like managment and the coders or markerting and engr).  Watch out for this because it may repeat.  One odd thing about it is most orginzations know how to paln for assigning blame but most have no system in place to place blame and many problems can be solved by just saying "our group screwed up on that".  Once the other groups stop figting over whos going to get blamed, then they can get back to tring to figure out how to solve the problem.  If the project is at the point where everyone is placing blame for everything and making no progress, then the project is dead and can't be fixed.

    Have you considered replacing it? (none / 0) (#128)
    by fathomghost on Sun Aug 11, 2002 at 11:18:21 PM EST

    I sympathize with you on this one. Unfortunately, repairing something like that might only result in adding more cruft. Sometimes you need to scrap it and start over.

    Is the amount of work you'll end up doing trying to maintain it going to save your employer more in the short term? Is it possible to build a system that does exactly what the old system does as, say, a J2EE webapp using something like a JBoss/Webwork/MySQL combination? You'd have the benefits of security, web accessibility, container-managed persistance, modular design for future enhancements, and best of all--you'd pay nothing for server license costs. If you could provide all the features of the current software, you might be able to migrate the database to a J2EE middleware client and save the day.

    Overhauling legacy systems is a hard job. I've done my share of it. Consider the future, though. Streamlining the data structure and switching to a modular design pattern could allow for more precise data mining, data integrity, and more reliability. You'd be able to swap out bits and pieces of the business logic as needed. You could completely forego writing time intensive and highly human-error-prone SQL code and spend more time working on fine tuning the business logic and user interface to better serve the customers. The application could make use of new dynamic clustering technologies to gain better scalability and performance.

    Of course you're going to have to mine the current database. That's the hard part, particularly if the relational models lack cohesive patterns. Trying to make sense of a decade of illogical database entries can cripple the best clutch of programmers.

    I recommend you read up on some common software configuration patterns/antipatterns and see if any of them apply to your situation. If nothing else, it would take your mind off of your worries for a few hours.



    "May the source be with you." --The JBoss Group
    Saving The Project From Hell | 127 comments (121 topical, 6 editorial, 0 hidden)
    Display: Sort:


    All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
    See our legalese page for copyright policies. Please also read our Privacy Policy.
    Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
    Need some help? Email help@kuro5hin.org.
    My heart's the long stairs.

    Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!