Fog Creek Software
Discussion Board

Non OOP Java Experiences

I am a little scared. The company I work for is mostly a COBOL mainframe shop. Over the years they developed some pretty horrible VB6 client server application. The object modeling is horrible being that the VB devs were converted COBOL progs that are only capable think in structured programming terms. All of the code is designed poorly and encapsulization and good programming techniques are ignored all over the place (no option explicit, many variants, many many undeclared variables, huge arrays of user defined types as properties of classes that are never set to nothing and are globals, business and database code sometimes right in the forms, other times in a class, global collections that can hold 5 different types of classes at once instead of using custom collections, etc etc etc)

I have inherited this mess while these Senior Programmes are writing new versions of the applications in J2EE Intranet. I have a feeling that the code is going to be just as bad with little or no correct OOP techniques used. One day I will probably have to inherit this as well.

My question is: Has anyone else had experience with developers writing bad Java code that does not correctly use simple OOP techniques????? (considering evertyhing in Java is an Object)

Thursday, June 26, 2003

Read Martin Fowler's "Refactoring". It has advice on how change code to give it more of an OOP flavor.

There are also several design patterns that would help you deal in an OOP manner with an underlying layer not made of objects.

Joe Grossberg
Thursday, June 26, 2003

My question is: Has anyone else had experience with developers writing bad Java code that does not correctly use simple OOP techniques????? (considering evertyhing in Java is an Object)

Yes, it's called real world code. 

Tom Vu
Thursday, June 26, 2003

That depends, viewed naively the same thing could be said of lots of the code base I currently deal with.
Actually in our case lot's of this is for three reasons:
a) We're compatible with our existing dos code base, this means we do things in a stupid non-oop fashion so the two can co-exist (i.e. some users in DOS some in Windows)
If your VB code can talk to the same database this may be why.
b) We have code that is nearly identical to the DOS version (See joels good software takes ten years article for why) complete with ugly gotos and all the rest. For some of the more complicated routines, which may need to restart on exceptions or jump out to other routines the code is then very similar which helps considerably when debugging.
c) Some of it was written by programmers moving from being non-oop to oop, often in a hurry so the non-oop way was less likely to create obscure bugs while they were learning.

Item a I can't do much about.
Item b We've tried the other way, and when you get a bug of "the dos version is fine, but the windows version is broken" variety it's a complete nightmare
Item c If it ain't broke, why fix it

Some of this is down to inexperience on our part 4-5 years ago. Our new version written in C# doesn't have these problems as we're starting from ground zero with a nice object model first, rather than trying "clone" an existing system. At this point our rewrite and restructure could in theory be done by refactoring, however we're also taking the opportunity of moving programming environment to redesign the way the system works (Moving from 2 tier to a 3 tier model) thus breaking most of Joels rules. However we're not planning on adding huge amounts of functionality at the same time and the move from 2 tier to 3 needs to be done at some point so I don't feel too worried. i.e. we should have the what does the previous version do as a reference model.

However back to your question. You say you have a "feeling", have you actually wondered over and had a look to see quite how bad the mess is? Certainly if I employed a new developer and never let them look at our next version they could have just the feeling you're getting. I don't know just how feasible it is cockup a J2EE application by attempting to write COBOL, perhaps you can go and have a quick peek and report back.

Peter Ibbotson
Thursday, June 26, 2003

I think it's largely a question of the programmers.

Some environments (the Java language, some frameworks I've used) try fairly hard to push you to use their recomended style. I've found that while the correct methods are not obvious, the incorrect ones often are.

That is, Java wants you to program in an OO manner, at it's pretty clear that your code doesn't 'fit' when you look at it in the context of the Java APIs and language features (why do I need this 'catch' here?).

It comes down to, if they are willing to learn, they should notice their own most egregiously bad code. If they're really good, they'll fix it.

It comes down to them, though: good programmers will learn J2EE by going through tutorials and absorbing the style used therein. Bad programmers will memorize 5 to 10 line blocks of code for doing specific tasks and then cut and paste them together.

Of course, even if their good, it's fairly likely that their first OO app will be disgusting (I know mine were, until I reached enlightenment).

Mike Swieton
Thursday, June 26, 2003

I would be scared.

Walter Rumsby
Thursday, June 26, 2003

I wasn't involved in one, but I have witnessed it.

The company took a bunch of COBOL and database programmers, trained them for a couple weeks in Java, and BOOM! put them straight onto a big Java project with EJBs and all the J2EE bells and whistles.

Widespread cut-and-paste instead of inheritance.  The JSPs were a mangled mess of HMTL intertwined with Java code.  They overused EJBs in the design (actually there wasn't much of a "design"), killing the performance to the extent that each of the big expensive servers couldn't handle more than 15 concurrent users.  The project ran for 3 years instead of the planned 2 years.

The one guy who knew what he was doing built a code generator to automate the creation of dozens of classes that followed certain patterns.  Some of them would require manual customization, so guess how they did it?  Direct editing instead of inheriting from the generated class.  Then whenever they had to regenerate one of those classes, they had to go and cut-and-paste the customized pieces back into it.  That guy resigned within the first year.

They created a legacy system in an object-oriented language.

Thursday, June 26, 2003

> no option explicit, many variants, many many undeclared variables

Yes, that's complete junk. If they did that in VB, I shudder to think what they'll do in J2EE.

Thursday, June 26, 2003

I have worked on a project were the original code was written in C (and it wasn't too bad, just huge .c files with huge .h files, lots of side-effects but not too much spaghetti) and later compiled using a C++ compiler. This code was then 'translated' to Java (i.e. just make it compile) and then some parts were "fixed" to use objects instead of public static classes. It has taken around 4 years to gradually migrate the code to proper OO design by a team of knowledgable OO developers and we are still fixing big threading bugs. The big carrot in this project has been maintainability and extensibility. The old code had a well-deserved reputation for being a nightmare to fix (you can't even find the function where stuff is done, never mind figure out its side-effects, despite it being extensively commented) and a nightmare to add new features to.

Good luck. Read the refactoring book. Really! Also, I can't emphasize enough how important regression (black box) test cases are. They have saved our butts time and again...

Friday, June 27, 2003

Yes, it's called real world code. 

Tom Vu
Thursday, June 26, 2003


I guess your code sux too then huh Tom?????????

Bob is that really you?

Friday, June 27, 2003

I think you're right to be concerned.  Unfortunately, since you're a junior guy, your voice doesn't carry much weight.  However, if I were in your shoes I would try talking to my boss about getting these senior developers some training and mentoring on this project.  Something like this:

"Hey, Boss, you got a minute?...  Okay, well I figure at some point I'm going to be transferring to this new J2EE project, and I've been doing a little reading to sort of start preparing, and one of the things that I've noticed mentioned a few times is that since J2EE is so large and complicated, a lot of teams really struggle on their first project to deliver on schedule and on budget.  I'm not saying our team aren't smart or don't know what they're doing, but they don't have much experience with J2EE.  And from what I've read it doesn't matter how smart or experienced you are with other languages or tools, when you transfer to J2EE it's a whole new world.  Anyway, the reason I'm mentioning this is because I think it would make sense to look into giving our developers J2EE training or hiring a couple of J2EE experts who can keep us from going down the wrong path.  What do you think?"

Notice the way this is worded: you're not talking about your expertise or knowledge, you're just referring to "the experts", which bumps up your credibility, and you're not telling your boss what to do, just asking him if it would make sense to "look into" a couple things.

Now, you may have a PHB manager who will tell you that when he wants you to have an opinion he'll give you one :).  But if you have a good manager, he'll be appreciative that you're pointing this out and might look into it.  And you'll be showing some initiative -- which in the right environment will get you recognized in a positive way.

Another tack, if you know the above won't work, is to approach one of the developers on the project with this information and let him deal with it.  Especially if you can talk to someone with whom you have a good relationship and/or a senior developer or team lead.  Because it's going to be his ass that's hanging out if the project goes over-schedule and over-budget, and if he can do something to mitigate that he will.

Finally, worst case, if you can't get any traction, then just let it go.  And when the time comes for you to start maintaining the code, you'll learn a lot about refactoring.  :)


Friday, June 27, 2003

Judging by your post, I think you have your head in the sand. A lot.

Neil Bloh
Sunday, June 29, 2003

*  Recent Topics

*  Fog Creek Home