A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I am now working with the company that Muppet definitely labeled "worthless" - even getting paid.
The general nature of the job is to perform triage on an orphaned Delphi application that the past programmers want no part of.
Laced throughout the code, I am finding, are WndProcs and message handlers. For an ordinary data entry application.
You see sh*t all over the place like
result := SendMessage(hwnd,WM_SCRATCHMYASS,...,...);
In general this stuff is used only to create artificial, never-leveraged layers of unused abstraction around library components. Little ghettos of useless SDK level coding in what is otherwise a reasonable Delphi app.
The debugging problem with this is that: you can't easily trace through these calls, and the linker is no use in enforcing the construction of code. As an experiment I removed one component from a form, it built OK, but the program failed. If coded using a more normal method call technique it would have failed at link time.
All I can surmise is that: some terrifically egotistical prima donna with Win32 SDK experience from the university decided that: Delphi's built in component/method model wasn't good enough for him - that only idiots use anything built in - and that he would showcase his leetness with the garbage I am dealing with now.
Bitch-slapping, public humiliation, and firing are all acceptable remedies for this kind of thing, IMO.
And how is an employer to know that they have an idiot who does stuff like this at work for them?
"Bored" maybe should be "bitter" but it sounds justified. Does this explain why the Steve McConnell's of the world are so big on code reviews?
I wonder where Joel Almighty stands on that one. I wish we used code reviews, but everyone balks at the suggestion.
"I wonder where Joel Almighty stands on that one. I wish we used code reviews, but everyone balks at the suggestion."
Code reviews might not be necessary if you had shared ownership of the code (an XP suggestion). That is, if everyone owns and can look at the code you might be able to keep idiots from putting in stupid crap. Formal meetings are not required.
However, I did work for a company that did formal code reviews (for good reason: COBOL) and it was very enlightening. Those were the most useful meetings. And nobody, ever ever, got out without having to change something.
==> I am now working with the company that Muppet definitely labeled "worthless" - even getting paid.
Congrats on the new gig. Maybe?
==> result := SendMessage(hwnd,WM_SCRATCHMYASS,...,...);
Didn't know that one existed! <grin>
Is there a WM_GRABMEACOLDBEER too (?) -- 'cause you'll be needing one real-soon-now.
==> Bitch-slapping, public humiliation, and firing are all acceptable remedies for this kind of thing, IMO.
I missed parts of the other thread. Did the offending party abandon the project, or whas he fired?
==>And how is an employer to know that they have an idiot who does stuff like this at work for them?
Unfortunately, most of 'em will never know until someone like you comes along and takes an in-depth look at the code. My experience (I've worked on a couple of these "triage" projects) is that it's difficult to convince them of your concerns. They think you're just bashing the previous employee/contractor.
Wednesday, September 08, 2004
"You see sh*t all over the place like
result := SendMessage(hwnd,WM_SCRATCHMYASS,...,...);"
That really is shit, because of the propensity of SendMessage and other Windows SDK calls to hang under various conditions. No doubt the libraries he's bypassing have a lot of well-tested code that account for those issues and the myriad subtleties of Win32 programming.
I wouldn't be surprised at all if the application has tons of hoary heisenbugs from misuse of the Win32 SDK.
And at bottom, this programmer has displayed a remarkable lack of business sense. The developers of Delphi spent hundreds of thousands of dollars on his behalf developing libraries that wrap Windows, and he's decided to forsake it. It's throwing away money at its finest.
How to catch him?
I think this problem is just always going to be endemic to small businesses that are run, primarily, by businesspeople who don't understand software. In a company with established technical leadership and mentoring, it's obvious because there's a certain amount of "crawling through your shorts" (code reviews, source control, and daily builds) that goes on. Such activities are impossible in the environment you've described.
Wednesday, September 08, 2004
I have "enjoyed" many such tasks and though tempted to bore you all witless with warstories. I'll simply suggest what you are seeing is the spoor of the lone wolf jack-of-all-trades journeyman programmer who is trying out everything he's ever read or thought about on the task at hand.
How to ... ?? Hit the forums. Forums vary. Not all offer the remarkably effective advice available to any who ask this board. So you'll get "Why don't you ...?" as an answer, and the poor loon does so.
My grandma asked me as I was tackling some tiling in her bathroom whether I'd ever done any tiling before, On hearing "no", she sniffed and remarked "Trying it out on the cat, eh?" She knew what she was getting. It comes down to knowledgable inspection.
Small business is utterly defenseless against the shonks and not all shonks hunt alone. Some of the worst code I HAVE EVER SEEN was supplied by a wellknown multinational TLA to a small client, and would have cost much more per line.
So clean it up and get it working and heck, you may gain a reference site and even some repeat work to put on top of a straightened foundation.
Thursday, September 09, 2004
So Bored, we feel your pain. But calling this guy names and puffing your chest out on this forum is venting, it isn't a way forward.
Sometimes message passing is a useful abstraction. Often not. From the way you paint it, it seems in this case misguided. Did you paint it fairly? Probably.
Are you going to rip it out, work around it, vent more, or ignore it? Do you need to care about this? Do any of these messages cross your problem space?
i like i
Thursday, September 09, 2004
"Code reviews might not be necessary if you had shared ownership of the code (an XP suggestion)."
I can't disagree with that entirely, but on the other hand, I have consistently observed that the best systems are the ones where one or two people take a strong interest in / ownership of / pride in the code. Over and over I have seen great systems stray toward chaos as more and more people who are less and less close to the code start to tinker with them.
The stuff I mentioned is only a tip of the iceberg. The dynamics of this company are: the owner is a scientist who probably denigrates user interfaces as trivial. And they do buy on cheapness; they picked college students for implementation, who apparently decided to play because they weren't being paid much nor were supervised.
From the start of my dealings with them, they downed the section I'm working on as "just" a "simple" UI. The next big lump to deal with will be resuscitating their Installshield project to create an installation for this stuff. Nobody there knows s**t. It's propellerhead "we don't want to know about that icky product stuff" heaven.
AKA: if it's so trivial, "professor", why do you need a hired gun?
I'm not blaming the kids who developed the stuff, exactly. Unsupervised, unaccountable kids will play. The company is exceptionally poorly managed by very smart people who are in over their head due to academic arrogance and now they must pay through the nose for my time.
There's different ways of doing code ownership to. In the XP model, it's all open for anyone. In my experience, anything (code, a task, an action item) that isn't owned by just one person is as good as unowned.
I think a better model is that if you own something, only you make changes. If a bug is tracked to it, you have to fix it (unless it passes out of your realm). This has a tendency to reduce the pain that poor programmers introduce because they are kept busy fixing their own problems rather than making new one.
Thursday, September 09, 2004
This also happens when the person was an expert at Win32 C coding but nothing else. So, when he looks at OOP code, he can't understand how the app can operate without WndProcs and SendMessage. Under pressure (or being unprofessional or being lazy), he adds his own WndProcs and SendMessages and never learns OOP, making the program a C-style Delphi program.
I saw this happen with an MFC program, once upon a time where the person constantly bypassed message maps using custom WndProcs because he simply didn't understand that that's what message maps are for. Of course, management was hands off: "We don't care about the code as long as it works."
Friday, September 17, 2004
I think a real professional should adapt to the ways of the tool that he is using, so long as the tool is proven and standardized.
The unprofessionals, the hacks, and the idiots I've had to work with or pick up the pieces from are the ones who believe that they can out-think an entire commercial class library. This type tends to write huge, bloated applications because they refuse to believe that someone else had a deeper understanding of the solution than they do.
In the end, it's programmer ego.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz