• Ryan (unregistered)

    I wish I could wake up to but sunshine, warmth, happiness, smiles, and hugs.

  • my name is missing (unregistered)

    It's government work at it's best - WTF did the WTF do WTF?

  • genitus (unregistered)

    Well, I guess he'd have hit the the magic "Convert this VB craplcation to an ASP web exploit" inside the VB IDE...

  • (cs)

    I used to work with a Hungarian maniac (perhaps the noun is superfluous) who was as technically literate as they come. He'd been a small part of a team producing a disastrous VB4 data warehousing front-end. (It wasn't necessarily the team's fault: the original mandate was for a disastrous VB3 data warehousing front-end. They managed to achieve the disastrous port to VB4 in something less than a year.)

    He was intensely proud of his team. I don't know why; everybody but Gabor was a total imbecile.

    Anyway, we cornered him at lunch one day in the cafeteria and explained that, well, this is the late '90s, after all, and this application should really be Web-enabled (for all the reasons mentioned in the OP). This would take a very long time.

    His response?

    "It's already Web-enabled. All you have to do is target the VB4 build at an OCX..."

    I think this is the solution to your man in the OP's problem.

    PS Damn! Beaten to it while I was typing. Happy days, though.

  • (cs)
    "Our network administrator says our network is already secure, so no need to worry about that. If you can just make those few adjustments I'd like to have this on the web by the afternoon!"

    i hate that - give them a little information and they think they know everything! i've been in sales meetings where our guy doing the pitch has slashed quotes because the new functionality we're providing is "just a row in the database and a checkbox, right? should take 5 minutes"

  • (cs)

    Should've done it in .NET (And I reckon he did, seeing as the automatic resize of form controls would involve a lot of work in VB6 for a feature that wasn't requested): In that case, you can pretty much just copy the code behind the Windows Application and paste it into a Web Application.

  • Anon (unregistered)

    Ok, I really want to know what happened next.

  • Mark (unregistered)

    I loved the 'don't maximize' work-around.

    Reminds me of a story.

    I was overseeing user testing on an enterprise app for a multi-billion dollar corp a few years back. We had about 9 PCs set up in a conference room so we could get testers away from their desks (and their phones) and have them concentrate on testing.

    One of the SMEs who had been on the project for over a year and was directly involved with most of the requirements gathering sessions calls me over to her machine. "I found a bug."

    When she showed me the 'bug' I knew right away that it was built to the specification. I had worked on gathering the requirements for the particular module that she was in so I knew without a question that there was, in fact, no bug. What's more, this 'bug' was nothing more than a cosmetic issue.

    But to be diplomatic, I pulled out the RD and we read the associated requirements together. I think there were three of four requirements relating to the particular element and she and I agreed that all of them were met.

    "But they built it wrong," she insisted.

    Knowing that in the grand scheme of things this was a very small issue I said, "I think what we should do is log it as a new requirement and let the project management team prioritize it from there."

    "No, it's a bug! They built it wrong"

    Here is where my irritation started to bubble forth. I said something along the lines of "It can't be a bug if it is built to the specification. You worked on these requirements and you advised your boss to sign off on these requirements."

    Her response: "Yeah, but if I had known they were going to build it like this I would have given you different requirements...It's a bug."

  • James M (unregistered)

    Who's up for using the terms shrink and deshrink from now on?

  • Haha (unregistered) in reply to Mark
    Mark:
    Her response: "Yeah, but if I had known they were going to build it like this I would have given you different requirements...It's a bug."

    i file these bugs under UNTBS

    User Needs To Be Shot

  • (cs) in reply to James M
    James M:
    Who's up for using the terms shrink and deshrink from now on?

    Go look at some pr0n. That should make those terms useful!

  • (cs) in reply to Haha
    Haha:
    Mark:
    Her response: "Yeah, but if I had known they were going to build it like this I would have given you different requirements...It's a bug."

    i file these bugs under UNTBS

    User Needs To Be Shot

    Sounds like a problem between the keyboard and the chair.

  • (cs)

    You do all realize that installation and deployment are effectively solved problems for "smart client" apps, right? ClickOnce in .NET takes care of everything for you, and even if you're writing in pure Win32/Win64, most commercial installer packages are more than capable of handling automatic updates.

    Of course, if you have customers, or branch offices, or anyone that really needs to work remotely, then yes, it's good to have it on the web (or at least route things through a web service tier so you don't need to screw around with VPNs and database permissions). But the "maintenance" argument is so old hat now, and it's a pretty lame excuse for spending 3-6x the effort on an application with the same features.

  • Patrick (unregistered) in reply to Mark
    Mark:
    I loved the 'don't maximize' work-around.

    Reminds me of a story.

    I was overseeing user testing on an enterprise app for a multi-billion dollar corp a few years back. We had about 9 PCs set up in a conference room so we could get testers away from their desks (and their phones) and have them concentrate on testing.

    One of the SMEs who had been on the project for over a year and was directly involved with most of the requirements gathering sessions calls me over to her machine. "I found a bug."

    When she showed me the 'bug' I knew right away that it was built to the specification. I had worked on gathering the requirements for the particular module that she was in so I knew without a question that there was, in fact, no bug. What's more, this 'bug' was nothing more than a cosmetic issue.

    But to be diplomatic, I pulled out the RD and we read the associated requirements together. I think there were three of four requirements relating to the particular element and she and I agreed that all of them were met.

    "But they built it wrong," she insisted.

    Knowing that in the grand scheme of things this was a very small issue I said, "I think what we should do is log it as a new requirement and let the project management team prioritize it from there."

    "No, it's a bug! They built it wrong"

    Here is where my irritation started to bubble forth. I said something along the lines of "It can't be a bug if it is built to the specification. You worked on these requirements and you advised your boss to sign off on these requirements."

    Her response: "Yeah, but if I had known they were going to build it like this I would have given you different requirements...It's a bug."

    What a bitch.

  • CoderHero (unregistered) in reply to Mark
    Bob:
    I loved the 'don't maximize' work-around.

    Reminds me of a story.

    I was overseeing user testing on an enterprise app for a multi-billion dollar corp a few years back. We had about 9 PCs set up in a conference room so we could get testers away from their desks (and their phones) and have them concentrate on testing.

    One of the SMEs who had been on the project for over a year and was directly involved with most of the requirements gathering sessions calls me over to her machine. "I found a bug."

    When she showed me the 'bug' I knew right away that it was built to the specification. I had worked on gathering the requirements for the particular module that she was in so I knew without a question that there was, in fact, no bug. What's more, this 'bug' was nothing more than a cosmetic issue.

    But to be diplomatic, I pulled out the RD and we read the associated requirements together. I think there were three of four requirements relating to the particular element and she and I agreed that all of them were met.

    "But they built it wrong," she insisted.

    Knowing that in the grand scheme of things this was a very small issue I said, "I think what we should do is log it as a new requirement and let the project management team prioritize it from there."

    "No, it's a bug! They built it wrong"

    Here is where my irritation started to bubble forth. I said something along the lines of "It can't be a bug if it is built to the specification. You worked on these requirements and you advised your boss to sign off on these requirements."

    Her response: "Yeah, but if I had known they were going to build it like this I would have given you different requirements...It's a bug."

    I have to say, I'm rather unimpressed with your story, as your response indicates that you're more interested in completing a spec than fulfilling usability by the customer. Even if the spec did say "X", customers rarely know what they really want!

  • (cs) in reply to Aaron
    Aaron:
    You do all realize that installation and deployment are effectively solved problems for "smart client" apps, right? ClickOnce in .NET takes care of everything for you, and even if you're writing in pure Win32/Win64, most commercial installer packages are more than capable of handling automatic updates.

    Of course, if you have customers, or branch offices, or anyone that really needs to work remotely, then yes, it's good to have it on the web (or at least route things through a web service tier so you don't need to screw around with VPNs and database permissions). But the "maintenance" argument is so old hat now, and it's a pretty lame excuse for spending 3-6x the effort on an application with the same features.

    You've obviously never had to rely on third-party DLLs, have you?

    ClickOnce is another of those Microsoft abortions that fails to recognise that the underlying platform is screwed beyond redemption. (It isn't terribly portable, either, is it?)

    WxS, pooh.

    I've tried to find the blog that helped me cut down a year's worth of effort on this simple task to a mere two weeks (with an ugly installation interface), and I've failed. This one's a good start:

    Tim Anderson

  • ArbitrarilyComplicated (unregistered)
    "It shouldn't do that," Craig said. "It should look exactly like the printed page."
    Is that something they teach people at the Federal Department of Government on their first day? I worked on a few applications (Windows only, of course) for a federal agency and I got the same requirement. Data entry and display forms just *had* to look like the paper form on the screen.

    But wait, there's more! Every office that used the software had their own homemade paper forms, so of course we needed to include a form designer with the software, so they could continue using their arbitrarily complicated, locally generated form layout. (And no, adding standard Windows controls at any given location didn't cover all possible values of "arbitrary").

    It was nice, though, that the people I was dealing with (even the end users) generally knew how to use Windows and do things like change the screen resolution, or were willing to learn. They didn't have a spastic fit when they resized a window and the form resized with it. So I suppose it could have been worse. :)

  • More (unregistered) in reply to CoderHero
    CoderHero:
    I have to say, I'm rather unimpressed with your story, as your response indicates that you're more interested in completing a spec than fulfilling usability by the customer. Even if the spec did say "X", customers rarely know what they really want!

    Couldn't agree more. If you are one of those IT people who says "this is what you asked for, this is what you get" you will never get very far. If there is something strange in the specs (and something that you know the customer would think is a bug) it would be better to sort it out before development.

  • asfafwfeaaw (unregistered) in reply to More
    More:
    CoderHero:
    I have to say, I'm rather unimpressed with your story, as your response indicates that you're more interested in completing a spec than fulfilling usability by the customer. Even if the spec did say "X", customers rarely know what they really want!

    Couldn't agree more. If you are one of those IT people who says "this is what you asked for, this is what you get" you will never get very far. If there is something strange in the specs (and something that you know the customer would think is a bug) it would be better to sort it out before development.

    Nah, that requires thought and talent on the part of the IT person. Better to just whine and snivel to the user.

  • sadrat (unregistered)

    I want to know, what happens to all the paper after data has been entered into a database???? Does it still get stored in the closet or is it destroyed (shudder).

    This is really a scanning application that needs to be set up. There would be very little data entry involved, depending on how scanning applications are set up. Would take a fair amount of work on the front end to distinguish between the type of paper, etc. Then scan the paper into the appropriate application, ensure the index info is correct and your done. Destroy the paper when ever you want.

    There are a number of vendors that have complete scanning solutions (including IBM/FileNet and EMC).

  • John (unregistered) in reply to More
    More:
    CoderHero:
    I have to say, I'm rather unimpressed with your story, as your response indicates that you're more interested in completing a spec than fulfilling usability by the customer. Even if the spec did say "X", customers rarely know what they really want!

    Couldn't agree more. If you are one of those IT people who says "this is what you asked for, this is what you get" you will never get very far. If there is something strange in the specs (and something that you know the customer would think is a bug) it would be better to sort it out before development.

    Sounds like neither of you have had the joy of working on a fixed bid US govt. contract.

  • John (unregistered) in reply to John
    John:
    More:
    CoderHero:
    I have to say, I'm rather unimpressed with your story, as your response indicates that you're more interested in completing a spec than fulfilling usability by the customer. Even if the spec did say "X", customers rarely know what they really want!

    Couldn't agree more. If you are one of those IT people who says "this is what you asked for, this is what you get" you will never get very far. If there is something strange in the specs (and something that you know the customer would think is a bug) it would be better to sort it out before development.

    Sounds like neither of you have had the joy of working on a fixed bid US govt. contract.

    He had no problem making the change. He just had a problem doing it for free. Bugs = Free / Change Request Cost Money. Thus they were trying to get stuff w/o paying for it.

  • (cs) in reply to More
    More:
    CoderHero:
    I have to say, I'm rather unimpressed with your story, as your response indicates that you're more interested in completing a spec than fulfilling usability by the customer. Even if the spec did say "X", customers rarely know what they really want!

    Couldn't agree more. If you are one of those IT people who says "this is what you asked for, this is what you get" you will never get very far. If there is something strange in the specs (and something that you know the customer would think is a bug) it would be better to sort it out before development.

    I think his point was that it wasn't technically a bug as defined by the waterfall (drip, drip, drop) methodology. No doubt there was some bureaucracy that mandated s/he not accommodate the SME and fix it. Likely, there was also a whole slew of pains caused by filing a bug too (punishment for allowing a bug, pride damaged, delayed release).

  • ArbitrarilyComplicated (unregistered) in reply to CoderHero
    CoderHero:
    Bob:
    Her response: "Yeah, but if I had known they were going to build it like this I would have given you different requirements...It's a bug."
    I have to say, I'm rather unimpressed with your story, as your response indicates that you're more interested in completing a spec than fulfilling usability by the customer. Even if the spec did say "X", customers rarely know what they really want!
    I'm all for making the customer happy, so long as I won't receive an inordinate amount of grief for doing so. Some customers are terminally unhappy, or don't know that they don't know what they really want, and those people sometimes leave me no choice but to interpret the spec literally, and be hard-nosed about going beyond it. Maybe that's the kind of company Bob was dealing with here.
  • (cs) in reply to sadrat
    sadrat:
    This is really a scanning application that needs to be set up. There would be very little data entry involved, depending on how scanning applications are set up. Would take a fair amount of work on the front end to distinguish between the type of paper, etc. Then scan the paper into the appropriate application, ensure the index info is correct and your done. Destroy the paper when ever you want.

    I don't think you understand. They had someone who was going to type the data in manually. How can an automated solution beat that?

  • (cs) in reply to Pecos Bill
    Pecos Bill:
    More:
    CoderHero:
    I have to say, I'm rather unimpressed with your story, as your response indicates that you're more interested in completing a spec than fulfilling usability by the customer. Even if the spec did say "X", customers rarely know what they really want!

    Couldn't agree more. If you are one of those IT people who says "this is what you asked for, this is what you get" you will never get very far. If there is something strange in the specs (and something that you know the customer would think is a bug) it would be better to sort it out before development.

    I think his point was that it wasn't technically a bug as defined by the waterfall (drip, drip, drop) methodology. No doubt there was some bureaucracy that mandated s/he not accommodate the SME and fix it. Likely, there was also a whole slew of pains caused by filing a bug too (punishment for allowing a bug, pride damaged, delayed release).

    No, I think his point was that it wasn't a bug.

    Are all of you people pussy-whipped by the illiterate brain-dead testers foisted upon you by upper management?

    Or is it just that you don't recognise the fairly important and essentially trivially obvious difference between testers ("We pay them") and customers ("They pay us")?

  • SomeCoder (unregistered) in reply to More
    More:
    CoderHero:
    I have to say, I'm rather unimpressed with your story, as your response indicates that you're more interested in completing a spec than fulfilling usability by the customer. Even if the spec did say "X", customers rarely know what they really want!

    Couldn't agree more. If you are one of those IT people who says "this is what you asked for, this is what you get" you will never get very far. If there is something strange in the specs (and something that you know the customer would think is a bug) it would be better to sort it out before development.

    Allowing users to change their minds is one thing. Allowing them to file mind changes as bugs is quite another.

    If the user signed off on the spec, that is what they agreed to get. Obviously users don't know what they want but it's your job (or the architect/software engineer's job) to translate what they want/need based on what they say and what they do.

    What if their mind change requires an additional 80 hours worth of work? I surely wouldn't just hand the user that for free.

    If the change request is relatively simple and won't hurt the deadline, go ahead and throw it in to make the user happy. If the change request is an enormous undertaking, you make the user aware of what they signed and agree to do it in the next version.

    I would probably even see if there was something I could add easily in this version to placate them while I work on the 80 hours of change they want for the next iteration.

    I just went through this power struggle at work (with internal groups). The users tried to go over my head to get their changes (at least 120 man hours of work) implemented. Luckily, project management sided with me and I then worked to give them something in between while we plan for the next release.

  • (cs) in reply to asfafwfeaaw
    asfafwfeaaw:
    More:
    CoderHero:
    I have to say, I'm rather unimpressed with your story, as your response indicates that you're more interested in completing a spec than fulfilling usability by the customer. Even if the spec did say "X", customers rarely know what they really want!

    Couldn't agree more. If you are one of those IT people who says "this is what you asked for, this is what you get" you will never get very far. If there is something strange in the specs (and something that you know the customer would think is a bug) it would be better to sort it out before development.

    Nah, that requires thought and talent on the part of the IT person. Better to just whine and snivel to the user.
    Wow, it's the Scope Creep Fan Club!

  • (cs) in reply to James M
    James M:
    Who's up for using the terms shrink and deshrink from now on?
    So you want to hear your wife saying something along the lines of:

    Come ooooon, Honey, deshrink it already!

    shudder

  • Röb (unregistered) in reply to John

    Damn right, the article said it was a COSMETIC problem. The details of the look and feel weren't in that spec by the sound of it. As a rule though little cosmetic changes and tweaks aren't strictly bugs if the thing still works and is usable. If every little cosmetic tweak was done for free at the clients whim then every client ever would just take the piss and the thing would never be finished.

    CAPTCHA: letatio - things that salad fetishists would do!

  • (cs) in reply to FredSaw
    FredSaw:
    asfafwfeaaw:
    More:
    CoderHero:
    I have to say, I'm rather unimpressed with your story, as your response indicates that you're more interested in completing a spec than fulfilling usability by the customer. Even if the spec did say "X", customers rarely know what they really want!

    Couldn't agree more. If you are one of those IT people who says "this is what you asked for, this is what you get" you will never get very far. If there is something strange in the specs (and something that you know the customer would think is a bug) it would be better to sort it out before development.

    Nah, that requires thought and talent on the part of the IT person. Better to just whine and snivel to the user.
    Wow, it's the Scope Creep Fan Club!
    I assume their theme tune is "The Monster Mash."

  • Mark (unregistered)
    CoderHero:
    I have to say, I'm rather unimpressed with your story, as your response indicates that you're more interested in completing a spec than fulfilling usability by the customer. Even if the spec did say "X", customers rarely know what they really want!

    So I should have logged it as a defect against the developer who coded the module to spec? There had already been a fairly intensive effort by the PM team to prioritize the requirements and phase the project.

    Not only would it have been inappropriate to log it as a defect, it would not have served the user's end goal anyway. Logged as a defect it would have been assigned to the development team, who would then have to research it, note that the element was, in fact, built to spec. They would have then rejected it back to the QA team who would have had to research it further and then submit it as a new requirement to the project management team. All the while, time is marching on and launch date is approaching, and of course the closer you get to launch date the less likely a cosmetic change is to make it in.

    I'm all for users getting a system that meets each and every requirement, but that goal has to be balanced against the organization's goals (which in this case included retaining paying customers).

  • asfafwfeaaw (unregistered) in reply to FredSaw

    Psst... It's only scope creep if the system hasn't been implemented yet.

    There was no need to get pissed off at the user. She can call her functionality it whatever the hell she wants. It doesn't really matter. What matters is that it didn't work the way should thought it would. Here are the available choices:

    1. Bitch and snivel that her "bug" isn't a "bug" and that it's something else.

    2. Do your job as an IT person and find out what she really wants, find out how long it would take, try to slot it in somewhere, and charge whoever has the money a boatload.

    Which one do you think gets you further?

  • Mr. V (unregistered) in reply to asfafwfeaaw
    asfafwfeaaw:
    What matters is that it didn't work the way should thought it would. Here are the available choices:

    1. Bitch and snivel that her "bug" isn't a "bug" and that it's something else.

    2. Do your job as an IT person and find out what she really wants, find out how long it would take, try to slot it in somewhere, and charge whoever has the money a boatload.

    Which one do you think gets you further?

    In my company, we tend to see (1) as a prelude to (2) - whatever the person involved really wants, until we agree that a change is indeed a change request (or a bug) there is no change performed in the source code. You know, while we can be expected to fix our goofs after ourselves, there is a certain price you have to pay for being indecisive (as we developers like to be paid for our work - we are greedy bastards, are we not?). There is a certain reason for that: customers often refuse to pay for something that was misclassified as a bug (hey! it's a bug! fix it!).

    While low-risk low-time consuming change requests can be (and usually are) implemented outright, they still get charged for those ad-hoc changes.

    In short: agree on whether it's a bug (free) or a change request (not free), resolve it and collect the money.

  • (cs) in reply to asfafwfeaaw
    asfafwfeaaw:
    Psst... It's only scope creep if the system hasn't been implemented yet.
    Here's a shocker for you: when the system is in testing, it hasn't been implemented yet.
    asfafwfeaaw:
    Here are the available choices:

    1. Bitch and snivel that her "bug" isn't a "bug" and that it's something else.

    2. Do your job as an IT person and find out what she really wants, find out how long it would take, try to slot it in somewhere, and charge whoever has the money a boatload.

    Which one do you think gets you further?

    Why does it automatically become "bitch and snivel" when it's the IT guy, but not when it's the all-uncomprehending tester?

    So those are the only two choices? What happened to "File it as a new requirement, like any experienced project manager would"?

    In my newbie days, I worked at a company that didn't have IT project managers. I was given a set of specs for a project to write a data input application for the Purchasing Department. These specs had been put together during several meetings involving the head of Purchasing, the head of IT, a couple of senior VPs, and a couple of clerks who would ultimately be the end users. One of these clerks didn't see the point of switching from paper tracking to computer tracking, thought the developers were playing games on their computers, and was having to be dragged kicking and screaming into the 1990's. Among other things, she wanted the screen to look exactly the way the paper forms did, even down to having the same size input areas and same type fonts.

    When the application was ready for testing she was the one assigned to do it. First of all, she ignored the testing with the excuse in her mind that she was too busy doing "real work". Then when she got chewed out for that, she came to my desk and wanted to make "a few important changes", which turned out to be things like, "Can you move this input box over here? Okay, now, can you make it wider? A little wider... a little more... okay, now can you bold this header? What fonts do you have available? Let me see what they look like..."

    My boss came by and heard what was going on, and angrily ordered her away from my desk. I then got a lecture on letting the user waste my time with trivialities. "She'll keep you busy for days dragging controls around on the form," he said. "If the application meets the specs, then you're done."

  • (cs) in reply to John
    John:
    More:
    CoderHero:
    I have to say, I'm rather unimpressed with your story, as your response indicates that you're more interested in completing a spec than fulfilling usability by the customer. Even if the spec did say "X", customers rarely know what they really want!

    Couldn't agree more. If you are one of those IT people who says "this is what you asked for, this is what you get" you will never get very far. If there is something strange in the specs (and something that you know the customer would think is a bug) it would be better to sort it out before development.

    Sounds like neither of you have had the joy of working on a fixed bid US govt. contract.

    I am killing myself on one right now!!

  • Franz Kafka (unregistered) in reply to Haha
    Haha:
    Mark:
    Her response: "Yeah, but if I had known they were going to build it like this I would have given you different requirements...It's a bug."

    i file these bugs under UNTBS

    User Needs To Be Shot

    Nah, requirements bug.

  • Sanity (unregistered)

    TRWTF is that it's a WTF with a happy ending!

    Not that I'm complaining...

  • Not quite. (unregistered) in reply to Sanity
    Sanity:
    TRWTF is that it's a WTF with a happy ending!

    Not that I'm complaining...

    I think you may have read the ending wrong.

  • (cs)

    I know I asked for that word to be bold, but I really wanted it italicized.

    I know I asked for that data entry point to be a text box but I really wanted it to be a textarea.

    I know I asked for this page to only insert new records but we really need to update records.

    I know I asked for a time tracking application but we actually need a shopping cart.

  • demon (unregistered) in reply to Mark
    Mark:
    ... Her response: "Yeah, but if I had known they were going to build it like this I would have given you different requirements...It's a bug."

    ...gotta love to argue with woman...

  • (cs) in reply to demon
    demon:
    Mark:
    ... Her response: "Yeah, but if I had known they were going to build it like this I would have given you different requirements...It's a bug."

    ...gotta love to argue with woman...

    Well, I quite enjoy it, yes. It's the sign of a mature mind.

    What makes you think that "she" wasn't anonymised from "he"?

  • (cs) in reply to demon
    demon:
    Mark:
    ... Her response: "Yeah, but if I had known they were going to build it like this I would have given you different requirements...It's a bug."

    ...gotta love to argue with woman...

    Trust me, there's nothing gender-specific about that response.

    Although it does remind me of the old poem...

    And the user exclaimed with a snarl and a taunt, "It's just what I asked for, but not what I want!"
    (from http://nethistory.dumbentia.com/nut14.html)
  • Jeff Bell (unregistered)

    "Fantastic," Sheila said excitedly. "Our network administrator says our network is already secure, so no need to worry about that. If you can just make those few adjustments I'd like to have this on the web by the afternoon!"

    The proper response is "I think we can have a bid ready by next week"

  • noname (unregistered)

    A WTF with a happy ending. Those are kind of rare.

  • Peter (unregistered) in reply to Mark

    GASP - A user not being able to specify all the requirements exactly up front. My god, I've never heard of that happening. The assumption here is that users can communicate exactly what they need, that the business analyst can write the requirements describing what the user said, that the designer made no errors in designing the system to implement the requirements, and that coders made no errors in the implementation.

    It gets very tiresome hearing the continual complaint from developers that they completed the "requirements". The only requirement that counts is whether the software helps the user get the job done. We might argue whether a problem is a bug or a missed feature, but ultimately the users does not care a damn.

  • (cs) in reply to Peter
    Peter:
    It gets very tiresome hearing the continual complaint from developers that they completed the "requirements". The only requirement that counts is whether the software helps the user get the job done.
    What a sweet, wonderful, sunshiny, flowers-growing birdies-singing world you live in, where time and money are of no consequence.
  • (cs) in reply to noname
    noname:
    A WTF with a happy ending. Those are kind of rare.

    Indeed, since this isn't quite one of them - read the ending a bit more closely to see why.

    Hint: it involves how long it would be expected to take to make the system web-enabled.

  • (cs) in reply to FredSaw
    FredSaw:
    Peter:
    It gets very tiresome hearing the continual complaint from developers that they completed the "requirements". The only requirement that counts is whether the software helps the user get the job done.
    What a sweet, wonderful, sunshiny, flowers-growing birdies-singing world you live in, where time and money are of no consequence.
    More to the point, none of this crap should have anything to do with programmers. That's why we have project managers and salesmen. All a programmer should do is to point a problem "upwards."

    Well, that's why we should have them, anyway.

  • Mark (unregistered) in reply to Peter
    Peter:
    The only requirement that counts is whether the software helps the user get the job done.

    Actually, that doesn't matter at all (especially in the short term) if the software helps the business make money.

Leave a comment on “Completing the Circle”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article