- 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
The real secret is to have the code do nothing. Just output canned, hardcoded data no matter what the input is. At least that way you can avoid data validation and everything else. Just make sure that when you're demo'ing the software, only input what they expect to match the output. That way no one's the wiser....
Admin
The WTF here was not completely destroying the prototype code with extreme prejudice immediately following the demo.
Admin
You did. It's just a prototype, and little to none of it should be used in the final system.
And surely you're not so stupid as to ask me to mix them. You didn't give ME production code. Why did you expect me to give YOU production code? It's not like I was rewriting what you gave me.
Admin
Bingo.
I've done both. They both suck. Even when you can compare, things get squirrelly whenever the client wants to be difficult. He complains "well, my machine at home still can't download any faster" and no amount of explanation will convince him that this isn't in your power to fix. You show him a brand new database interface layer on the latest and greatest control panel, and he pulls up a two year old report and says "well, this doesn't reflect the new databases".
I'm not good at finding reliable and intelligent clients. Once I figured that out, I stopped trying. ;)
Admin
Admin
Menus are UI. If I'm not a UI specialist, I shouldn't be asked to design a menu system.
And that's what I did. He gave me a crapplication and said to build a menu system for it, that it was a prototype, and that little to none of it should end up in the production code. It seems reasonably obvious to me that the menu system attached to a prototype should itself be a prototype.
After all, I haven't been asked to look at the prototype and build a production application. I have been asked to look at a prototype and build a completely new system for it. On what planet is that new system expected to be ready for a production application?
Admin
A bit later, he began to dig beneath the users' perception to understand the purposes of their requirements. It turned out that this alert email was being sent so that its recipient could copy the new input, massage it a bit in an Excel spreadsheet, back it up in an Access database, and send it on to the next person in the process chain.
When the PM informed them that the new application could do all that for them automatically, they were stunned; they'd never considered the possibility. They were thinking in terms of the motions they went through in their present daily work process, rather than what the desired result of that process was.
And yes, we swapped SQL Server for Access, and redesigned and normalized the database.
Admin
Admin
This discussion resonated with me. As contract developers, we have had many discussions about responsibilities in cases like these. Given an obviously short-sighted or incorrect requirement, it seems we can't win:
A) Deliver what was asked for and get an (eventually) dissatisfied client. You can get sign off because you did what was specified, but they will feel tricked, they won't be happy and you feel no pride in the deliverable. It just feels wrong and CYA-ish.
B) Deliver something besides what was asked for, hopefully better and as needed, but risk eating expanded time/budget and the potential that the project is not considered finished because you haven't met a spec.
I would be a rich man if I hadn’t followed path B-- you can make a fortune in bug fixes along path A.
When you see basketball players, they don't look tall around other basketball players, but when the referee walks up, suddenly you have context. By analogy, it would be nice to have multiple implementations of a project. Then there could be context-- i.e. yes, the project has 4 bugs in it, but, hey, by following the spec, there would have been 4000 big problems.
Admin
Seems clear to me that Mr. Q thought his job was to DESIGN a menuing system, not to design AND implement it. Design prototypes are not supposed to be beautifully-coded and fully functional -- just functional enough to test that the design is a good one.
Admin
I tend to agree.
It sounds like someone expected him to design and implement a menu system pinned to nothing.
If someone asked me to create something like an entire menuing system and gave me a prototype I would assume that they wanted a prototype menuing system.
If I was doing prod code there is no way I'd create an entire menuing system at one time. A menu entry would get created when I was wiring up the completed feature. After all, creating/modifying a menu system isn't/shouldn't be all that hard. Making the menu entries do something is.
Given the fact that a senior dev was only able to create the menu prototype in the given time (weeks?) means that either he's not a senior, he wasn't doing his work, or there wasn't nearly enough time to implement anything.
The fact that the devs didn't talk to each other for that period of time is the WTF. Smells like overseas or incompetence on both sides to me.
-blah
Admin
Admin
I think his name is "Mortadelo" :)
[image]Admin
It seems odd to me that some time people need to point that out, as I have sort of taken it it as evident. On the other hand I tend to work on small projects where regular informal meetings with the client are the norm so I assume in a large coorporate environment it might be an issue.
That said, I marvel at how people sometimes can't be bothered to explain their business process to you. It's usually some bitter overworked secretary that can't take it on faith that spending some time explaining things will save her hundreds of hours of work later on. Not to mention that the older an employee the larger the crowbar you need to pry them off their establish wasteful process and show them how to accomplish things with half the effort.
Admin
The picture reminds me of six flag's mascot:
[image]Admin
huuu???...
I often make prototype pages as html with menus like Services | Clients | Technology.
If you want something else for a prototype, you must ask for it.
Maybe David sould have give more information about what whas intended to do with the Mr Q menu. If the whas to reuse on the final product, a warning is needed, so the code quality whas better than in protototype. With not complete information, I see as normal to make some fake menu. It will be usefull the way a prototype is usefull: to show how the final product will look.
Maybe I am Mr Q? :(
Admin
No, Cloak is fed up of that stupid ASP/VB/VBA/VBScript WTFs. Java and C flavors are also a WTF for themselves. Of, course, that guy would suggest PHP (WTF as well). But if you have an MS framework you should probably stay with it and not add another WTF to it in order to get a heterogeneous system. VB flavors do their job quite well in RAD and I wouldn't want to exchange them against something else (except Coldfusion) if a web-RAD solution has to be presented. Only because one is not able to use MS stuff doesn't mean that MS is entirely unusable. People just don't know the language and only see the MS-sign and then say: oh, a WTF language.
Geeeeez.
Admin
No, Cloak is fed up of that stupid ASP/VB/VBA/VBScript WTFs. Java and C flavors are also a WTF for themselves. Of, course, that guy would suggest PHP (WTF as well). But if you have an MS framework you should probably stay with it and not add another WTF to it in order to get a heterogeneous system. VB flavors do their job quite well in RAD and I wouldn't want to exchange them against something else (except Coldfusion) if a web-RAD solution has to be presented. Only because one is not able to use MS stuff doesn't mean that MS is entirely unusable. People just don't know the language and only see the MS-sign and then say: oh, a WTF language.
Geeeeez.
Admin
The REAL WTF is being called Mr. Q
Captcha: Wigwam
Admin
Admin
You might have had a valid point, if the same bullet point you're contesting didn't also say
If the prototype already contained code to make the menu stuff database-driven, how is it acceptable that Q's version after the prototype was hard-coded? Sorry, you're wrong here. There's no excuse for stepping backward in functionality when fleshing out after a prototype has been accepted; worst case is that you end up using the hacked together prototype code instead to maintain the functionality.
Admin
Admin
Funnily enough, today is turning into something similar....
3 weeks ago I asked what was required. They told me. I confirmed it with them, and double-checked to make sure. They confirmed. I started building... I provided interim snapshots along the way, showing the results that had been asked for above...
And today, I get those 4 magic words designed to reduce any dev to tears and alcohol addiction...
"What we meant was..."
Captcha: "SMILE" - hardly!!!
Admin
Did anyone else read the title of this one and assume it was going to boil down to a story about "Option Explicit" not being set?
Admin
This reminds me of a story from an old co-worker. They were working in the auto industry and ordering parts from a Japanese company. They set a 2% (or whatever) part failure threshold. The Japanese company put big red X's on two of the parts to denote that they were the defective ones and threw them in the box with the other 98.
It only took a couple shipments to realize that the red X's were the broken ones and they explained what a maximum failure threshold was to the Japanese company.
Admin
Ironically on that subject, I've met a LOT of people who dislike using Option Explicit. One boss hated it because he felt it was annoying to use (of course the ASP/VBScript code he wrote was also littered with things such as: objMail234 or objConn45, but he admitted he hacked together an entire Classic ASP-based ERP system for the company years ago when it was still new). Wow that was some tough times
Admin
Bottom line: You are being hired for your expertise. If your customer's requirements are not going to yield a functional product, it is YOUR job to inform the customer that these requirements need to be firmed up so that they SHALL result in a functional product. And if you, as a software engineer, have a bright idea to make "a better mousetrap" - then prototype it, demo it, and get the requirements changed to fit it. It's what you're hired to do. It's why we're paid the big bucks.
Admin
Reminds me of a project I once had in the pharmaceutical industry. They wanted to have a quality assurance tracking system. But since they didn't really know what they wanted they let me code the prototype (which made it into production) and when it was nearly finished they wrote the specs according to the capabilities of the prototype :)
Admin
Admin
If I /am/ writing production code for him, why is he giving me code that shouldn't end up in production? He didn't say "make this production ready and add a menu system to it". He said "add a menu system to this prototype". The result is a prototype with a menu system. It's still a prototype. Doesn't it just make sense that the menu system shouldn't end up in production, either?
Admin
Some clarification might be in order here.
The task was to produce a generic menu system to underpin a web-based application.
It was given to a senior, not a junior and a spec was provided. There were gaps but as a senior, they should have had the skills to solve these.
The task wasn't exactly huge - it was about 4 weeks work, where I was on leave for the last 2 weeks.
The main issue was that Mr Q. was paid as a senior but didn't actually have the skills to match the juniors. In the end, another senior developer took over the task and completed it in 2 weeks - working exactly as required.
The real wtf is that he talked his way into a senior position based on a CV that was made up. But that's another story...
Admin
I made the assumption, incorrectly it seems, that such was the situation here as well. I should have read more closely. It sounded to me like junior was parcelling out pieces of the assignment to different people, and we were just focusing in on this particular senior for the sake of the story.
Yes. Given the context of this story, it does. I misunderstood.Admin
That doesn't mean it doesn't work. That means it's full of hacks and shortcuts and poor error handling.
Admin
CDarklock, if I was your boss, I'd fire you for quibbling. :-)
Plus, many of your statements are in direct contradiction to the article. So I'd fire you for lying, too.
For example, you base your arguments around the supposed fact that the prototype was "non-working code". But the article says the prototype did work. If you didn't see the code yourself, what justification do you have to contradict this?
Sure, David said it was a prototype, but that's not the same thing as saying that it didn't work. It was just not as well-designed, extensible, maintainable, flexible and resource efficient as one would expect the final system to be.
Also, there has been some dispute over requirements "bugs" vs. actual bugs. But at least the "missing HTML tags" thing is clearly and indisputably an implementation bug. This guy knew that he was supposed to produce HTML and then he screwed it up. There is no way that the requirements included "output broken HTML", and unless otherwise specified, it must always be assumed that features that are required to be present are also required to be implemented correctly. Even if this is not explicitly stated, every developer must assume this because this is an essential cultural convention in societies where people actually want to accomplish something. If you do not accept this cultural convention, I suggest you move to Bangalore, India, and work for the wages that are customary over there. Many Indians also like being spoon-fed with this sort of information because they have grown up in a hierarchical culture where you are expected to unthinkingly carry out what your superior ordered you to, and only what is explicitly mentioned, without ever venturing to assume the slightest bit of responsibility for your actions. Eventually you will have to move elsewhere, though, as more and more Indians understand that you cannot be successful unless you learn to assume responsibility for your own actions.
Finally, there is just no excuse for taking bad code and making it intentionally worse. Ever. Everyone who disagrees is fired. There is always a possibility of doing this unintentionally, but the things cited in the article require conscious effort. Consciously making code worse is willful sabotage which no employer can accept. Yes, it is also possible that Mr. Q just had very unusual ideas about the "goodness" of code. But this would just go to show that he is not qualified to be holding the title of senior developer.
Admin
If you didn't already know I was right more often than not, you wouldn't have hired me.
But go ahead. Side with the consultant instead of your own developers. It won't impact morale at all.
"If I was your boss," pfft. You're not qualified. Go home.
Sure there is: "The code doesn't need to do that." An English-only interface doesn't need string tables for localisation, and if you have them, you may as well remove them.
A demo can use hardcoded data and styles. Indeed, they are less likely to fail. Furthermore, any HTML tags unnecessary for the browser you use in the demo are unnecessary altogether.
The programmer did exactly the right thing: he reduced the chance of failure, thereby increasing the chance of success. Since he was working on code that was not expected to enter production, that was a larger design goal than similarity to production code.
Admin
Although Homer's car did have many faults, I have often wished that my car had the soundproofed back seat enclosure separated from the driver. It would come in handy pretty often...
Admin
Admin
Once upon a time, there was an interim among us. Interim was asked to create a program that performed task A. When interim told such program was done, she was asked to create a program that performed task B. Later, when interim was asked to show both programs, interim explained that nobody had told her that task A and B were supposed to be performed by a different program, so she had decided to delete the code for the first program and reuse the file.
Admin
Ooh I'd totally forgotten about that episode - that is a very disarming and very easy example which people will know and be able to relate to, I'm using that in future! 8)
Admin
Language barrier?
Admin
Which was easily recovered from source control...
What? No source control?
See, the real WTF is... ;)
One of the biggest problems with interns and other entry-level people is that they are simply flat-out clueless about how work... well, works. I had a contractor working for me that didn't understand the concept of weekly status. I'd ask how things were going, and he'd say they were going fine. I'd ask what his percentage complete was, and he'd say 45% one week and 30% the next.
So I scheduled meetings with all the contractors, small talked my way through the other team members, and educated the problem contractor on how I expected status to work. I showed him a series of invoices to the client, pointed at the "quote" column, and said "that's what we get paid for this feature when it's done". Then I pointed to the "percentage complete" column and said "if he cancels the feature, this is how much of that he pays". After going over a few invoices like this, I looked at him and said "when I ask for your status, YOU are telling ME what goes in this column".
And the light bulb went on, and his weekly status suddenly became useful. Never had another problem.
Usually, people just need to be privately and non-judgementally educated. I don't think this would have worked if I did it in front of the whole team. I don't think it would have worked if I had /only/ called the problem contractor into my office. The primary X-factor in the process was to avoid embarrassing him.
Admin
User: We need USB2 cards installed in all machines. Us: Why? The only USB peripherals we use are mice and they work fine on the old cards. Perhaps you could tell us why you think you need them. [silence for 5 weeks]
IT Director: (Quoting mail the user sent to complain, with !!!!URGENT!!** in the sodding title) Why are none of you installing USB2 cards on their computers? Try to be more customer focussed. [we drop something genuinely important but for someone who doesn't make as much noise. We install the USB2 cards and test them] [silence for three weeks] User: The USB2 card doesn't work. [we test it] Us: Yes it does. IT Director: Why have you installed faulty USB2 cards? Us: The cards work, we tested them. Twice. IT Director: Look into it, and this time get it right. Our, er ... my, bonus depends on meeting the SLA. [we find an ethernet cable, with the plug broken off stuck in the USB port with duct tape and toothpicks] Us: Why have you done this? Users: The plug on the cable was the wrong shape!
Admin
Admin
(Non UK readers will not have a clue what I mean. Sorry)