• Ash (unregistered)

    Comments don't work

  • J. Doe (unregistered)

    Bad Requirements Engineering up front... Yes, Jane probably didn't say anything about her future plans, nor did she expect she would have them in the first place.

    But.

    But Dick didn't poke too much. Nor did he explicitly list exclusions in the contract or req document.

    My experience is that it is usually quite easy to imagine what additional wishes people will probably come up with mid way. The less technologically savvy they are, the better.

    The time invested in clarifying requirements usually pays of in the end.

    Ok, you may argue that you aren't paid for that time - but you aren't paid for fighting the lawsuit in the end, either.

  • Mike (unregistered)

    Amature hacker developer blaming the client for own lack of professionalism.

    So many web hackers like this

  • (cs)

    I'm left with the feeling that something is missing from this story, like the fact that in reality, during the final meeting in Starbucks, Dick pulled his trusty GAU-8 out of his back pocket,[1] and used it to slaughter Jane and lay waste to the interior of the joint...

    Putting a slightly more serious slant on the comment: Dick bears some responsibility for his woes. It was clear almost from the beginning that Jane was not technology-aware, and that the buzzword soup was there principally to feed the government grant-granting machinery. If that wasn't clue enough, the unforeseen and largely irrelevant requirement for videoconferencing should have been the follow-up clue. (There are so many viable solutions for this problem that Dick merely needed to find a way to link one of them from the web site. The requirement is irrelevant because it neither adds to nor subtracts from the main purpose of the site.)

    Also, and perhaps most damningly, Dick made the primary mistake of committing to spuriously-added extra work "against his better judgement". Since Dick's judgement said that the work was ill-advised, then the decision to do it anyway is not only creating a rod for his own back, but actively hitting himself with it.

    [1] Dick wears TARDIS trousers, so he has no problem fitting a 20-foot long seven-barrel Gatling gun in his back pocket.

  • (cs)

    If the leading two-thirds of the "requirements" are actually design constraints from someone who has no business making them, and you still agree to take the job, then you deserve everything you get. Or don't get, in the case of payment.

  • WC (unregistered)

    I'm really sick of this blame-the-victim mentality.

    Could he have avoided this mess? Sure.

    Does he deserve the pain? No. He was clear in everything he did and it was all above-board. He did nothing unethical or immoral.

    I'm sure he learned his lesson and he'll be much more cynical in the future. But he didn't deserve any of it.

  • Ironside (unregistered) in reply to J. Doe
    J. Doe:
    But Dick didn't poke too much.

    Because there are laws against it

  • (cs)

    I can believe this story. Been there and done that...

    We had clear specs - can't be clearer than "don't include <product series xyz>". But apparently what the client actually meant was "make a whole section dedicated to <product series xyz>".

    Also, somehow we were meant to know that he'd stopped selling one brand of product and replaced it with a different one. Didn't tell us at any stage. We were just supposed to know.

  • (cs) in reply to Steve The Cynic
    Steve The Cynic:
    Also, and perhaps most damningly, Dick made the primary mistake of committing to spuriously-added extra work "against his better judgement".
    This depends a bit on the nature of this extra work in my opinion. Being generous with how you interpret a specification can generate you some good-will with your client, who may then be more amenable to paying for the more serious extra work that is bound to crop up sooner or later. After all, clueless people tend not to know what they want, no matter how much you discuss it with them.

    I have a hard time blaming Dick for not foreseeing that his client wanted to "be able to push layout changes directly from photoshop". That kind of crazy, you just can't predict. Moreso because of the premise of the work: get some government money, try to make a quick buck, while being completely clueless as to how the technology works? That sort of thing just never works.

    If you absolutely do have to work for them, then get a concise specification, stick to it, and finish in time - which seems to be exactly what Dick did.

  • RFoxmich (unregistered)

    WYSIWYG - He saw Jane and her lack of ability to understand what she wanted...and that's what he got.

  • (cs)

    I had very similar experience a couple of year back. A guy that knew some of my sisters' friends had recently taken over a small business. He now needed to get the website updated and wanted to hire somebody to help him out. I was low on clients in that time so took the job. However, when he first received an invoice from me, he reacted the same way as Jane. Even though I had been very nice to him and worked the first day or two for free, he still thought it was too expensive (he even got a discount). He sort of changed between believing that I was doing a favour to him and thinking that he could pay me off with a cheap bottle of wine. I explained to him that this is what I do for a living, and i had actually been very nice to him. He wasn't really listening, so I had to 'fire' him. Obviously he didn't have any money, so I didn't get the rest of my money until after a couple of months (and after a few angry letters).

  • (cs)

    Yes, Dick made mistakes. But anybody who's done freelancing has made the same mistakes. I made them! I once tried to help someone build a shell interface to Google AdWords. They didn't really know what they wanted it to do, except that they wanted to script AdWords (and at the time, there was no AdWords API, which meant page scraping). After finally cobbling together something that sort of worked, they rejected the product because it depended on a page-scraping module out of CPAN and they didn't want their code dependent on some third party package.

  • chris (unregistered) in reply to Ash
    Ash:
    Comments don't work
    Why can't I edit this comment??!!
  • (cs)

    That's why you should never ever freelance for people who have no clue what they are into, may they be friends or relatives or whatever.

  • Dam (unregistered)

    I want my comment to have a yellow background, but I can't find the button. Please do it ASAP.

  • ZoomST (unregistered) in reply to chris
    chris:
    Ash:
    Comments don't work
    Why can't I edit this comment??!!
    The right way is: print it out, edit with a pencil, put on a wooden table, shot a photo, and send it back.
  • (cs) in reply to ZoomST
    ZoomST:
    chris:
    Ash:
    Comments don't work
    Why can't I edit this comment??!!
    The right way is: print it out, edit with a pencil, put on a wooden table, shot a photo, and send it back.

    No, no, no. Don't you understand how web 2.0 works? Print it out, edit with a pencil, scan it in, find the "upload" button, upload the scan. Job done.

  • QJo (unregistered)

    The real WTF, of course, is doing business with a woman. Surprised nobody mentioned that.

    Or the fact that I'm a giant, idiot, douche who thinks that "oh, I'm just joking" is a valid cover for reinforcing the attitude that IT is a boy's club. Nobody mentioned that part either, probably because it's obvious.

  • Hewes (unregistered) in reply to skotl

    I'm sure you're mandated to send it back by using a pigeon, and hoping Dick Dastardly doesn't catch it.

    Captcha: Haero, as in I need one. He’s gotta be strong and he’s gotta be fast

  • Wfd (unregistered) in reply to QJo

    We were having a nice time discussing stupid customers and you had to go all sexist?

    Why?

  • b_russel (unregistered)

    I can't help but think the whole disaster is Dick's fault. He's supposed to be a professional software developer, who knows how to gather requirements, design software, develop incrementally and all that. Jane (as far as I understand the story) is not a software developer, so you can't expect her to know much about how to plan a software project or how to gather requirements, right?

    Programming is only a small part of actual software development, but it seems it's the only part Dick's ever heard about. He should have told Jane that...

  • (cs) in reply to FragFrog
    FragFrog:
    Steve The Cynic:
    Also, and perhaps most damningly, Dick made the primary mistake of committing to spuriously-added extra work "against his better judgement".
    This depends a bit on the nature of this extra work in my opinion. Being generous with how you interpret a specification can generate you some good-will with your client, who may then be more amenable to paying for the more serious extra work that is bound to crop up sooner or later. After all, clueless people tend not to know what they want, no matter how much you discuss it with them.
    He committed to doing the extra work "against his better judgement". There must have been a reason his better judgement spoke against it, and he went ahead anyway. While he doesn't automatically *deserve* what happens, he shouldn't be surprised by it.
    FragFrog:
    I have a hard time blaming Dick for not foreseeing that his client wanted to "be able to push layout changes directly from photoshop". That kind of crazy, you just can't predict. Moreso because of the premise of the work: get some government money, try to make a quick buck, while being completely clueless as to how the technology works? That sort of thing just never works.
    Sure, predicting that Jane would want to push layout changes from Photoshop is not going to be easy, but are we saying that he *never* asked her about how she wanted to update the site, either in content or layout? The WTF lies with Dick, if that is the case.
    FragFrog:
    If you absolutely do have to work for them, then get a concise specification, stick to it, and finish in time - which seems to be exactly what Dick did.
    No, it's absolutely NOT what Dick did. He got an over-brief and definitively incomplete specification, and then allowed work to be added as he went. His requirements gathering was (understandably, perhaps) inadequate, and so, therefore, was the specification. Perhaps he finished on time, and perhaps he only managed that because he persuaded Jane to accept schedule changes (in which case, Dick has the Gift Of The Gab, for sure), but that doesn't change the fact that he didn't "get a concise specification, stick to it, and finish in time".
  • (cs) in reply to chris
  • (cs) in reply to Lorne Kates
    Lorne Kates:

    Nice :)

  • Tad (unregistered)

    Dick, you idiot. Don't do business with people who are clearly computer-incompetent, at least without getting paid upfront. They have no idea what they need, want, or will get, and you know this.

    Don't stick your Dick in stupid.

  • anonymous (unregistered) in reply to ochrist
    ochrist:
    I had very similar experience a couple of year back. A guy that knew some of my sisters' friends had recently taken over a small business. He now needed to get the website updated and wanted to hire somebody to help him out. I was low on clients in that time so took the job. However, when he first received an invoice from me, he reacted the same way as Jane. Even though I had been very nice to him and worked the first day or two for free, he still thought it was too expensive (he even got a discount). He sort of changed between believing that I was doing a favour to him and thinking that he could pay me off with a cheap bottle of wine. I explained to him that this is what I do for a living, and i had actually been very nice to him. He wasn't really listening, so I had to 'fire' him. Obviously he didn't have any money, so I didn't get the rest of my money until after a couple of months (and after a few angry letters).

    That's why when dealing with that kind of "contract", I clearly explain the budget conditions so nobody feels deceipted. I should do it for free ? My brother is a plumber and he doesn't expect doing work for friends against a bottle of wine, why should I ? In opposition, I make it clear when I do it for free that I will actually help for free but will do it on my free time.

    When receiving strange emails for help, I also make it clear that there will be a consultency charge.

  • Al R (unregistered)

    Been here myself. Problem is the informal initiation by doing a favor for a friend or relative some of the usual safeguards are bypassed. In a normal set up you make sure all requirements are signed off and clarified with some form design documentation. New requirements result in a formal re-costing process that again has to be signed off. In the informal favor scenario it is all so easy to agree to that little change where is turns out the requester has only told you a tiny part of their (ever changing) vision. Where as a formal business customer will likely have put a lot though in up front as to how they want their hard earned cash to be used, the informal customer is often a person with little tech knowledge who thinks that you can reproduce Amazon and Facebook for them with a few hours effort.

  • (cs) in reply to Steve The Cynic
    Steve The Cynic:
    Sure, predicting that Jane would want to push layout changes from Photoshop is not going to be easy, but are we saying that he *never* asked her about how she wanted to update the site, either in content or layout? The WTF lies with Dick, if that is the case.
    Erm, you did read the article, right? It's clearly mentioned that there is a content editor available in Jane's admin module. So he did ask how she wanted to update the site, and he did provide the functionality to do so.
    Steve The Cynic:
    No, it's absolutely NOT what Dick did. He got an over-brief and definitively incomplete specification, and then allowed work to be added as he went.
    You seem to work on the assumption that, if you paint your client a picture of how it looks, how everything is going to work, and what they will be able to do with the product, then the client will understand what she gets, can indicate what she wants, and will never ever change her mind.

    Sadly, in the real world, this is just not the case. People change their mind, they forget what they wanted, or they are too stubborn to tell you when they do not understand something. This was very clearly the case here (going by the mention of 'video conferencing' suddenly being included and font changes).

    I do not know exactly he precise the specification was, but from what is mentioned, we do know that the client originally wanted XYZ, during the next meeting mentioned wanting ABC as well, and then Dick successfully convinced her that ABC was NOT in the original specification, whereupon she agreed that he would just do XYZ. From this we can deduce that:

    A. The specification was clear enough to limit the product to specific components. B. The client either did not understand the specification which she agreed to and signed off on, or changed her mind despite agreeing to it.

    Not everyone has a clear idea of what they want, and the more vague it is and the more clueless they are, the more that idea is going to change. There is only so much you can clarify with prototypes and mock-ups. You can make a complete mock-up of a webpage, get a client to sign off on it, and then when it is delivered get complaints that it's not what they wanted - true story. If you have never experienced this, than you have clearly never had to go through the whole development process yourself.

  • eVil (unregistered)

    So the client starts off chirpily misusing tech terminology, but subsequently turns out to be a clueless nob who knows nothing about what they're requesting, but still feels entitled to bitch and moan about anything they feel like?

    How is this different from every other web developers problems?

  • JAPH (unregistered)

    Was Jane recommended by Dick's first cousin (twice removed) or Dick's second cousin (once removed)?

  • (cs) in reply to FragFrog
    FragFrog:
    Erm, you did read the article, right? It's clearly mentioned that there is a content editor available in Jane's admin module. So he did ask how she wanted to update the site, and he did provide the functionality to do so.
    Yup, I read that. I'd say that it doesn't actually mean that he asked *how* she wanted to do it, merely that he realised that it was going to be necessary. Perhaps I overlooked that, and should have restricted my comment to updating the layout.
    FragFrog:
    Steve The Cynic:
    No, it's absolutely NOT what Dick did. He got an over-brief and definitively incomplete specification, and then allowed work to be added as he went.
    You seem to work on the assumption that, if you paint your client a picture of how it looks, how everything is going to work, and what they will be able to do with the product, then the client will understand what she gets, can indicate what she wants, and will never ever change her mind.
    No, not at all. And I didn't say anything of the sort. *You* asserted that Dick got a concise specification, stuck to it, and finished in time. *I* asserted that no, he got an incomplete specification, allowed it to be updated, and pushed back the completion date so that although he was late by the original contract, he was not late by the revised work-plan.

    Change management is, as you say, an essential part of the development process, but how to do it is frequently misunderstood. "Adding feature X will cost Y€ and Z weeks" is the essential starting point for discussing specification changes. And you must be able to say "Removing feature A will cost B€ and C weeks because it is already fully built. Feature D is next on the work-plan, so we can remove it from the final product by simply not building it." And you must also say, "Let's haggle over what is included and what is not."

    And last but most, you must get a sign-off on what the original specification is, and what each change is, so that you have a record of it. A smart client will want this as well, so he can point out what is missing. You don't do it to "freeze" the product, but to force the client to put more effort into thinking about what he wants.

    FragFrog:
    From this we can deduce that:

    A. The specification was clear enough to limit the product to specific components. B. The client either did not understand the specification which she agreed to and signed off on, or changed her mind despite agreeing to it.

    "A" isn't clear from the article, and a specification can be clear without being sufficient. If it makes no mention of videoconferencing, and the client wanted that, it remains as clear as it is on other aspects even if it is not an adequate specification for the desired product.

    "B" is a problem, and can only be addressed with difficulty. Forcing the time/money/feature tradeoff discussion will help to a certain extent, because it makes the various things the client wants have a concrete cost.

    FragFrog:
    Not everyone has a clear idea of what they want, and the more vague it is and the more clueless they are, the more that idea is going to change. There is only so much you can clarify with prototypes and mock-ups. You can make a complete mock-up of a webpage, get a client to sign off on it, and then when it is delivered get complaints that it's not what they wanted - true story. If you have never experienced this, than you have clearly never had to go through the whole development process yourself.
    The essential part of this is that you must think about what the workflow looks like, and you must have enough behind the prototype that the client can use it himself. It's best to have some unwarranted fragility in the demo so that it is clear that it is not ready for the small-time, much less the big-time. That's part of the other difficult element of any development process, called "managing expectations". You have to think about what the requested workflow means, and you need to be able to explain the pitfalls of that to the client.

    I once had to write a term paper for a Software Engineering class at university. The goal of the paper was to discuss X and Y and Z[*] about what I learned during the semester, both from the class itself and also from the assignments. I actually felt that these questions were invalid, or at best inadequate, so I refused to answer them. Instead, I explained why I was doing so, proposed an alternative question, explained why it was a more useful question to answer, and proceeded to answer it. I began the meat of the essay with a four word sentence, "Software Engineering is hard."

    Despite refusing to answer the assigned questions, I got an A.

    [*] No, I don't remember what X, Y, and Z were. It was 25 years ago.

  • Paul Neumann (unregistered)

    TRWTF is Dick's wheel building skills. There are plenty of CMS platforms, teleconferencing SAAS and web API's that 90% of his work should have been plumbing. If I contract to have a building constructed and the contractor comes to me at the conclusion to demo the saw and hammer he was able to create, but there is no building then I am going to be quite unlikely to pay him or her as well.

  • trucking foll (unregistered) in reply to b_russel
    b_russel:
    I can't help but think the whole disaster is Dick's fault. He's supposed to be a professional software developer, who knows how to gather requirements, design software, develop incrementally and all that. Jane (as far as I understand the story) is not a software developer, so you can't expect her to know much about how to plan a software project or how to gather requirements, right?

    Programming is only a small part of actual software development, but it seems it's the only part Dick's ever heard about. He should have told Jane that...

    Dick's only REAL problem? "Nonetheless, Dick had done his job, maintained his sanity, and sent Jane a final invoice with instructions for using the administration interface he'd developed." (FTA)

    He might as well have said, "Here's everything you need to run, crazy client. I sure hope you pay me for it."

    You gotta, at least, get some payment before delivering EVERYTHING.

    Captcha: With too many clients like Jane, Dick will need more "luctus" to stay afloat.

  • Valued Service (unregistered)

    You know that commercial with the guy in the suit with a bunch of question marks. No.... not the riddler, has he ever been in a product commercial. Okay maybe a toy. ... I mean the guy that tries to sell the book that supposedly has a list of not-so-well-known government grants.

    Maybe it's a cross reference from a get rich quick book? You know, the one that recommends you stand on the side of the road and beg for money.

    I always wondered what was in those books. Now I know where all these stupid schemes are coming from...

    BTW, those guys publish real working ideas, just long after their successful and no longer work.

  • Steve (unregistered)

    I side with the developer on this one. I know there is always scope creep but some customers just think they can add a lot more features without paying a penny more. They think they can hold the payment hostage in the end if they don't get their way. That's what contracts are for though and that's the developer's job.

  • W. (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    Change management is, as you say, an essential part of the development process, but how to do it is frequently misunderstood.

    "Change management" is something else than what you are describing.

    Basically the issue for self-employed freelance professionals, is that they must learn how to wear many hats. At a normal company, there would be the sales guy to find the clients, the account manager to manage their expectations, a beancounter to send the invoices, maybe a helpdesk for after sales assistance, etc. Doing this all yourself, as well as actually doing the work, means you can sometimes find yourself at cross purposes with yourself :)

  • (cs)

    The moral of this story is: Don't work for anyone who watches Fox News.

  • (cs) in reply to Paul Neumann
    Paul Neumann:
    TRWTF is Dick's wheel building skills. There are plenty of CMS platforms, teleconferencing SAAS and web API's that 90% of his work should have been plumbing. If I contract to have a building constructed and the contractor comes to me at the conclusion to demo the saw and hammer he was able to create, but there is no building then I am going to be quite unlikely to pay him or her as well.
    9/10. Would enthusiastically flame.
  • C-Derb (unregistered) in reply to Steve
    Steve:
    I side with the developer on this one. I know there is always scope creep but some customers just think they can add a lot more features without paying a penny more. They think they can hold the payment hostage in the end if they don't get their way. That's what contracts are for though and that's the developer's job.
    Agree 100%. I'm not sure why so many people think Dick is at fault when 4 months of working with this client is condensed into less 1000 words. Clearly there's more to the story from both sides.

    However, the punchline is an amazing closing argument as to who is at fault. Anyone who thinks Fox News updates their website by clicking save on photoshop is a bigger dipshit that anyone could have ever anticipated.

  • (cs)

    This is why you base contracts on a "Statement of Work." You do nothing more unless you get another contract. Very helpful method of preventing scope creep.

  • tragomaskhalos (unregistered)

    "Rubies and Pearls" - classic. That was your big "awooga" noise, complete with rotating amber strobelight right there mate !

  • Your Name (unregistered)

    After seeing a hilariously terrible one-paragraph "business plan" like that, there are only two valid responses:

    1. "Cash up front", or
    2. "Nope!"
  • Freelancer (unregistered)

    Been there when an uncle-in-law wanted help building a website. Fortunately I knew not to get involved, but I still kept getting asked to donate hours and hours of time consulting. There was even a surprise-addition video conferencing requirement.

  • IN-HOUSE-CHAMP (unregistered)

    Always get everything recorded. Keep recordings online. Make the user describe what she wants. This is the smart thing to do. Tell her, you suffer from memory lapses, so you'll need to videotape the entire proceedings. As and when you want something, you'll playback the session.

    IF THE USER AGREES, GET IN BUSINESS WITH THE USER ELSE IT IS A NO GO.

  • jay (unregistered) in reply to skotl
    skotl:
    ZoomST:
    chris:
    Ash:
    Comments don't work
    Why can't I edit this comment??!!
    The right way is: print it out, edit with a pencil, put on a wooden table, shot a photo, and send it back.

    No, no, no. Don't you understand how web 2.0 works? Print it out, edit with a pencil, scan it in, find the "upload" button, upload the scan. Job done.

    Scan it in? You mean hold it up to the screen and press the enter key?

  • s73v3r (unregistered) in reply to J. Doe
    J. Doe:
    Bad Requirements Engineering up front... Yes, Jane probably didn't say anything about her future plans, nor did she expect she would have them in the first place.

    But.

    But Dick didn't poke too much. Nor did he explicitly list exclusions in the contract or req document.

    My experience is that it is usually quite easy to imagine what additional wishes people will probably come up with mid way. The less technologically savvy they are, the better.

    The time invested in clarifying requirements usually pays of in the end.

    Ok, you may argue that you aren't paid for that time - but you aren't paid for fighting the lawsuit in the end, either.

    I would be willing to put down money that even if Dick had these things (and it's not clear that he didn't), Jane wouldn't have cared.

  • (cs) in reply to QJo
    QJo:
    The real WTF, of course, is doing business with a woman. Surprised nobody mentioned that.

    Or the fact that I'm a giant, idiot, douche who thinks that "oh, I'm just joking" is a valid cover for reinforcing the attitude that IT is a boy's club. Nobody mentioned that part either, probably because it's obvious.

    I'm interested: how is it possible to edit another person's posting?

    I second QJo's comment: the real WTF is trying to do business with stupid split-arses.

  • jay (unregistered) in reply to J. Doe
    J. Doe:
    My experience is that it is usually quite easy to imagine what additional wishes people will probably come up with mid way. The less technologically savvy they are, the better.

    Huh, my experience is pretty much the opposite: the less technologically savvy they are, the more terrifying they are as a customer.

    The people who know the technology may come up with difficult, complex requirements, but they know what they mean and how much work they involve.

    It's the non-techie people who will casually toss in at the last minute that they just took for granted that they could add a new screen by drawing it with crayon on the back of a napkin, holding it up to the monitor, and pressing "insert".

  • jay (unregistered) in reply to s73v3r
    s73v3r:
    J. Doe:
    Bad Requirements Engineering up front... Yes, Jane probably didn't say anything about her future plans, nor did she expect she would have them in the first place.

    But.

    But Dick didn't poke too much. Nor did he explicitly list exclusions in the contract or req document.

    My experience is that it is usually quite easy to imagine what additional wishes people will probably come up with mid way. The less technologically savvy they are, the better.

    The time invested in clarifying requirements usually pays of in the end.

    Ok, you may argue that you aren't paid for that time - but you aren't paid for fighting the lawsuit in the end, either.

    I would be willing to put down money that even if Dick had these things (and it's not clear that he didn't), Jane wouldn't have cared.

    Yeah, that's the catch.

    I remember one project I worked on that had very detailed requirements, spelling out exactly what screens, what data, menus, etc etc in excruciating detail. Then a week after deployment the client came by and described a report he wanted. I started in on, "okay, let's get the details of that and we'll put it in the requirements for the next release". But no, he wanted it NOW. I replied that we had never coded for such a report because it wasn't mentioned in the requirements. And he said that he had not seen a need to mention it in the requirements because -- this is pretty close to an exact quote -- "I just took it for granted that I could get any report I wanted at any time".

    I cried.

  • jay (unregistered) in reply to chubertdev
    chubertdev:
    This is why you base contracts on a "Statement of Work." You do nothing more unless you get another contract. Very helpful method of preventing scope creep.

    I agree, but it's not that simple.

    Me: "I'm sorry, but generating a picture of what the sofa will look like in the client's home, with the ability to drag it to different places and re-arrange existing furniture automatically to make room in a way that optimizes the feng-shui, was never part of the requirements."

    Client: "Yes it is! It's right here! In the contract it clearly says, 'Display a picture of the sofa.'"

    Okay, I made that one up, but it's only different in quantity and not quality from plenty of conversations that I've actually had.

Leave a comment on “Freelance Fun with Dick and Jane”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article