Skip to main content

Post-project questions

8 replies [Last post]
Joined: 2003-06-11

Hello all,

I'm sure you all know the feeling. You've joined a team working on a large-scale J2EE system. The foundations are shaky, the technologies outdated. Nobody knows what an interface is, and even less JUnit. You've spent several months trying to fix things up and yet end up convinced that it would be easier to simply rewrite the whole thing. By yourself.

How do you react to this feeling? Do you stick to the project and try no matter what to fix it? Do you simply leave the project and try to join another one where it would be possible to properly apply your knowledge, to actually make a difference? Do you rewrite the whole thing and try to sell it for a vast amount of money? ;)

I'd really like to know you guys' opinion. Thanks a bunch.

Message was edited by: gbilodeau

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-06-11

Well thanks for all your (sometimes humbling!) replies. It made me realize that an accomplished designer/programmer must not only be proficient in writing new systems, but also in understanding the state of an existing one and appropriately refactoring it to improve its quality and keep it maintainable.

Working on legacy systems is surely way more common than working on a new one, which should be considered, I suppose, a priviledge.


Joined: 2003-12-02

Don't rewrite any piece of code that's not actually facing a bug report at that moment.
Any rewrite will have a high chance of introducing its own bugs, making things only worse.

MAYBE try to create a feature freeze for a few months and use that time to find and handle the worst parts and rewrite those while the rest of the system remains stationary, and TEST TEST TEST everything exhaustively.
Unit testing isn't enough here, do full regression tests all the time to make sure you're not having an effect elsewhere in the system (if you do, assume your new code is at fault unless you can prove beyond doubt that the code affected is a workaround or hack for a bug in the old code.

Joined: 2003-08-22

Yes. I know the feeling. It is the feeling every software developer has in every project (of any scale) everywhere.

It is also a myth. No you cannot rewrite it yourself (don't believe me? See Netscape story).

Joined: 2003-06-06

From a purely technical standpoint, check out Michael Feathers' book,
[i]Working Effectively with Legacy Code ([/i]. Those sorts of techniques can help a lot in creating some grip on the existing system. Then, once you have some grip on parts of the system, you can e.g., selectively reimplement them. Being able to thereby [b]show[/b] improvement usually goes a lot farther than just talking about it.

Obviously, you have to judge your ability to survive within the group that you're in and whether or not e.g., leading by example will help enough to keep you from going postal. :-( :-)

Joined: 2004-11-17

The answer is simple - why did you join in the first place? If you know that this project didn't start yesterday, that it has a few dozens developers, haven't you been able to put 2 and 2 together? I think that you have exaggerated a bit about not knowing what an interface is, but you have to make the choice yourself (and not [b]after[/b] joining the project): are you willing to work on existing codebase with 40 other developers or not.

If the answer is yes, then you will [b]always[/b] be fixing bugs in ugly code, be faced with slower processes of adapting new technologies etc.

There are three types of programmers that come to such systems:
1. In the first year you think that you can rewrite the whole thing by yourself. The answer is you can not.
2. In the second year you think that no new feature can be added to the system. The answer is it can be.
3. After that you see the whole picture and start realizing that every bug you fix can create two new bugs, and every new feature will have to play nicely with everything else. The productivity will not be what you would expect in the first year, but the management knows that.

And one more thing - that system you are working on had started with new technologies and solid foundations. That was five years ago (back then no IDE had provided good support for JUnit if you are still wondering about that). The same will happen to the new rewrite (that you will never finish since you will be quickly overwhelmed by a wealth of low-level dirty code that you will have to write).

You will be able to make a difference on new modules that are added to the system if you have a good enough grasp to see the above-mentioned points. It takes time for others to see your value (which will [b]not[/b] gain much when you tell others that their code sucks and everything needs to be rewritten).

Message was edited by: kirillcool

Joined: 2003-12-02

In 2000, 2001, maybe even 2002 I'd have said leave the project and find one where some satisfaction can be had.
In the current climate I'm saying you should be happy to have a job and tough it out.
Maybe try to educate the others on the project to become better programmers and try to steer the project away from eventual collapse, but don't get yourself fired or leave because you won't likely find another job any time soon.

Joined: 2003-06-12

> In the current climate I'm saying you should be happy
> to have a job and tough it out.
Amen to that.

There's a silver lining to the tightening job market. It forces us to get humble and figure out how to make the best of bad situations. We're having to clean up after our own messes instead of just moving on to greener pastures.

Why is that current J2EE project so crappy? Was it [i]really[/i] all managements fault? Did we really do our jobs well, or did we cut corners or overcomplicate things to try out the latest and greatest new technologies?

There's always a combination of factors that cause failure, and one of those factors (usually subliminal) is that you have an easy escape hatch.


Joined: 2003-06-12

> You've spent several months trying to fix
> things up and yet end up convinced that it would be
> easier to simply rewrite the whole thing. By
> yourself.

I have a feeling that most of the alternative frameworks (Spring, Hibernate, etc.) were spawned by these feelings.
The pre-EJB3 stack was just too hard to work with... probably due to a rush to market and trying to fit a square peg (CORBA) into a round hole (Entity Beans).

My own response is evolutionary. First, break the application into subsystems. Many J2EE applications were written with a monolithic mindset, and you can probably break out chunks of functionality.

Once a chunk is broken out, tackle cleaning up the chunk. For example, we broke a chunk out of one of our J2EE applications and then completely rewrote the chunk's web tier.

By rewriting the web tier of a subsystem, we were able to concretely demonstrate the advantages of simplifying the code. We're currently leveraging this credibility to tackle more ambitious rewrites.

There's the key. You have to gain credibility before attempting to "rewrite the whole thing". Why should your business owners trust you to do a better job "this time"? You have to prove to them that they aren't just throwing good money after bad.