thiscodesucks

New Milestone

2005-07-29T15:35:00.000-04:00

P.S. We just passed the 700 bug mark.

Everyone have cake!

Javascript considered harmful

2005-07-29T15:29:00.000-04:00

Javascript can be useful, I guess. I mean you've got stuff like AJAX nowadays that use Javascript in ways that don't make the baby jesus cry. This application, on the other hand, abuses Javascript in ways that would make Hannibal Lector say, "Oh, now that's just over-the-top."

See, this application has a relatively normal-looking (I say "normal-looking" because, well... just read the rest of this blog dammit) back-end server component, and about a jillion lines of Javascript that runs in your browser to translate the baloney the server sends to it (this pseudo-XML like stuff I've mentioned before) into something that a browser can actually display. In other words, the server sends HTML, but it's only an HTML wrapper around this goofy Javascript baggage.

By itself, the browser doesn't have a clue what to do with this Javascript data package thingie. I say it's a little bit like XML because it's this sort-of formatted kind-of hierarchical not-exactly structured packet of "data" that represents what the page is supposed to look like. Then the browser downloads like 4MB of Javascript files that include all the logic of how to turn that data into HTML that it then document.write()s to the page.

I should probably also mention that everything on the browser is driven by this Javascript as well. Even the so-called form submissions. So, like, in "normal" HTML, you'd push the button and the browser would build a form data and send it up to the server which would know what to do with it because it's an HTML form, right? Well, here the button just tells the Javascript to reformat all the gunk on your page that you typed in into the same big data doohickey and send it back to the server as another HTML GET. There's code on the server that knows what to do with it and how to relate it to the bit that your browser just downloaded, I think it uses magic or something.

Gosh I really hope you're cringing right about now, because you should be. It sort of sounds like maybe a good idea at first, I mean you're saving bandwidth and creating reusable Javascript components, right? And you're making a nice interactive client that doesn't need to round-trip to redisplay the data, right?

That is, until you realize that there's really nothing that special in how much interactivity you get for such a huge amount of Javascript, and until you realize that this app uses this Javascript to perform most of the basic functionality that your web browser is supposed to be handling, like displaying HTML and clicking links and doing form submission, and until you realize that the Javascript pretty much reimplements a huge amount of server-side code as well, and until you realize that you'd be solving the same problem only without having to maintain a bucket of nasty ugly Javascript if you just used XML and stylesheets. Then you just feel like a tool for thinking anything like that in the first place.

As if it needs mentioning, the Javascript is typically as well designed and implemented as anything else that's been documented here already. Except, well, it's Javascript. Do you know how to debug Javascript? I don't. I know there's a "Javascript debugger" out there somewhere but the idea of having so much Javascript that you need to run a debugger makes me feel all dirty inside. We have a "Javascript specialist" who has figured out all that crap so he can tell when it's the server barfing and sending bogus data and when it's just the fact that these kazillions of lines of Javascript code are just b0rked. Which happens more than a lot, really. Not that that should be surprising.

What's the best part of this plan? Well, the whole concept allegedly behind is to save bandwidth. Coz, um, it's a lot better to download 4MB of Javascript and have 3-4K pages instead of having just a bunch of 5-6K HTML pages you download one-at-a-time. Errr... Yeah. Oh! And I shouldn't forget security! Coz you can't just do a "View Source" and see... uh... you know... all the data that's on your screen anyway. Besides, everyone knows that "Security Through Obscurity" is the best kind of security.

Suffice to say the trade-off of "saving some bandwidth, maybe, under certain circumstances" is much much more than offset by the pain of effectively duplicating large amounts of server logic in this Javascript garbage and making it about 1,000,000 times harder to actually develop in this environment.

I'll gladly admit I still don't even understand what's involved in creating a new page, or view, or look, or whatever the hell it's called. We have a guy for that, and he apparently understands it. Or can fake it well enough. Then there's debugging. You can't look at the HTML because if you "View Source" it's just this blah of stuff, so you get to run in the Javascript debugger or do some kind of magic thing to see the HTML that actually gets generated. And let's not forget any kind of automated testing. I hope your testing environment understands how to execute Javascript, because there's not a single "standard" HTML href or form on the whole site, even though it's all extremely data-driven.

And I suppose I should mention that there are big chunks of this Javascript that really aren't "real" Javascript, so the whole site only really works under Internet Explorer, and even then only under certain specific versions. Coz the Javascript stuff just breaks or doesn't run right or maybe it runs away screaming or something if it's run on any other browser. But that's ok, coz we can just tell all our customers to install a specific version of Windows 2000 running a specific version of Internet Explorer and we'll be all right!

But hey, that's the tradeoff you have to take when you're working on an Enterprise Application you know. If only we could convince the entire rest of the industry as to how brilliant we are for using this program.

List the ways

2005-07-27T22:01:00.000-04:00

Let's say you have a time-ordered series of objects. Let's say you have an "Original" and a "Current" object, and a bunch of modifications in between that all relate to each other linearly. Let's say that they are all related in some way to some other object, such that you would like to be able to retrieve them from that other object when you want to perform operations on them. Let's further say that it's important that they stay in the same order in which they were created & attached to your related object. Finally, let's also say that you will be performing lots of operations on these objects, which means that efficiency of storage and retrieval and being able to iterate over your collection are all important.

Can you see where this is going? Yep! It's another pop-quiz!

So, this is your scenario, please pick the correct answer for the proper data structure for storing these objects:

A) A Linked List
B) A Doubly-Linked List
C) Either A or B
D) An Arbitrarily-Ordered Array

By now I hope you know what the correct, Enterprise answer is.

Do I need to give you a hint?

Ok.

It's not A, B or C.

That's Right! The correct answer is D! Yes, indeed! The correct way to store this data is as an array where the order in which the objects are placed in the array is undefined, requiring you to manually sort the objects any time you retrieve them and wish to iterate over them! Further, it ensures that to add objects to your collection you have to allocate a new storage collection and clone all of your objects into the new collection rather than being able to dynamically add/remove objects!

Sometimes it's the stupid things that mean so much.

Bracket bracket bracket

2005-07-25T15:51:00.000-04:00

I feel like taking a step back to more simple times, when the kinds of insanity we were dealing with wasn't some deep-rooted psychology and just plain home-grown stupidity.

Like: use of brackets is considered optional.

Yes, this is so simple that any first-year Comp Sci student should know better (at least one who hadn't flunked out for consistently and egregiously doing this sort of thing) but we actually still find stuff like this in the code:


if(foo)
  if(bar)
     doSomething();
  else
     doSomethingElse();

*beats head against wall*

Speak Only Correct Thought

2005-07-21T16:06:00.000-04:00

Everyone knows (or should know if you don't) what the terms "voodoo programming" and "cargo cult programming" mean. More than anything else, these terms define how this project is developed.

I'm working a bug at the moment that is so full of cargo cult and voodoo it's ridiculous. The method names make no sense, there's a call tree seven or eight layers deep to code that is entirely inscrutable as to purpose, the terminology used for whatever few comments there are just doesn't bear much relation to normal english language.

The Genius Architect who designed this disaster has made it a habit to take terms that either have a certain industry-standard meaning and twist them away from their acceptable use, or simply make up new terms to define industry-standard concepts. TLAs rule the design. The important thing is keep people who are working on this project from being able to think in terms outside of the scope of how he has designed and implemented this application.

(For example, a "unit test" is running through the application following a pre-written script. This is also called "component testing." Neither of which is even vaguely close to accurate terms for what is actually going on, but he will pretend to not understand if you use any other terms.)

Cult leaders use this technique to keep people from questioning the outside world, and fascist governments ensure population docility by requiring citizens conform to Correct Thinking. Orwell pegged it with his term "thoughtcrime" - think inside the framework given you and you will be ok and fit in with this project; think outside the allowable terms and you will be treated with derision and scorn and shown to be an inferior developer.

One reason for this behaviour is to try to convince everyone as to what a brilliant genius he is. As long as everyone else stays confused by his lack of adherence to industry-standard terms and his use of made-up phrases he can dazzle the unwary with bullshit made-up phrases that sound awfully impressive when said quickly and with a confident tone.

Another frequent use for this bullshit is intimidation. Dear Leader has a huge ego and he likes it that way. He is so clearly smarter than everyone else. Call something "that thing" or "the whatsit" and he will put his hands on his hips and tap his foot and stare at you until you use the "correct" term. There was a frequent tendency for him to berate us for not learning the "right language" to work on this application until we completely blew up on him and told him to fuck off on his TLAs and bullshit words. Now he uses passive-aggressive attitude to act superior when we don't play his game

But I think the main purpose is just to keep the people working in the code from being able to really think about how awful it truly is. If you are expending all your mental energy trying to figure out what the fuck he's talking about when he starts making up new TLAs and using terms that are almost but not quite what you know they are supposed to mean, you can't effectively fight back against the awful code you are being made to write.

I'm getting a headache anymore just trying to think in the insane doublespeak this application uses and the Great Leader who is trying to drive development. Try to use industry-standard terms and he will try to act stupid ("The what? What's that? Oh! You mean [xxxx]!") until you use his made-up phrases. Try to avoid using his made-up phrases for some programming concept and he will correct you. It's all a horrible mind-game used to keep us off-balance and it's taking its toll on me. I worry that I'll still be able to write real code once I get off this project or if I will have been permanently scarred as to my ability to do anything logical anymore.

[title here]

2005-07-18T16:04:00.000-04:00

I know I try to come up with "clever" titles for these articles, and most of them just sort of write themselves, but recently I came across something just so flat out bizarre that I can't think of even a vaguely clever title for this article.

I was assigned a bug to track down the cause of this strange error that would pop up occasionally when one entered/edited number was larger than the previously-entered/edited number for the same field.

Well it turned out there was a bit of code that took the two input numbers and returned an error if they differed by more than 0.005 but less than 1.000. I duly reported this in the bug list and turned it over to QA for verification and thought "damn that's just weird" and moved along to the next mindbogglingly stupid thing to work on.

Then a couple days ago I got the bug bumped back to me with the note to please "determine the purpose of this code."

See, the code is only like four lines long and called "compareDouble." There are no comments either on the method or inside the code. There is a bit of typical-for-this-code obfuscation in using temporary values to hold the values passed in as parameters for no discernible reason. It's declared public static and called in about a dozen places throughout the code. Now all this code does is take two values, find the difference, and error if the difference is greater than 0.005 but less than 1.000. (Not that it's important, but it's not "greater-or-equal" or "less-than-or-equal." And why 0.005 anyway??)

In other words, is a mystical bit of code that has existed since we received ownership of the project with no documentation as to purpose and so baffling that it's as un-self-explanatory a piece of code as I've ever seen.

I bumped it back to QA with "This code determines if two values differ by more than 0.005 but less than 1.000 and returns an error if so. There are no comments so I am unable to determine why this is being tested."

I guess we'll see what the next step is. There's something slightly unsettling about this one, if you get what I mean.

My rage is fight

2005-07-11T15:40:00.000-04:00

I had a nice, long, relaxing weekend which has energized me to come into work full of angst and hate and the power to despise and abuse this godforsaken abomination of a project in ways I haven't been able to in weeks gone by. My anger fuels me to reach heights of bile and vitriol I haven't even come close to yet. I quote:

"Your hate had time to ferment, age and gain power... before, you were spewing forth raw, barely-distilled hate, which is good for fucking things up but leaves a bad taste. Well-aged, mellowed hate flows down the gullet like water."

I got just one thing to add:

Hail to the King, baby.

GET 'EM OFF ME!!!

2005-07-11T14:23:00.000-04:00

There are a lot of bugs in this program.

I mean a lot.

Like... tons.

And tons.

Oh, you want numbers? Here's numbers:

In March, when we finally got everything into the bug tracking system (which has a whole story of its own) we had about 200 outstanding bugs, with about 50 of them considered "critical," after entry of previously-documented bugs and the first round of so-called "testing." It's now the middle of July and we have about 200 outstanding bugs, with about 50 of them considered "critical" bugs.

In the meanwhile, the team has fixed over 450 bugs.

Ow. Ow Ow Ow. Ow.

This is a system that's "85-95% complete," and would require "six months to reach a production state" at time of acquisition. (Come September three of us will have been working on it full-time for a year and we haven't even hit beta.)

I mean, holy freaking crap on a stick with butter and lime juice, that is just friggin insane. The bugs are popping up at least as fast as we can shut 'em down. It's not just a matter of finding new bugs either. You may have inferred from earlier posts that this system may not exactly be the best designed application that's ever seen the light of day. (In fact, if you've been reading earlier posts I sure hope you've gotten the impression that this is the equivalent of that lump of flesh that horked out of your throat the morning after the particularly bad night at the bar where you stopped asking for drinks by name and started ordering them by size the day after your girlfriend found out you were married and called your place at 2am, so to speak.) I've already lost track of how many times a bug fix has gone into the code to only cause or reveal another bug.

And then there's the whole issue of Glorious Leader changing design specs on us in the middle of dev/bug fixing. It makes a grown man cry, I tell ya.

In short, This Code Sucks.

The Enterprise Programmer

2005-07-04T16:37:00.000-04:00

Here's the promised "4th of July special event"!

Possibly the most famous quote from Dear Leader came after he was given a copy of a Design Patterns book and during a 4-1/4 hour-long phone call about the use of object factories. I can't remember it verbatim, so I'm going to paraphrase:

"Most application developers are only good at writing something that maybe does one function really well, but they can't think of the big picture. So they need these design patterns to help them out. But this is an "Enterprise Application", which is in a class of its own, so those patterns really don't apply."

<blink>APPLAUSE</blink>

That one quote so defines this whole project.

If you read this blog and take to heart the wisdom contained herein, one day you too can aspire to become a true Enterprise Developer.

Lemme float this past you

2005-07-01T15:43:00.000-04:00

In a couple earlier posts you may have seen reference to using doubles for monetary calculation. Yep, that's what this app does. I've been keeping this on the back-burner because it's a tricky one to get into, mainly because it's such a simple and blatantly obvious topic that it's hard to even write about.

The back-end is a well-known database whose name may or may not begin with the letter "O", so there's no problem there, because it's stored in the database in a sane type for money. It's when it gets into the program logic, and even the user interface that it gets really weird.

This is a web-based application and there is an ungodly amount of Javascript involved. There's not just little Javascript bits here and there - great portions of the application logic have been reproduced on the client (i.e. web browser) side, as well as using javascript to actually render the pages and do page submission and such. This subject deserves an entry of its own, so just take as given that as bad as the server-side Java is, it's pretty close as bad in your browser as well.

What's this have to do with floats for money? Well, first of all your browser does a bunch of calculations on its own in Javascript. If you enter a monetary value (and this application is chock full of monetary values. In fact, I'd go so far as to say that calculating monetary values is its primary purpose. More I cannot say without giving too much away.) the browser does a bunch of calculations to show you subtotals, percentages, totals, and such. Oh, and then it fills a lot of that in for you so you don't have to figure it out yourself and sends it back to the server.

Now frankly I have no idea, nor do I especially care, how Javascript handles floating-point values. I do know that we shouldn't be accepting some of the calculated values at face-value when we get them back from the browser, having been filled-in by Javascript functions. Yet this is only the first step of the horrible, horrible things this app does with numbers.

However, the server doesn't necessarily take all of those values as given. It recalculates a bunch of them. Using double values. That it fills in from stuff it got from the browser that maybe the user typed in or maybe got calculated by Javascript. It's kind of a mess, so it's kind of hard to figure out in every case which values you have came from where.

Now, once we have the values, we calculate a bunch of derived values from them (as double of course) and store them in the database. Then, after every transaction, we retrieve it all, put them back into doubles calculate everything all over again for everything that came before that transaction in this sequence of transactions (there's another whole entry on that subject...) and store it all right back in the database.

In other words, any time you add an entry onto this particular series of transactions, the system pulls the values from the database, stuffs them into double type variables, does a bunch of calculations against them, then stores them back in the database. Every time.

If you aren't rolling around on the floor in pain by now, I'm afraid I'm not going to be able to explain this to you. Just say that each time you go back and forth between a double and something sane your margin for error gets smaller and smaller. (Or larger and larger, depending on how you are looking at it.) At least double is better than float. Not that that's saying much.

If you do understand, it gets even better.

Me: "But you can't do calculations with doubles! You can't guarantee the accuracy of a 'double' type! They are just binary approximations of a floating-point value, you should be using BigDecimal if you want to do money, because it stores it encoded especially to not lose accuracy!"

The Enterprise Designer: "No, it's fine as long as we keep three decimal places."

Me: *boggle*

Yeah, that was his exact argument: "As long as we keep three decimal places."

Some days it's hard just getting out of bed.

When I tried to explain that the programmer really had no control over "how many decimal places" the program was going to retain to any degree of accuracy, and to please try to find and read something about IEEE floating point specs if he didn't believe me, he pointed back to a piece of code that I had discovered a few weeks prior which started my campaign to drive double out of this code.

If you aren't sitting, please do, because this is going to hurt. Here's what this code does:

double roundFloat(double input)
{
    long tempLong = Math.round(input * 1000);
    return ((double)tempLong/1000.0);
}

Hee hee. Hee hee hee heee. Hah haha! AHh hahahaha!! HAHAHAHAHA!!!!!

Ahem.

That's how he "guaranteed" the app would "keep three decimal places."

Happy birthday! Please feel free to use this simple and elegant hack in your own code that deals with very important monetary values!

The best part was the over-an-hour-long argument I had with Fearless Leader over why using doubles to handle money values was a bad idea. I can't quite grasp which was more amazing, that he designed it that way to begin with or that he was arguing with me over the point.

This argument happened about six months ago. I recently heard he is still plotting ways to prove to me why I am wrong.

P.S. Stay tuned for a Very Special July 4 entry! It's arguably the most famous incident from this whole project.

P.P.S. I should point out that we have seen rounding errors with some input values. Dear Leader has dismissed these as "corner cases" and not important to consider, as they are "unlikely to occur in real life."

bait and switch

2005-06-30T15:58:00.000-04:00

This project is written in Java. Java is "Object Oriented Programming". So obviously the best logical construct you can put in your code is ....

switch/case of course.

Let's say you have a couple different object types (but only a couple, we don't want to create too many objects after all) and you want to do different actions based on what kind of object you have. What's the most logical way of doing this?

switch/case of course. What were you thinking? Method overloading? Oh, you make me laugh so, sir!

No, the correct way to handle this situation is to put some method in your object type that returns a string value that lets you know what kind of object you have, that way you can write a big switch/case block based on what kind of object you have, to execute different methods! Oh, but wait, switch/case doesn't work on String types, whatever shall we do?

The Enterprise Programmer is not lost when they get in a situation like this; no, they plug on and they figure out a way to make their methodology work. In this case, what we need to do is write another method that translates from the String value into an int value we can plug into the switch/case. Brilliant! Now we just need to make sure that our method that maps from a String to an int is kept synchronized with the actual values the objects return, but that's not a problem for the Enterprise Programmer!

So what we wind up with instead of this:


method(A obj) { }
method(B obj) { }
method(C obj) { }

is this:


static final String OBJECT_A = "ObjectA";
static final int OBJECT_A_INT = 1;

static final String OBJECT_B = "ObjectB";
static final int OBJECT_B_INT = 2;

static final String OBJECT_C = "ObjectC";
static final int OBJECT_C_INT = 3;

private int whatObjectIsIt(Object obj)
{
    if(obj.nameOf() != null && obj.nameOf.equals(OBJECT_A))
       return OBJECT_A_INT;
    else if(obj.nameOf() != null && obj.nameOf.equals(OBJECT_B))
       return OBJECT_B_INT;
    else if(obj.nameOf() != null && obj.nameOf.equals(OBJECT_C))
       return OBJECT_C_INT;
    else
       doSomeKindOfHalfAssedErrorHandling("With Some" + 
                            "Inscrutable Error Message");
}

public void doSomething(Object obj)
{
    switch(whatObjectIsIt(obj))
    {
        case(OBJECT_A_INT):
            doSomethingWithA(obj);
            break;
        case(OBJECT_B_INT):
            doSomethingWithB(obj);
            break;
        case(OBJECT_C_INT):
            doSomethingWithC(obj);
            break;
        default:
            MoreHalfAssedErrorHandling();
    }
}

Now that's so much more elegant, isn't it? I bet you wish you had thought of it first.

Oftentimes those "doSomethingWithA" type methods have further, similar, switch/case statements in them. I sure wish I was making this all up.

P.S. In case you noticed, I did it on purpose, putting brackets around if/then/else statements, or case statements, to help delineate blocks of code is really unnecessary, because the Enterprise Programmer can tell where those logical blocks are without the need of all those extraneous brackets! (Besides, those brackets probably add performance overhead so it's best to leave them out.) There's a whole other blog post on this subject too.

P.P.S. Sorry it's been so long between posts. The angst was getting too much and I was unable to see through the tears to write anything for a while.

P.P.P.S. Sometimes they forgot to put a "break" between the cases. Sometimes that's accidental, and sometimes the code relies on falling through to the default, or even just the next case. It's never obvious which way it is, as if this needed to be said.

And now you know...

2005-06-19T19:21:00.000-04:00

A little more background on the situation:

The company I (along with fly and anon) work for, (A), is in a certain line of business. Person (B) has a company (C) that happens to operate in the same line of business as (A) and was developing a software "solution" (D) that handled an area of business that (A) did not yet cover. (C) ran out of money for (B) to continue developing (D). Rather than write our own, (A) bought (D) from (C) with the stipulation that (B) comes along with to complete development. (B) is the designer, architect and overall master of how (D) was written. When we acquired the rights to the code, it was claimed to be "about 85-95% ready for production" which made us all think it would take a few months, we could put it online, and move on.

Hah.

The actual truth of the situation is what you are reading about here. If only the software were as easy to follow as the soap-opera this whole nasty business has turned into.

And now you know... the rest of the back-story.

Logically Thinking

2005-06-19T14:33:00.000-04:00

The designer is always right. Remember that. If you get that, all else follows logically.

Dear Leader likes using all kinds of logical fallacies when he is arguing his point. I'm still not really sure if he truly believes that it's a valid argument to say, "Everything you say is valid except for this one irrelevant point, therefore your entire argument is invalid."

He also loves to argue any position as long as it's opposite yours, even if it's completely in opposition to the point he was arguing for ten minutes ago. The initial premise is "He is always right." Any argument used to prove that premise is a valid one. "Begging the question", "straw man" and "irrelevant conclusions" are among his favorites.

I had a 4-1/2 hour conference call about the use of the Factory pattern. I think I'm still owed a drink for that one. It started innocently enough with my attempts to refactor some of the code to use actual factories. (Recall the previous post talking about A->B->C->D? Well, the method that creates A, B and C is in A, which initializes some values of A and B, then calls a method in C that initializes some values for C and then calls another method in C that creates a D and initializes it.) It then degenerated into a pointless argument about "tightly-coupled objects" and how certain objects needed to know how other objects were created and how other objects didn't need to know how they were created themselves; essentially arguing against basic OOP strategies.

It came down to, "If you accept that this system requires 'tightly-coupled objects' then you must accept that my argument is correct." Denying that any system requires 'tightly-coupled objects' got the response, "but you're wrong, it does." (It also resulted in the most famous quote from this entire project, but I'm saving that for its own entry.)

Trying to get out of the argument by saying, "I just don't agree", or "I don't understand, but I'll take your word for it, let's move on" just gets you into one of his other favorite strategies to prove you are wrong and he is right: "Oh, but maybe I don't understand, so explain to me so I can understand." Which is pretty much just a shallow ploy to say, "If you can't convince me, you must be wrong."

The designer is right. If he wasn't right, he wouldn't have designed it that way. Therefore you are wrong. QED.

Anti-Theme

2005-06-18T14:37:00.000-04:00

This post will be a short one, with hopefully a very telling story:

"... there are some problems I keep seeing in J2EE projects. I'd say the top three problems are over-engineering, neglecting performance considerations and inflexibility." (Expert One-on-One J2EE Design and Development Interview with Rod Johnson)

Now, I'm not saying this project is J2EE. Nor am I denying it. Let's just say the technology used is along a similar intent. But that's not the point of the quote. What's really applicable are the three problems touched upon. Each are unbelievably applicable in this system.

First, let's talk about over-engineering shall we? Having cyclic dependencies running through a persistence framework that use its object cache as the system's sole repository for computations with object retrieval and filtering done by way of a home-grown object graphing nightmare sound complicated enough for you? It's just too much to fathom, really.

Second on the "things not to do in software engineering" list is neglecting performance. Now, this doesn't mean prematurely optimize while constructing a system. It also doesn't mean agonizing over each abstraction decision (hah, I'd love to have that problem again, but that's another blog all together). What it does mean, though, is to actually run your system under a reasonable load while creating it. Requiring four high end servers to handle about 300 transactions per day is, by every definition, neglecting performance.

The last one would take a week to give proper coverage with this system. The object graph dependencies, exposing just about every attribute by way of "handles", and the cyclic dependencies mentioned before will mix to give you a system as malleable as concrete.

How does that one song go again? "These are some of my favorite things...." Yea, right.

this.sucks

2005-06-16T17:23:00.000-04:00

Debugging this app is impossible.

Let's say you have an object graph that looks like A->B->C->D. Let's say you have a method that performs some actions upon object A. Where would be the logical place to put that method?

Well you'd think somewhere in some helper class or something, and you'd be wrong because in this case, it happens to be in C. It gets better than that though, because the method takes an object type "A" as a parameter, and it gets called from another method inside of object A. Here's basically what it looks like inside of A:

public void someMethodInA()
{
   this.getB().getC().doSomethingWithA(this);
}

If that's not enough to give you the heebies and the jeebies, in object C they use their wacky persistence framework to actually set the property values for A:

public void doSomethingWithA(A myVeryOwnA)
{
    MyPersistenceThing.setSomeProperty(myVeryOwnA, 
                             "propertyName", value);
}

And as you've already learned, everything is global. So if you're debugging, trying to figure out why some global property of A is getting set incorrectly, and you have to go through that method it all of a sudden gets a lot harder. If you were watching this.someProperty while you were tracing inside of an instance of object A, it's no longer in-scope, and you now have to watch myA.someProperty from inside of object C.

If that doesn't make a lot of sense, don't worry, it doesn't make much sense in the code, or in the debugger either. This sort of thing is riddled all throughout the code, which means when you're trying to watch some property value as it changes through the code, you wind up with eleventy-seven watches, most of which are out-of-scope most of the time, all of which are actually references to the same object, called different things from different places, and none of it really matters because you're relying on your wacky persistence framework to set the values of the object out of sight where you can't see it happening anyway.

Creepy, huh?

I know what your thinking..

2005-06-15T21:59:00.000-04:00

Ok.. for those of you who took the time to read this blog.. It might sound like a bunch of rebellous developers who have a problem with authority.. Well.. your partially correct, but mostly wrong.. (I'm dead now when they read this). Let's put asside the mention of authority figures for a moment and discuss the reality of this project. Everything, I mean everything so far written in this blog sounds unbelievable, but it is true.. and there are so many other things to mention. How would you like to work with a Project Lead who does nothing but point fingers and never admit fault to anyone ever. Sounds like the damn Republican party. Oh, did I mention he is a Republican. Those of you who are Republicans, never fear underdog is here.. whoops, didnt' mean to slip this out.. Thought I was in this other blog I post to called I want to be a cartoon character...

Na.. what I mean is, I am a Republican without a party.. I want small government.. I want low taxes.. I want those things, but this Administration, and the Republican party as a whole today have divided our country by forcing their will on the American People.. Forgetting that half of america didn't want the Shrub in office and don't think like their party.. Bush has about as much integrity as most people have in there pinky finger. This Project Leader has the same qualities as the shrub.. They are as follows:

1. Both will never admit to fault.. Blame is a way of life..
2. They think they are doing things right, but they are really just fucking up miserably.
3. They kill the messanger instead of having open discussions about policy.
4. They fucking lie and cheat if they can't win on even ground.
5. They divide the group because they can't seem to get people to like them because of their overbearing manipulative ways..

All I can say is what comes around goes around.. and things will go around someday soon..

Keep you posted..

Fly on the outhousewall. <-- later changed to fly on the meeting room marker board..

"Too Many Objects"

2005-06-15T17:45:00.000-04:00

When asked why there were so few actual objects and why every object seemed to be crammed to the gills with unrelated methods, the answer we got was, "Because we didn't want to make too many objects and have a performance hit."

There's not a whole lot much else to say on this one.

Not Invented Here

2005-06-11T23:02:00.000-04:00

The Fearless Leader is a firm believer of "not invented here." Not because of any kind of weird legal issues or anything; it's simply because he thinks he's so much smarter than everyone else that there's no sense using an inferior implementation if he can write it from scratch according to his design and standards.

For instance, when we got our hands on it, the code had its own implementation of reflection. A method would use reflection to gather up all the methods from the named class, scan through them comparing against the method name and parameter list it was being asked to find, and if it existed, would invoke it. If it didn't exist, it would generate an error. (Notice that I didn't say "throw an exception". That's another story...)

Only problem is, if it found a matching name, but the wrong argument list, it would also error out.

Reread that carefully. See if you can think of why that's a problem. Here's a hint: overloading. Yep, if you overloaded a method to take different arguments, and it found the "wrong" one first, it would error out without ever finding the "correct" one that you had overloaded.

The bugfix involved deleting some 700 lines of "our very own reflection" code and just using reflection as implemented by the JDK.

(I'm still baffled as to how the built-in reflection was OK enough to use to gather the method list for a given class, but not to use to do the actual work of what all that code was trying to accomplish.)

That was one of our first clues that the problems with this code ran much deeper than what we had already figured out in the first couple months of working with it.

Globally Stupid

2005-06-10T14:50:00.000-04:00

Our Dear Leader believes that passing parameters to a function causes a performance hit. Which is why all smart programmers store values globally.

Not only that, but we shouldn't declare variables, since we can't predict ahead of time what values we might want to store in any particular object or property. Smart programmers use a global hashmap that can store arbitrarily named key/value pairs. (This is Java, by the way.)

This method proves its obvious superiority when you also realize that it allows other objects to reach into that hashmap (because it's declared public, of course) and add/modify/delete stuff out of it at whim. Only stupid programmers write accessor methods.

I now see the errors of my ways. Some day soon I will reach enlightenment.

Abstractions are for Newbies

2005-06-10T05:30:00.000-04:00

Yea, that's right. You read the title correctly. On this one project I'm on, the mantra of "keep it simple stupid" (kiss) has been morphed into "stupid people keep it simple" (spkis, a Czech hockey player). Collaborations between objects are replaced with convoluted monolithic methods, some having a cyclomatic complexity of well over 50. Yes kids, that means over 50 control altering statements within one method!

And don't think it's isolated either. Strewn throughout these hairballs for methods are dependencies on other classes' internal implementation. So change a Vector to an ArrayList, for example, and watch the system go boom. Sometimes. Depending on what check box you selected on a particular screen that's only visible if you've done a prior (seemingly unrelated) step.

What most disgusting, or amusing depending on how perverse your sense of humor, is hearing the vendor state "tightly coupled objects are better in enterprise systems." Amazing as it sounds, this is the actual quote. Never mind the, oh I don't know, ENTIRE INDUSTRY OF SOFTWARE ENGINEERING DISAGREE!

And here's some evidence to support this thesis: http://www.sei.cmu.edu/str/descriptions/cyclomatic_body.html#table4

Requirements and Standards

2005-06-08T23:36:00.000-04:00

This might as well be our programming guide for this project.

Wishful Thinking

2005-06-08T20:57:00.000-04:00

Dear Sir:
You are a fucktard. The code we received uses floating point variables to store money, prima facie evidence of your fucktardness. We are not paying you, because you misrepresented yourself as competent at the time of our initial agreement.
Very truly yours, &c.

Dear Gullible:
You paid me millions for this shitty ass code I hacked up on my spring break. The floating point variables are to keep me employed as your contractor until this code dies a horrible death. Enjoy the pain.
Your Fucktard

Dear Gullible and Fucktard:
I just wasted eight months of my life turning my brain into mush looking at and fixing Fucktard's idiot-boy code, while Gullible was too panty-waisted to tell Fucktard to go to hell. I'll be seeing you both tomorrow morning with a flak vest, a shotgun, several handguns and a big knife.
Sincerely, Gone Mental

Dear Fucktard:
You are my idol. Can you teach me how to be a worthless leech on society so that I may also profit from the suffering and pain of others like Gone Mental? I have body armor and a good health plan.
Yours, The Common IT Professional.

Denial of fault

2005-06-08T17:04:00.000-04:00

One of the worst things to deal with on a project is having a team member that is incapable of admitting that they are wrong. Let's face it, we're all human. No developer/engineer/manager makes perfect decisions all of the time. So have the fortitude to admit ones weaknesses!

Dogmatically arguing a known flawed point is futile. It's like trying to teach a pig to sing. It wastes your time and annoys the pig. On a recent project, a semi-technical consultant advocated using doubles for monetary computations in a Java application. This is just plain wrong in that environment (do a web search and pick one of the first dozen articles on the subject if you like). However, even in the face of massive evidence, the consultant "stuck to their guns." All this did was to further alienate the rest of the team. Furthermore, any changes that others made to correct the mistake were attacked.

Once this interaction had been established, other ingenuative approaches weren't event presented. The senior programmers simply resolved themselves to patching crap code until the (quite numerous) bugs seemed resolved.

The moral of this story is to listen to those around you. Especially if they've been paid for a very long time to solve the problems you are working on.

Sad but true

2005-06-08T16:50:00.000-04:00

It's a shame.. The company is one of the best I've worked for but the product is the absolute worst I have ever seen, and I've seen some really bad stuff.. I sometimes feel like I'm in the twilite zone. The philosophy of the owner/developer seems to be backwards to what the industry is claiming to be good design/coding styles...

First Post

2005-06-08T15:59:00.000-04:00

So I'm part of a small team working for a company that's working on a source code project. When we acquired this software, it was alleged to be "95% complete" yet we've spent the last eight months closing 350 bugs and we still have over 200 outstanding bugs.

Welcome to the insanity.