Comment On Command 696

Morale of the day: becareful what you wish for.

Being tasked with a complete rewrite is a good thing ONLY IFF you have requirements or specifications beyond "it should work just like the current app".

I have iterated your methods pray I don't iterate them any further.

"ARE YOU SURE AFT CARGO COMPARTMENT IS EMPTY!!!!"

What is your question!!!!!!!

Nice.. VB6 in aircraft software. Maybe, hopefully, it's simulator software.

(Assuming the Dash 8 involved is in fact the de Havilland Dash 8 (see http://en.wikipedia.org/wiki/Bombardier_Dash_8))

ONLY IFF = ONLY (IF AND ONLY IF).

Happy to help. My fees are reasonable. Let's go to the ATM machine, punch in your PIN number, and withdraw a shiny quarter.

I particularly like all of the empty
Else
End If
blocks.

'Cuz, you can't write an If without and Else.... That'd be crazy.

I have failed to frist your post. Pray I don't fail to frist it any further.

I am flying on a Dash-8 tomorrow. Ugh.

I'd be very careful. This seems to be a ground-based tool that manages airplane load and weight distribution. Probably it does other things, too, but Dash 8 is a plane made by Bombardier, PAX are passengers, etc. Maybe the submitter just doesn't have a clue, but the logic for this application is pretty much given by the manufacturer and airline operation manuals. I don't know this particular application, and I have nothing to do with airline industry, but I presume if I could figure it out in one minute, the submitter better ask themselves "should I be doing the job"?

Yes, the application is a WTF, because many such frontline apps are on life support since day one, and all fixes/modifications are done with flames under your feet, and the industry is chronically short of money, yada yada.

But methinks TDWTF is that the submitter seems somehow confused -- he shouldn't be.

Ok, I think we've found the root cause for these:
http://en.wikipedia.org/wiki/Bombardier_Dash_8#Incidents_and_accidents

Fixed?

private void command696Clicked()

  try {

  String docName;

  int response;



  if (frame500 == 1 && pax > 37) {

	JOptionPane.showMessageDialog((Frame) null, "CHECK PAX DASH 8 LIMIT 37 SEATS", JOptionPane.QUESTION_MESSAGE);

  }

  if (frame500 == 2 && pax > 29) {

     JOptionPane.showMessageDialog((Frame) null, "CHECK PAX DASH 8 LIMIT 29 SEATS", vbOKOnly  

  }

  if (totalload1 > 2000) {

     JOptionPane.showMessageDialog((Frame) null, "OVERWEIGHT Fwd Shelf ", vbOKOnly  

  }

  if (ttshelf > 1000) {

     JOptionPane.showMessageDialog((Frame) null, "OVERWEIGHT Aft Shelf ", vbOKOnly  

  }

  if (totalload1 + ttshelf > 2000) {

     JOptionPane.showMessageDialog((Frame) null, "OVERWEIGHT Aft Compartment max 2000 lbs ", vbOKOnly  

  }

  if (frame500 = 1 && totalloadsecd > 0) {

     JOptionPane.showMessageDialog((Frame) null, "DASH 8 WITHOUT SECTION D ", vbOKOnly  

  }

  if (frame500 = 2 && totalloadsecd > 2150) {

     JOptionPane.showMessageDialog((Frame) null, "OVERWEIGHT SECTION D ", vbOKOnly  

  }

  if (remaining < 0) {

    JOptionPane.showMessageDialog((Frame) null, "DASH 8 OVERWEIGHT REDUCE LOAD !!!!", vbOKOnly 

  }

  if (ttload <= 0) {

    response = JOptionPane.showMessageDialog((Frame) null, "ARE YOU SURE AFT CARGO COMPARTMENT IS EMPTY!!!!", vbYesNo)     

  }

  if (frame500 == 1 && pax <= 37 && totalload1 <= 2000 &&

     ttshelf <= 1000 && totalloadsecd == 0 &&

     remaining >= 0 && totalload1 + ttshelf <= 2000 && Response = 6) {

    docName = "csaprintinfo37seats"

    DoCmd.getInstance().openReport(docName, acPreview);

  }

  if (frame500 == 2 && pax <= 29 && totalload1 <= 2000 && _

     ttshelf <= 1000 && totalloadsecd <= 2150 && _

     remaining >= 0 && totalload1 + ttshelf <= 2000 && Response = 6) {

    	docName = "csaprintinfo29seats"

    	DoCmd.getInstance().openReport(docName, acPreview);

  }

  } catch (Exception ex) {

    command696ClickedError(ex);

  }

}

Drak:

Nice.. VB6 in aircraft software. Maybe, hopefully, it's simulator software.

(Assuming the Dash 8 involved is in fact the de Havilland Dash 8 (see http://en.wikipedia.org/wiki/Bombardier_Dash_8))

Me too, but I don't think we are that lucky.
As the code presented apparently are concerned with bagage load in a Dash 8. Considering the elefantine slow development in the air industry, I would not be surprised to see our national carrier (SAS) use WB6 or something similar in use today....

Yazeran.

Plan: To go to Mars one day with a hammer (And NOT on a Dash-8 :-))

This must be the US localization as more than half of rules are about being overweight.

Yazeran:

...

Yazeran.

Plan: To go to Mars one day with a hammer (And NOT on a Dash-8 :-))

You made me giggle with that addition to your signature :)

The Nerve:

Fixed?

  if (frame500 == 2 && pax > 29) {

     JOptionPane.showMessageDialog((Frame) null, "CHECK PAX DASH 8 LIMIT 29 SEATS", vbOKOnly  

  }

I think I could have quite happily lived the rest of my life without seeing JOptionPane and vbOKOnly in the same line of code. Thanks for ruining that for me.

Kuba:

I'd be very careful. This seems to be a ground-based tool that manages airplane load and weight distribution. Probably it does other things, too, but Dash 8 is a plane made by Bombardier, PAX are passengers, etc. Maybe the submitter just doesn't have a clue, but the logic for this application is pretty much given by the manufacturer and airline operation manuals. I don't know this particular application, and I have nothing to do with airline industry, but I presume if I could figure it out in one minute, the submitter better ask themselves "should I be doing the job"?

Yes, the application is a WTF, because many such frontline apps are on life support since day one, and all fixes/modifications are done with flames under your feet, and the industry is chronically short of money, yada yada.

But methinks TDWTF is that the submitter seems somehow confused -- he shouldn't be.

This ^^^

If this is truly a rewrite, the butt-ugly implementation doesn't matter, else. Design the new application in a way that makes sense from the original requirements. If the original requirements can't be found or don't exist, derive a new set from the way the old application is used, else.

bd:

This must be the US localization as more than half of rules are about being overweight.

Response = 6

mott555:

The Nerve:

Fixed?

  if (frame500 == 2 && pax > 29) {

     JOptionPane.showMessageDialog((Frame) null, "CHECK PAX DASH 8 LIMIT 29 SEATS", vbOKOnly  

  }

I think I could have quite happily lived the rest of my life without seeing JOptionPane and vbOKOnly in the same line of code. Thanks for ruining that for me.

I got lazy and didn't convert all the JOptionPane.

Kimvais:

http://en.wikipedia.org/wiki/Bombardier_Dash_8#Incidents_and_accidents

Too bad there is apparently no anchor #Hints_and_allegations.

Wow, that's pretty bad code. It would be worth a million to rewrite it. Intro was exciting -- someone could make a movie about this. They could call it Brewster's Millions.

Hey it works. Don't mess with it. Rewriting SOUNDS good, but the code has years of undocumented business rules in it that you'll never figure out.

The Nerve:

Fixed?

  if (frame500 = 1 && totalloadsecd > 0) {

     JOptionPane.showMessageDialog((Frame) null, "DASH 8 WITHOUT SECTION D ", vbOKOnly  

  }

  if (frame500 = 2 && totalloadsecd > 2150) {

     JOptionPane.showMessageDialog((Frame) null, "OVERWEIGHT SECTION D ", vbOKOnly  

  }

"frame500 = 1" and "frame500 = 2". Pretty sure you didn't mean to assign a value here.

NOT VB6 - it is VBA. The line

DoCmd.OpenReport stDocName, acPreview

is specific to MS Access.

Umm.. Where is the WTF? Badly written, perhaps... Lacking easy maintainability, sure... But a WTF? Not really. I've seen worse, daily.. for most of my career. If the function was being recursively called with a static integer and a case statement to decide which if statement to check.. now that would be a WTF.

Private Sub Command696_Click()

  Dim stDocName As String

  Dim Response As Integer  

  On Error GoTo Err_Command696_Click

  Static val as Single

  val = val + 1

  

  select case optselected

  case 1

  If Frame500 = 1 And pax > 37 Then

     MsgBox "CHECK PAX DASH 8 LIMIT 37 SEATS", vbOKOnly

  Else

  End If

  case 2

  If Frame500 = 2 And pax > 29 Then

     MsgBox "CHECK PAX DASH 8 LIMIT 29 SEATS", vbOKOnly

  Else

  End If

  case 3

  If totalload1 > 2000 Then

     MsgBox "OVERWEIGHT Fwd Shelf ", vbOKOnly

  Else

  End If

  case 4

  If ttshelf > 1000 Then

     MsgBox "OVERWEIGHT Aft Shelf ", vbOKOnly

  Else

  End If

  case 5

  If totalload1 + ttshelf > 2000 Then

     MsgBox "OVERWEIGHT Aft Compartment max 2000 lbs ", vbOKOnly

  Else

  End If

  case 6

  If Frame500 = 1 And totalloadsecd > 0 Then

     MsgBox "DASH 8 WITHOUT SECTION D ", vbOKOnly

  Else

  End If

  case 7

  If Frame500 = 2 And totalloadsecd > 2150 Then

     MsgBox "OVERWEIGHT SECTION D ", vbOKOnly

  Else

  End If

  case 8

  If Remaining < 0 Then

    MsgBox "DASH 8 OVERWEIGHT REDUCE LOAD !!!!", vbOKOnly

  Else

  End If

  //blah blah blah

  case 999

     Exit Sub

  end select

  Command696_Click

end Sub

Now that would be a WTF. Excuse any syntactical errors, I haven't written any VB in a looooong time.

-Yard

Pssh. Whippersnappers. When your idea of ancient doesn't involve having to read tech manuals and language references written on dead tree media, I don't have any sympathy.

VB6 sucks, but VB6 and MSSQL2k is nothing compared to working with crap like COBOL or RPG, working on legacy databases (Turbo Image, anyone?)

JK:

NOT VB6 - it is VBA. The line

DoCmd.OpenReport stDocName, acPreview

is specific to MS Access.

Oh. In that case, isn't there a wizard you can use to refactor it?

Bad VBA code... what a surprise!

I am continually amazed that people really just throw together shitty code without any idea of what it does or how it can be improved. Even when I was actively doing programming I had some dozen programming blogs and websites that I visited regularly, and I had subscriptions to magazines and video sites where I could hone my skills and become a better developer.

Yet, almost everything that comes here is tossed together by some twit who has no idea what they're doing, and probably learned by picking up a SAMS "Teach Yourself VBA in 24 Hours" book, and never once thought "Hmm there might be a better way to do this" or "Maybe I should use descriptive names instead of the defaults". What the hell goes through the minds of these people? Are they just ignorant?

Gary:

I am flying on a Dash-8 tomorrow. Ugh.

Is it the 37-seater, or the roomier 29-seater? And does it have a SECTION D? (And don't forget to check if the AFT CARGO COMPARTMENT IS EMPTY!!!!)

Drak:

Nice.. VB6 in aircraft software. Maybe, hopefully, it's simulator software.

(Assuming the Dash 8 involved is in fact the de Havilland Dash 8 (see http://en.wikipedia.org/wiki/Bombardier_Dash_8))

It's scheduling/manifest software, not flight applications. This would never pass V&V. Besides, DASH-8s don't have compartmentalized mass sensors.

Yardik:

Umm.. Where is the WTF? Badly written, perhaps... Lacking easy maintainability, sure... But a WTF? Not really. I've seen worse, daily.. for most of my career. If the function was being recursively called with a static integer and a case statement to decide which if statement to check.. now that would be a WTF.

...snip...

Now that would be a WTF. Excuse any syntactical errors, I haven't written any VB in a looooong time.

-Yard

Agreed, planned to say the same thing. This is ugly as hell and it certainly shows that the devloper wasn't your best and brightest, but it isn't really a WTF.

On that note, VB has a bad wrap less becuase of the language, and more because of its accesibility. People who don't know much about good practices or developing for maintainability are more commonly using VB, but that doesn't mean the language itself is a WTF or that good code can't be written with it. Same goes for MS Access, used right, and within the limits of what it is designed for, it's a decent little app for small scall and quick turnarounds; the problem isn't the platform, it's the accessibility to poor developers.

The Nerve:

Fixed?

private void command696Clicked()

  try {

  String docName;

  int response;



  if (frame500 == 1 && pax > 37) {

	JOptionPane.showMessageDialog((Frame) null, "CHECK PAX DASH 8 LIMIT 37 SEATS", JOptionPane.QUESTION_MESSAGE);

  }

  if (frame500 == 2 && pax > 29) {

     JOptionPane.showMessageDialog((Frame) null, "CHECK PAX DASH 8 LIMIT 29 SEATS", vbOKOnly  

  }

[...]

Sorry, but your "fix" doesn't meet the requirements that it be 100% compatible with the old app. Your code is completely missing all of the "else" code.

DaveAronson:

Kimvais:

http://en.wikipedia.org/wiki/Bombardier_Dash_8#Incidents_and_accidents

Too bad there is apparently no anchor #Hints_and_allegations.

Hey, what's stopping you? This is Wikipedia, after all.

justsomedude:

On that note, VB has a bad wrap less becuase of the language, and more because of its accesibility. People who don't know much about good practices or developing for maintainability are more commonly using VB,[...]

VB... a language so simple to learn that even an idiot could use it... and many do.

Kuba:

But methinks TDWTF is that the submitter seems somehow confused -- he shouldn't be.

Methink it's presumptuous to assume that the submitter is confused. I can easily understand the code, but the prospect of rewriting an application (where there are at least 695 more of these command-validation functions) is unappealing to me to say the least.

brazzy:

Morale of the day: becareful what you wish for.

Being tasked with a complete rewrite is a good thing ONLY IFF you have requirements or specifications beyond "it should work just like the current app".

Funny thing, I've had projects where I was rewriting buggy/misbehaving apps. While trying to tease out reqs/specs on how the business needed the applications to work, I was always told that first they wanted the app rewritten to behave the exact same way as it currently does, and after that I would make the functional improvements that they want. After all, I don't want to take on too many tasks at once now, do I?

Who doesn't like having to rewrite code to reproduce the same buggy or just-plain-wrong behavior as the original?

Hmm. Turns out it wasn't that funny after all.

DaveAronson:

Kimvais:

http://en.wikipedia.org/wiki/Bombardier_Dash_8#Incidents_and_accidents

Too bad there is apparently no anchor #Hints_and_allegations.

Can I call you Al?

Sure, and I can call you Betty.

I have refactored the code...pray that it works.

frits:

If this is truly a rewrite, the butt-ugly implementation doesn't matter, else. Design the new application in a way that makes sense from the original requirements. If the original requirements can't be found or don't exist, derive a new set from the way the old application is used, else.

EXACTLY. A rewrite should only look at requirements, not the hideous old implementation. Throw that code into a vault and only take it out if you install the rewrite and they go "heyyy it doesn't work like it used to". Then you go "well, why did you give me invalid requirements?". Only THEN do you take out the old program and try to see how it behaved, add those to the requirements, and then lock it in a dark place again.

ObiWayneKenobi:

SAMS "Teach Yourself VBA in 24 Hours" book

And that is TRWTF. The programmers who write these books are ultimately responsible for about 90% of all WTFs for convincing people who have no business programming anything more advanced than a VCR that they too could be leet coders, and in just 1 day!

boog:

While trying to tease out reqs/specs on how the business needed the applications to work

Apparently all you have to do is write an app that ejects the CD tray.

DaveAronson:

Kimvais:

http://en.wikipedia.org/wiki/Bombardier_Dash_8#Incidents_and_accidents

Too bad there is apparently no anchor #Hints_and_allegations.

I don't find that stuff amusing anymore...

Mr Gangreen:

DaveAronson:

Kimvais:

http://en.wikipedia.org/wiki/Bombardier_Dash_8#Incidents_and_accidents

Too bad there is apparently no anchor #Hints_and_allegations.

I don't find that stuff amusing anymore...

The real WTF is the angels in the architecture. What were they thinking? Everyone knows that leads to an endless loop...

Anon:

... a VCR ...

What's that?

evilspoons:

EXACTLY. A rewrite should only look at requirements, not the hideous old implementation. Throw that code into a vault and only take it out if you install the rewrite and they go "heyyy it doesn't work like it used to". Then you go "well, why did you give me invalid requirements?". Only THEN do you take out the old program and try to see how it behaved, add those to the requirements, and then lock it in a dark place again.

That's easier said than done. Sometimes there are no documented requirements. And sometimes (as was probably the case in the submitted code) there are many intricate business rules that you won't know about (and often times, neither will the customer/user); the only way to discover them is to look in the code.

The very fact that the submitter has to rewrite the app implies that it wasn't done right the first time. Even so, in such projects, the original code may end up being the only semi-reliable documentation you have.

evilspoons:

A rewrite should only look at requirements, not the hideous old implementation. Throw that code into a vault and only take it out if you install the rewrite and they go "heyyy it doesn't work like it used to". Then you go "well, why did you give me invalid requirements?". Only THEN do you take out the old program and try to see how it behaved, add those to the requirements, and then lock it in a dark place again.

Wrong, wrong, wrong, wrong, and wrong.

A few years back, a JoelOnSoftware column made a pretty good (but imperfect) case for never doing a rewrite at all. The basic premise was that as you are spending a huge amount of time and money on the rewrite, you are also reintroducing bugs that your organization already spent time and money diagnosing and correcting. He figures you're throwing out years of accumulated knowledge, and history provides plenty of support for that point.

The flaw in the argument is that you don't HAVE TO throw out the knowledge encoded in the old implementation, if you use the legacy code as a de facto repository of requirements and specifications. If you insist on ignoring the old code, then Joel is right. Relying on requirements will fail for two main reasons.

First, you don't have good requirements. If there was an original requirement document, you're lucky. If it were maintained in parallel to the code, that would be miraculous. If you try to get new requirements from scratch, a million things that are taken for granted in the legacy app won't be mentioned; you will go from a mature but ugly product to a pretty-looking v1.0 that frustrates your staff and angers your customers.

Second, many of the bugs you're going to reintroduce are technical issues that won't show up in the requirements. Those bugs showed up in the first implementation because they're common mistakes; you're going to make some of them too, unless you're being reminded not to because you're looking at the steps the maintenance teams have taken to correct them.

Of course, since you're probably porting to a different language or environment, some of the technical bugs in the legacy system may not apply to the new system. (For example, a C-to-Java port won't reintroduce a lot of memory leaks.) And on the other hand, the new environment will offer the opportunity to make new mistakes that the legacy system never faced. To that degree, Joel has a point; but at least those will be new bugs (not reintroduced ones) which might get you some political wiggle room.

The point is, if you're going to write that much new code, you need to do everything you can to ensure you're covering the bases, and that means you'd better make sure you understand what the legacy system does (not just what somenoe says it's "supposed to" do).

Kuba:

I'd be very careful. This seems to be a ground-based tool that manages airplane load and weight distribution. Probably it does other things, too, but Dash 8 is a plane made by Bombardier, PAX are passengers, etc. Maybe the submitter just doesn't have a clue, but the logic for this application is pretty much given by the manufacturer and airline operation manuals. I don't know this particular application, and I have nothing to do with airline industry, but I presume if I could figure it out in one minute, the submitter better ask themselves "should I be doing the job"?

Yes, the application is a WTF, because many such frontline apps are on life support since day one, and all fixes/modifications are done with flames under your feet, and the industry is chronically short of money, yada yada.

But methinks TDWTF is that the submitter seems somehow confused -- he shouldn't be.

I definitely agree. There are things in there that really should be enums (does VB even have an enum, though? You could at least use constants to make things clearer) but the logic doesn't seem that bad. It's testing that the loading of the airplane is valid.

bd:

This must be the US localization as more than half of rules are about being overweight.

Why? They are looking at *CARGO* weight.

Mark:

evilspoons:

A rewrite should only look at requirements, not the hideous old implementation. Throw that code into a vault and only take it out if you install the rewrite and they go "heyyy it doesn't work like it used to". Then you go "well, why did you give me invalid requirements?". Only THEN do you take out the old program and try to see how it behaved, add those to the requirements, and then lock it in a dark place again.

Wrong, wrong, wrong, wrong, and wrong.

A few years back, a JoelOnSoftware column made a pretty good (but imperfect) case for never doing a rewrite at all. The basic premise was that as you are spending a huge amount of time and money on the rewrite, you are also reintroducing bugs that your organization already spent time and money diagnosing and correcting. He figures you're throwing out years of accumulated knowledge, and history provides plenty of support for that point.

The flaw in the argument is that you don't HAVE TO throw out the knowledge encoded in the old implementation, if you use the legacy code as a de facto repository of requirements and specifications. If you insist on ignoring the old code, then Joel is right. Relying on requirements will fail for two main reasons.

First, you don't have good requirements. If there was an original requirement document, you're lucky. If it were maintained in parallel to the code, that would be miraculous. If you try to get new requirements from scratch, a million things that are taken for granted in the legacy app won't be mentioned; you will go from a mature but ugly product to a pretty-looking v1.0 that frustrates your staff and angers your customers.

Second, many of the bugs you're going to reintroduce are technical issues that won't show up in the requirements. Those bugs showed up in the first implementation because they're common mistakes; you're going to make some of them too, unless you're being reminded not to because you're looking at the steps the maintenance teams have taken to correct them.

Of course, since you're probably porting to a different language or environment, some of the technical bugs in the legacy system may not apply to the new system. (For example, a C-to-Java port won't reintroduce a lot of memory leaks.) And on the other hand, the new environment will offer the opportunity to make new mistakes that the legacy system never faced. To that degree, Joel has a point; but at least those will be new bugs (not reintroduced ones) which might get you some political wiggle room.

The point is, if you're going to write that much new code, you need to do everything you can to ensure you're covering the bases, and that means you'd better make sure you understand what the legacy system does (not just what somenoe says it's "supposed to" do).

Bravo. Anyone who imagines that using new or original requirements to rewrite a legacy app is the 'right' way to do it, is just asking for trouble. That kind of thinking will turn what can normally be done with a reasonable amount of confidence and grace, into a stupendous cluster-f*ck.

I mean, sure.. It'd be nice to stick it to the business users and say "well, your requirements are plain wrong, that's why it doesn't work the way you expect" but really.. who are you doing any good for in that case? You're expanding the project life cycle indefinitely. If you're a responsible and well-adjusted person you work with the business to recreate the requirements from the original code as you go, not try to 'stick it to em'.

Let's all try to be human beings here, not jackals.

-Yard

wtf:

Mr Gangreen:

DaveAronson:

Kimvais:

http://en.wikipedia.org/wiki/Bombardier_Dash_8#Incidents_and_accidents

Too bad there is apparently no anchor #Hints_and_allegations.

I don't find that stuff amusing anymore...

The real WTF is the angels in the architecture. What were they thinking? Everyone knows that leads to an endless loop...

Spinning in infinity.

Plz Send the Code:

Rewriting SOUNDS good, but the code has years of undocumented business rules in it that you'll never figure out.

All business rules are documented as VBA-code.