The Daily WTF: Curious Perversions in Information Technology

Scarlet Manuka · 2010-08-30 Reply Admin

frits:
Anon:
... a VCR ...
What's that?

It's a Very Complicated Recorder. Hence the trouble that people had programming them.

2010-08-30 Reply Admin

M:
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, 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.

I really wanted to believe this. But I've been maintaining an app written in ASP and Access, and I can categorically say, they are terrible.

Uh, if you're using ASP and "Access" you're not using VBA at all, since if you're using ASP, you're using "Access" for the database engine only, i.e., Jet/ACE, and not using the VBA scripting capabilities.

2010-08-30 Reply Admin

Ben:
Consider, for example, Command 696: a method named that simply because Command1 through Command695 were already taken.

Thanks to MS Access's obfuscation wizard!

So, exactly how would you go about writing a point-and-click application-building system where you let the user create UI components without asking them to name each one explicitly?

You wouldn't do that? OK, that might be a valid design decision, but it might lose you users. That's debatable, of course, but MS decided it would supply default names for the users as a way of being user-friendly. You may disagree, but that's what they decided to do -- what simpler way to do it than this?

And thinking there were 696 command buttons on the form is something only someone who's never used Access would assume. What 696 means is that this is the 696th control added to the form. Open up Access and try it yourself -- add a command button to a blank Access form, and it will be named command0. Add some other objects, then another command button, and you'll see that its number is not command1, but commandN where N is the 0-based counter of the number of controls added to the form since the form was created. Add a text box with a label after command0 and then add a second command button and it will be command3 (1 and 2 being the textbox and its attached label).

How would you design this if you chose as a design goal supplying default names for the controls?

It might seem that the real WTF here would be that the form has had 696 items added to it (removing controls does not decrement the control counter, and there's a hard limit of 700-odd controls over the life of a form). But I just checked one of my older apps (it began life in 1997 and has been upgraded and enhanced signficantly since then), and the counter on it is above 600, so that isn't even what I'd consider a big deal -- it's just evidence of a long development lifespan for the particular form in this particular application.

2010-08-30 Reply Admin

Larry:
TRWTF is yet another language without a while loop.

VBA has a WHILE LOOP, and it did even when it was called Access Basic.

2010-08-30 Reply Admin

Been There:
I think everybody's missing something. Sure, it happens to be in VBA ... which is slightly suspicious in and of itself. The main points to note are:

696 functions called Command1 .. Command 696

No function parameters; just globals

Every "if" lovingly paired with an "else"

Doesn't that sound like generated code to you? It does to me. I strongly suspect there is some godawful "design" document thrown together in an Excel spreadsheet, with a bonkers in-house code generator, behind this.

Still, at least that way there's a design...

Er, no, it's just the default way Access forms work in terms of generating names for controls added to a form. The 696 is just the counter of how many controls have been added to the form since it was first created. Over the long lifespan of an application (I maintain Access apps that originally date to 1996 and Access 2, for instance), a complex form can easily accumulate that number of controls when you consider that every element on an Access form is a control (a textbox with its label is two controls; an option group with a frame, a label and three options, each having a label, is 9 controls), it's not at all far-fetched for the counter to reach 696.

Of course, there's a hardwired limit of 700-odd controls over the lifetime of a form (even if you delete them), so this form would likely need to be recreated sometime in the next few years if it were to continue to be developed.

2010-08-30 Reply Admin

immitto:
"Command###" is the default name for command buttons, so I kinda feel sorry for anyone who has to support an app that contains 696 buttons. ESPECIALLY if it's in Access. And if the original programmer kept the default button names, you just know he probably also kept the default names for EVERYTHING: Form1, Form2, Form3, Text1, Text2, Text3, etc.

Each control type does not maintain a separate counter. The counter is for all controls on the form. So, it's 696 CONTROLS of ALL TYPES, rather than 696 command buttons. With the 700-odd hard upper limit for controls added to an Access form over the entire lifetime of the form (deletions don't decrement the control counter), a form with 696 command buttons likely wouldn't have much else on it.

Callin · 2010-08-30 Reply Admin

Execute Command 696: Kill all the Jedi

2010-08-31 Reply Admin

TRWTF: VB (nothing else really matters)

2010-08-31 Reply Admin

Herby:
TRWTF: VB (nothing else really matters)

They've never cared for what they do.

2010-08-31 Reply Admin

While yes, it's a whole lot of rules and direct error handling / reporting, it doesn't look like it's something unovercomable ('something that cannot be overcome', my engrish suxx). It lists a number of conditions, which can easily be extracted into single conditional rules. The reporting of the errors as well.

aihtdikh · 2010-08-31 Reply Admin

DaveAronson:
Kimvais:
http://en.wikipedia.org/wiki/Bombardier_Dash_8#Incidents_and_accidents
Too bad there is apparently no anchor #Hints_and_allegations.

Thanks, Al! I knew that line sounded familiar, but I couldn't place it myself.

2010-08-31 Reply Admin

@Deprecated:
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.

That reminds me about the worst teacher CS101 EVER*, who not only ditched me about writing a crazy IF-with-no-ELSE but also cut half my grade because of that...

same teacher that once in that class, I asked a question about some code I had done (not that bad) and he stood there...

1 min reading the code 2 min reading the code ... 10 min reading the code

"Hummm, better if you do by my example."

Crap and I thought I was in the class to learn something!!! I learnt copy-paste instead.

2010-08-31 Reply Admin

Ralph:
Our marketdroids are always begging for the app to be "more engaging" and "responsive to the user" [code] If totalload1 > 2000 Then MsgBox "OVERWEIGHT Fwd Shelf ", vbOKOnly Else MsgBox "Good job on the Fwd Shelf! ", vbOKOnly End If

Brilliant!

As for the WTF, it seems a slightly imperfect but frankly real weight and balance app. Those 'magic numbers' are real magic numbers given by the manufacturer.

And as for re-writing from scratch based on the req's document the client gives you, gotta be honest, that doesn't show a lot of real-world experience...

2010-08-31 Reply Admin

The Nerve:

Fixed?

private void command696Clicked()
  try {
  String docName;
  int response;
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 ttload>0 then this code will fail - unless the language you are using automatically sets all uninitialized integer variables to 6.

2010-08-31 Reply Admin

Herby:
TRWTF: VB (nothing else really matters)

Yawn

Cbuttius · 2010-08-31 Reply Admin

So a case of the "look at the code and see what it does" spec. Nothing new, pretty standard in fact and I've had enough of them in my time to work and really cannot be bothered looking at that code to see what it does.

The new approach of "test-driven development", i.e "look at the test code and see what it does and that should give you an indication of what you need to do to make them pass" is perhaps an easier approach but still totally inadequate.

Perhaps approaching "QA" which in most places I have worked means the testing team, although QA isn't equivalent to testing, assuming they have one, can be the best approach because they have the best idea as to what the specification is, and may even be able to give you access to the list of tests they run, from which it might actually be easier to write a spec, which is what you should do before you rewrite, and not just dig straight into the code.

TheJasper · 2010-08-31 Reply Admin

Mark:
evilspoons:
A rewrite should only look at requirements, not the hideous old implementation.

A few years back, a JoelOnSoftware column .... 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.

You are throwing out knowledge if you throw out readable documentation (for which I will accept well written code). Unreadable code isn't years of accumulated knowledge, it's the product thereof. The knowledge itself is already lost if you have to dig in to the (bad) code in order to retrieve especially since the person doing the digging will most likely not be a business domain expert but a programmer.

In fact, this in and of itself could be the impetus for the rewrite. The more maintenance a program needs the more expensive it gets. If you can't let go of your app because of lost requirements which are only in the code then you may well have a big problem. In the future you may be forced to a rewrite because of hardware/software/reality updates. The sooner you stop making poor undocumented code the less painful that process will be.

In the end you have to do a cost benefit analysis. Not only will you give your manager a happy feeling, you may actually learn something. Don't take a position of always rewrite or never rewrite. Both are unrealistic extremes and if you take either position your arguments will tend to be stock answers rather than suited to the situation.

2010-08-31 Reply Admin

++1

100% endorsed. Rewriting is a skill to be learned.

As a strategy, it is far, far safer to repeat the existing implementation bugs-and-all than to start again from a (figurative) blank sheet. Because when it comes to testing, you know whether you've done it right - because the new program matches the old one.

During the development phase, you are going to be able to make a note of all the bugs you encounter along the way and it may well be worth your while correcting them. In which case, you document this in your test cases: "This won't work the way it used to because I've fixed the bug."

Believe me, I know - I've made a lucrative career out of successfully bringing legacy apps into the modern world.

2010-08-31 Reply Admin

Callin:
Execute Command 696: Kill all the Jedi

I have modified your command to check the loadout of passenger aircraft, pray I do not modify it further.

frits · 2010-08-31 Reply Admin

iogy:
Herby:
TRWTF: VB (nothing else really matters)

They've never cared for what they do.

I never cared for what they sayeye.

Kuba · 2010-08-31 Reply Admin

Arkamis:
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.

But there are situations when whatever data this application comes up with directly determines the safety. It is an important part of a series of redundant checks. I'd say it's safety critical.

Kuba · 2010-08-31 Reply Admin

Mark:
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 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).

I agree with Joel here. It's better to refactor stuff. When done right, refactoring can uncover latent bugs -- that's my experience with my own code, at least. Even refactoring this code would not be that hard. One has to make sure to have relevant operations manuals handy. That would also be a good time to ensure that, say, manufacturer's airworthiness directives etc. that may modify the manual are tracked and make their way into the code.

Cbuttius · 2010-08-31 Reply Admin

The sad fact is that the easiest apps to rewrite are the ones that are written well, i.e. nicely modular with low coupling so you can rewrite one module without breaking too much else, and nicely clearly written so you can see exactly what it does.

However those are pretty much the apps that don't need rewriting because they are nicely maintainable.

The ones that you want to rewrite are those that it is hardest to do so.

A lot of the time it is also preferable to rewrite in the same language as the original, i.e. rewrite a badly written C++ app in C++ rather than moving to Java or C# because they are "cool". With regards to VB I don't know how well VB mixes with C# on .NET, assuming that is now the way to go but being able to rewrite a bit of your application whilst maintaining the rest for now is better than rewriting the whole thing.

There is for me usually a 7-stage phase to a rewrite, i.e.

Isolate the section to be rewritten
Create an interface to this section the way you want external parts of the system to call into it.
Write an implementation to this interface that forwards everything on to the existing legacy code.
Get other external code to use your new interface as a "plugin"
Document this and write the tests for it, assuming we don't have any
Write the new implementation code, also to the interface
Get the external code now to use your code.

Assuming the tests all still pass the job should be done.

And the great thing is that there is a very simple rollback step in the case of a bug, you just roll back step 7. As long as the external code is not using your implementation you have more time to test and fix it. The old code is still there but can be removed at a much much later stage.

2010-08-31 Reply Admin

Bill This:
jkupski:
(... the center of gravity of an aircraft must not be too far forward, nor too far aft, else you end up with something that isn't controllable). Really, I don't think there's anything wrong with VB6 here
Yeah, because an uncontrollable aircraft is not such a big deal.
We've been telling you for a quarter century: you can't rely on MS-based software. Not when it really matters. And, with the possible exception of luser desktops, it usually matters.

When 154 people die because an "ancillary" system was running WinBlows (http://www.networkworld.com/news/2010/082310-trojan-blamed-for-spanish-air.html?hpg1=bn) it's time to start lining people up for execution. And I don't mean the multithreaded kind either. Seriously! It's either premeditated murder or capital negligence. No more Mr. Nice Guy!

Ya, screw blaming the root cause, there's a software company we can lynch!!!!

2010-08-31 Reply Admin

Bill This:
jkupski:
(... the center of gravity of an aircraft must not be too far forward, nor too far aft, else you end up with something that isn't controllable). Really, I don't think there's anything wrong with VB6 here
Yeah, because an uncontrollable aircraft is not such a big deal.
We've been telling you for a quarter century: you can't rely on MS-based software. Not when it really matters. And, with the possible exception of luser desktops, it usually matters.

When 154 people die because an "ancillary" system was running WinBlows (http://www.networkworld.com/news/2010/082310-trojan-blamed-for-spanish-air.html?hpg1=bn) it's time to start lining people up for execution. And I don't mean the multithreaded kind either. Seriously! It's either premeditated murder or capital negligence. No more Mr. Nice Guy!

Ya, screw blaming the root cause, there's a software company we can lynch!!!!

Schol-R-LEA · 2010-08-31 Reply Admin

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

Nahh, it'll be a spaceship that looks exactly like a DC-8, dontchaknow. Filled with nukes and the freeze-dried souls.

2010-08-31 Reply Admin

Cool! A weights-and-balances application for a DHC Dash 8 - written in VB6...with, um, "minimal" error handling...and questionable numbers?

Just one question - which airline uses this thing...and how do I manage to NOT fly with them..?

Ol' "...can you say 'center of gravity'? - I knew you could..." Bob

2010-08-31 Reply Admin

justsomedude:
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.

Doing useful things in VBA is a very difficult chore even for an advanced programmer with five tabs open to the documentation. Part of that is due to Office's ugly API, but the structure of the language doesn't lend itself to structured programming. I've had to start in VBA several times - writing COM in C from scratch is hell, even in C++ without MFC it's ugly. In VBA it's all behind the scenes, at least, but in exchange you give up the ability to use useful OS and dll APIs that VBA poorly reimplements without great contortions (I have a good sized library full of contortion-wrappers now), and the language has never been extended to use even one useful vbscript/vb.net feature. It's no surprise that VBA lends itself to buttugly code, and if Office would include a VBA.net with a more than half-baked IDE, they could actually learn themselves some good practices instead of wallowing in "this makes no sense so I'll hack it any way I can" land.

The one and only feature I like about VBA is named parameters. Now that every language but C/++ has them, it's not so unique. (Yes, I know Pascal had them before.)

2010-08-31 Reply Admin

Jay:
Yes, the function name is stupid. I'm not sure if the variables with names like "Frame500" are referring to field number 500 on an input frame object, in which case that's a really dumb name, or if this is Dash 8 airframe style 500, etc, in which case they would be very good names. "pax" is pretty obviously an abbreviation of "passengers", and "loadtot" et al aren't that tough to guess.
All told I'd say this is a moderately well written module. If this is the worst you have to deal with, you don't want to apply for a job at my company.

I think "pax" is standard airline lingo for passengers. It's not unreasonable to figure that the person doing the programming knows the field and uses the standard lingo of what they are writing about.

2010-08-31 Reply Admin

The Nerve:

Fixed?

  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  
  }

Why not an else if on that second test? The conditions are exclusive, and the testers will thank you for removing an impossible path if they have to meet a path coverage metric. Or at least not curse you for leaving it in.

2010-08-31 Reply Admin

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

More distressing I find the assumption, that nearly each boolean expression found in the above function is the direct result of an before made error with painful consequences.

SQLDave · 2010-08-31 Reply Admin

Satanicpuppy:
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?)

Or CICS. <shudders>

Schol-R-LEA · 2010-09-01 Reply Admin

Kuba:
Mark:
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 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 someone says it's "supposed to" do).
I agree with Joel here. It's better to refactor stuff. When done right, refactoring can uncover latent bugs -- that's my experience with my own code, at least. Even refactoring this code would not be that hard. One has to make sure to have relevant operations manuals handy. That would also be a good time to ensure that, say, manufacturer's airworthiness directives etc. that may modify the manual are tracked and make their way into the code.

We have to consider just what is meant by 'rewriting' in this context, however. That term is often (mis)used as a synonym for 'refactor', which appears to be the case here - otherwise, why would the author of the new code be digging through the old code, rather than working from a new specification? I may not be a formal refactoring in the strict sense, but it sounds like that's really what is going on here.

2010-09-01 Reply Admin

So this is cargo cult programming...

2010-09-01 Reply Admin

junior:
Mark:
Many programmers don't bother to change the default name, even though you almost always should.

That's procedural programming - not visual programming.

Why would you want to change the default name?

You want to change the default names because the code is still code, and no matter what visual framework you have to tie it together it still needs to be readable standing on its own.

Sure, when you approach the Command696_Clock method by navigating the UI to the button and asking the environment to show you the code behind it, you know by context what Command696 is - "why, it's the submit button for this form that I just navigated to".

But when that code refers to Frame123, Radio592, and Form37.Command42, suddenly things don't look so great for your poor maintenance programmer. Yes, he can probably navigate the UI to find those things; and indeed there are some features of the environment that will help him do so. But there is no reason he should have to do so.

There is no such thing as "visual programming" as an alternative to procedural programming. "Visual" describes the development environment; "procedural" describes the code. (Actually I think MS uses some half-baked term like "object based" as a concession to the fact that although they want to call it OO, it really isn't.)

Actually, that's moot anyway; what makes you think proper naming would be peculiar to procedural programming?

2010-09-01 Reply Admin

Not sure what the prob is here, other than the empty ELSEs. Assuming that all those checks have to be made, then they have to be made. I don't see anything redundant or unnecessary (albeit, I only gave it a quick scan.)

2010-09-03 Reply Admin

"On that note, VB has a bad wrap less becuase of the language, and more because of its accesibility."

As a scientist, I had to maintain code written in Labview and I can tell you it's even worse. National Instrument has spent years advertising that Labview does not require any programming skill. Combine that with the impossibility to add meaningful comments to Labview code and you have the best recipe for success.

Eternal Density · 2010-09-06 Reply Admin

This code is a beautiful thing.

-when compared to SSDS.

2011-09-11 Reply Admin

You sir are an arrogant ass. I suppose your code is perfect. Right. It isn't. Jerkoff

2012-03-06 Reply Admin

TRWTF is that you're reimplementing by hand, something that looks code generated.

Command 696

Leave a comment on “Command 696”