- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Cue the avalanche of "The real WTF is ASP/Vbscript" comments
Admin
I've heard of some military-industrial subcontracts that had this happen. The system had to meet specifications on size, materials, weight, and power requirements, but nobody thought of requiring it to work. You could have filled the box with some lead weights, power resistors, and maybe a fan, and it would have met specs.
Admin
"I didn't know you'd expected to get paid."
Admin
"What do you mean there's no ice? You mean I've gotta drink this coffee hot?!"
Admin
If Mr. Q. was sued, this is the kind of thing that wouldn't hold up in court. There is a reasonable expectation that the thing being produced was also intended to be functional and do what it was intended to do, to a reasonable extent.
Admin
Ohhh, shut up!
Admin
Who is the guy in the picture? I swear Alex must have a library of bad clip art somewhere...
Admin
this Q fellow probably has some close relatives working for my government's civil service. it would explain a lot.
Admin
I have experienced this more than once.
I'm baffled by whatever bizarre thought process somehow gets to the conclusion that I've implicitly asked someone to spend time and money to build something that intentionally doesn't work. (*)
Functionally incomplete is one thing, broken is another.
(*) OK, so I've never asked anyone to build an industrial control system that was designed to cause an explosion, so it could be stolen by international industrial espionage agents who would use it to run a pipeline control system until some predetermined date when it would blow up in their faces. But I would hope that if I ever did ask for such a thing, I'd have to put the "contains difficult-to-detect bugs that make it lethally dangerous to use in 1979" requirement in writing.
Admin
He looks like he's about to spit on me.
Admin
"Well I didn't know you expected to work here"
Admin
What? You want a PRODUCT??
Admin
One of the problems for Dave is that Q is the "senior" developer. So chances are that Dave has to shut up and bite his lip about this. He can complain to coworkers, but in the corporate world, Q's word would be taken over Dave's anyday; especially if he was good at covering his own ass.
I'm not entirely sold on the WTF'ness of the first bullet point. Hardcoding things like menus can be acceptable in a rapid prototype. If you're under a time crunch and know you'll be able to refactor after the client is presented with the work, then this isn't the worst thing ever. Now, if it had made it into production, that's another story entirely.
Captcha: waffles - Mmmmmm. I just had lunch. Wish I had me some waffles right now.
Admin
LOL! The guy in the picture is me. No, honestly... It's from my portfolio on iStockPhoto.com. (Thanks for using it by the way!!) I come here every morning to put off doing some real work and got quite a shock seeing myself on the front page! :D
Admin
"As software developers, we automatically know what our clients want. Even if during the requirements gathering phase the client tells you they want you to zig, you know that they actually want you to zag."
This depends on the client, but in my experience when it comes to complex software clients usually don't have a very good idea of what it is they want, or how it should work because they often haven't thought their processes through nor can they envisage really well designed ways of handling whatever problem they want the software to solve (and they expect you do to that tricky 'problem solving' for them, not to just crank out code). I find this to be overwhelmingly true even for technical clients.
As arrogant as it may sound, while I think it's very important to listen to clients so that you understand their needs then propose a solution based on that (with mock up interfaces, or flow diagrams if it's software without a visual interface) - I think that you should not simply listen to client then go out and then just go and build what they've asked for (unless their requirements are highly detailed and they clearly do know what they are asking for, which is roughly one in hundred clients at best).
Simply building what people say they want verbatim is a recipe for underwhelming, rudimentary software that ends up being frustrating and confusing to use and ultimately adds little value (and that the client is ultimately disappointed with, more often than not). That is probably a fair summary of most software written to fulfill government contracts (written to spec. - specs. which were written by people with little to no knowledge of how to build great systems or great software).
I find developing good solutions is often about really getting to know the clients environment and individual challenges, anticipating problems the client hasn't, and presenting those issues and solutions back to them (with visual cues, such as a mock up of how the solution might effect the interface for the end user). I find people find it easier to immediately see the benefit of a proposal if you can show a direct application of what you are suggesting in a real-world scenario (likewise, it can also make it clear if you've misunderstood what they are trying to achieve).
Most people are not that great at problem solving and so won't have a good idea of what to ask for, many are not that good at articulating what it is they REALLY want (verbally or in writing) and of course people often fail at both because they are just plain lazy (or not that bright).
If you want to build a really great solution (and not just an average does-what-you-asked-for-no-more-no-less solution) then that means taking the lead in designing the solution - and sometimes that necessitates working out that when a client says they want "Zig" what they really want is "Zig, but Zag if $Foo is true, or $Bar is false".
Admin
He probably works for M. ;-)
Admin
This reminds me of one job I worked at where we gave the customer an estimate of the time and money to develop his application. The customer looked over the itemized list and (in all seriousness) asked us to skip all the testing and just ship them the software.
Fortunately, my management was smart enough to convince them to change their minds, although part of me thinks that maybe we should've sent them untested, crashing garbage, and then charge them per-incident support fees (much much more expensive) to fix all the bugs they insisted we not fix during development.
Admin
Righto. It's extremely rare that the client has the slightest clue what would work out best for them. Most likely they're going to ask you to copy the system their golfing buddy uses to run his company. Or just implement their paper system onto glass screens.
What one has to do is try to get the client to step back, and tell you in general what their problems are, only then can you make suggestions on how to attack their problems with the right size solutions.
Admin
The client should not be designing the software. The client should be describing his needs, and we should be the ones who design the software. A client definitely should not be dictating the structure of a menu.
When I think of a client designing the product, I think of that Simpsons episode where Danny DeVito plays Homer's long lost brother, a wealthy automobile mogul. The guy lets Homer design the "perfect car" and the result is a disaster that ruins the auto company. (When a co-worker suggests making software "just like the customer wants," I have been known to show a picture of Homer's dream car on the projection screen in meetings. It's a parable to which people seem to be able to relate.)
Admin
Well, then the question you should be asking is: is your face being used to represent David or Mr. Q?
Admin
Maybe Q thought he was making the prototype (i.e., didn't have to work, etc.) from a semi-working example. Okay, that's a stretch...
One of the better results on a client project I started with the user documentation (comm package add-on programmers' guide). I didn't touch one line of code until the customer signed off on the manual. After delivery, they reported no bugs and requested only one change for a feature they didn't know was needed to speak to the other device.
Admin
The real WTF is ASP/Vbscript
Admin
The REAL WTF is NOT ASP/VBScript, but the fact that a supposed "senior" developer didn't have enough common sense to NOT screw up a prototype and instead made it worse.
Admin
Agree. The Real WTF is that most companies award the "Senior" position based on longevity not on ability.
Admin
Admin
I don't know, but it sure makes things harder to read.
Admin
I like the picture pretty much - just plain text wouldn't be as funny
Admin
Just to play devil's advocate...
"...explaining that it was a prototype only and should be used to get the gist of how the system would operate, though little to none of the prototype code should be used..."
What, precisely, is "it"? It's clear in hindsight that he means the prototype code he's handing over, but was it clear to the developer designing the menu that the MENU was NOT expected to be a "prototype only" of which "little to none" would be used?
Because personally, if you handed me a non-working prototype and asked me to write working code on top of it, I'd think you were on drugs. You'd have to point me at the client so the client could explain "no, really, I'm retarded" and then I'd know what we were doing.
Admin
I have seen similar excuses from other developers. I think these things boil down to the difference between programmers in it for the cash and programmers who simply like programming. I cannot imagine anyone who loves what they do offering up so much needless humility.
CAPTCHA: craaazy ... WTF? Who Told?
Admin
Admin
Regardless, what interpretation of that text leads you to "take what I am giving you and make it categorically worse"? He handed him something functional and got back something broken and messier.
Admin
what part of "little to none of the prototype code should be used" do you not understand? If I hand you a prototype and tell you to write a real product that works like the prototype does, you'd have to be high to interpret that as 'bollow it up some and play minesweeper for a month'.
Admin
Why did you use a picture of that guy out of MythBusters?
Admin
got any old school code lying about? perfect chance to submit it and get paid.
so what if it's assembly for a microprocessor? if it doesn't have to work, just slip it and head out for a long weekend.
just change the college-sorta-appropriate comments, that's all anybody asks.
Admin
I've heard of bank where the SOP is, when writing specs, to place "it must work" right at the beginning. They probably had something like that happen to them to come up with such a policy...
Admin
I think that's the real WTF here. Let's all work in independent silo's and not talk to each other for several weeks, then be shocked when things don't work out.
Admin
This is the reason I caution people against getting a price based solely on requirements and then expecting to get working, useful code delivered for that price. All you wind up doing is spending the rest of your life explaining that things not precisely stated in the requirements are totally obvious and then having to negotiate how much more they will cost.
Admin
I'm going to cut Q some slack. The people I work for are explicit that they actually want my code to work, and it rarely does, so he's one up on me.
Admin
If there aren't any functional requirements, then Mr. Q did exactly what he was asked to do. This is why I hate dealing with non-technical people on technical projects...because non-technical people are usually non-logical too.
I've worked on plenty of web projects where you get a photoshop mockup of the a page, and naturally you ask a question like "What is supposed to happen when the user clicks on this button that says 'Create Account' <points at mockup>?" The answer is inevitably something along the lines of, "Obviously it should create their account."
When you're still a naive consultant in this business, you interpret that answer as, "I don't really care how the account is created, figure out all those pesky details yourself." So you would go and design a whole system and figure out what kind of information a user needs to create an account, how to validate it, and how to persist it.
Several weeks later you would get a phone call along the lines of, "Hey, there's a lot of bugs in the account creation page. I can't figure out how scan a picture of my dog and have the account creation page morph it into a faux-impressionist picture of an 18th century Victorian picnic by the lake. I'm e-mailing you a list of 43 other bugs I found on this page as well. Please can you fix this by lunchtime? My boss wants to see how the site is going and I don't want you to be embarassed if it doesn't work."
The truth is that most clients DON'T KNOW WHAT THEY WANT. There's no such thing as requirements gathering in cases like that. What you're really doing is taking an idea cloud and figuring out the actual nuts and bolts of what the software should do, how the software does it, and how users make the software do that.
Only after you have pieced that together can you even begin to think about your technical design.
Admin
That's why I always have requirements like:
Keeps the developers in check. Sometimes, if I don't like the developer, I omit the first requirement.
Admin
Why is it worse for your non-working prototype to have hardcoded values that can never fail, rather than external dependencies on databases and stylesheets? They're just other things that can go wrong in front of the customer.
The part where you didn't clearly specify whether you are GIVING ME the prototype code, or I am WRITING the prototype code.
Surely you wouldn't give me code I'm not supposed to use, right? That would be STUPID.
Admin
The truth is actually somewhat worse. Most clients:
And that's why I don't work freelance anymore.
Admin
Admin
Interestingly, one of my ex-coworkers sent me an email asking if it was a picture of me photoshopped to contain a bit less geeky glasses than I normally wear. I didn't see any resemblence, so thanks for clearing my worries (of there being a box filled with stock photos of yours truly hiding on some isolated corner of the Internet:)
Admin
Who said it was nonworking? Yeah, sure the DB can go down, but so what? It's a functioning system.
Of course I would - it's prototype code. Surely you're not so dense as to not know the diff between prototype code and production code.
Admin
I thought that the main part of dealing with clients was convincing them that you were competent and that it'd be better to leave design and implementation to the people who specialize in it. Sure it's hard work, but it pays well.
Admin
Ohhh.. apple sauce! The realWTF(tm) is that you dorks didn't just say - "we'll do the bulk of testing in the requirements phase and reduce the amount of bugs that we ship". Amateurs!
Admin
Admin
With that title, I thought the WTF would involve VBscript's "option explicit" statement and the third paragraph confirmed my suspicion. Then you dashed my hopes completely!
At one place I worked, a more senior developer asked me to stop using "option explicit" because it made it harder for him to revise my code.
Admin
OMG. I have that exact strip saved on my work laptop. I put it in meeting printouts when I know the end users I'm trying to gather requirements from have no clue what they're supposed to give me.