Advice on doing business with non-programmers.

Question

Real world scenarios (here "you" means "I") :

1. You are doing undergraduate "research" (in reality programming) for a theoretical CS professor who is a lousy programmer in general, let alone in the language that you will be using.
2. You are trying to help a friend with an IT aspect of his/her startup idea.
3. You are trying to pick up a programming gig on craigslist while in-between jobs.

Things that these people actually say:

1. The math is all done, you just need to add some GUI codes to it. I think that you just need this class and that class and ... shall will meet in two weeks?
2. Hey Hamish, here is a web site that I like. How difficult/long/much would it be for us to make something like that? Or ... hey take a look at this product. It is not that fancy; they just added GUI to it and made a website with some pretty graphics. I think we can make something similar or better in Visual Basic quickly.
3. I looked at your resume and I must say Wow! It will probably take you like 30 minutes to do this. Here, I attached two excel sheets with 15 pages each. The data is all in there. I need to keep it as it is but just put it all on the same sheet so that it is all right there in front of you, you know what I mean? What will this quick job cost me?

I can think of several ways to communicate back:

1. (wrong) "Yeah, let us meet in two weeks" (only to leave that next meeting with an "oh sh!$" face).
2. A) Use scare tactics to set their expectations right - "Well, a good web developer makes 100k per year, and there are usually several people on the team, and good graphics designers are really hard to find, and outsourcing is an option, but is very risky, and most places ask for a very detailed spec that you need to sign, or else they will not make it for you, and that means we better start drawing exactly what we want the page to look like." B) Imply that they suck at programming - "You know, back when I took that VisualBasic class I though I was God and that I will moved mountains, and after X years of coding full time I look back with a smile and realize how much I sucked, and I bet my senior colleagues still look at me with a smile and think that I suck. Just imagine what a difference there is between two classes of programming and 20 years of experience. There is a reason why some contractors can pull up to $200 / hr.". C) Try to quit = "Look, I took up this work thinking that I would be done by now but boy did I underestimate - I cannot even quantify what fraction of a percent is already complete. You know, feel free to just take what I have and find someone who is better at this stuff. I will not charge you a cent. I have been skipping beach on the weekends too much lately, and sorry, but I do like chilling now."
3. Give a high (but realistic, given uncertainty) estimate that is surely going to make their jaws drop.
4. (Desired) Find a way to manage the expectation of this non-programmer person carefully in such a way that they do not think that you are a lazy slob or charge orbital fees.

Have you ever been in these shoes and actually manage to make things work out? Please share what you know.

Answer 1

In my experience, most non programmers have no idea about the detail that goes into any non trivial production software.

Take a look at the project as presented and ask the "client" several questions about it, things that you will need to know in more detail before you can even start estimating the work.

This would normally be a good start to explain to the "client" that things are not that simple.

Answer 2

Yes, I have been in those shoes, especially where "research" is concerned. My take on this is a vast sea of "it depends".

If you are being asked to undertake a programming project in the capacity of researcher for your school, expect to have to follow funding guidelines that are relatively strict and set out by your faculty. You might not be able to expect the same compensation that someone in industry receives for the same job, but that doesn't mean that this sort of endeavour is a bad idea. As an undergraduate with little to no experience, anything that you can use to grow your résumé is a positive.

Especially if you're a student, be very careful with your time management. You need to develop an understanding of how many hours per day you require for studying and the general upkeep of your life (exercise, food, friends). Don't over-schedule yourself, even if the client is pushy when it comes to deadlines.

Regarding your "A", I wouldn't try to "scare" the client, but I would certainly acquaint them with reality. Yes, a good web developer may make $100k/year, but you can't expect to jump to that sort of figure right out of an undergraduate degree. Regarding "B", you certainly shouldn't imply that your client is somehow stupid or incapable, even if you suspect that that's the case. All of your assessments should be based on reality. If your client proposes a project, find a similar project on the internet and show the number of developers, the amount of code, and the amount of time that it took to be developed. Regarding "C", if after discussing everything with the client, their expectations and their budget do not match, or their requirements do not match your schedule or your budgetary requirements, then yes, refusal to do the job is an option. In an ideal world, and if you've done enough planning, you shouldn't find yourself in the middle of a job and needing to quit; of course, this isn't an ideal world.

Many of these issues can be addressed with the construction of a properly thought-out contract. Any significant project such as this should be governed by a legally binding contract that has been agreed upon by both you, the developer whose services are being provided, and the client, who needs the services. Such a contract includes these terms:

• Recompensation - how much you need to be paid, and how: By the hour or as a lump sum? Weekly, bi-weekly, or at the end of the project?
• Scope: what, as EXACTLY and as SPECIFICALLY as possible, you are to do for the client. Scope creep can be the death of a project.
• An outline of the schedule of development, testing and deployment.
• A clause describing what to do if this contract needs to change, describing that such changes need to be mutually agreed upon by the contractor and the client.
• A termination clause that specifies exactly what happens and who pays who what if the contract is to be terminated prematurely.

More often than not, your school will have a career services office that should be able to help with the design of such a contract. Above all, your interactions with the client should be grounded on reality and previous experience (whether your own or that acquired from historical projects), respect for the client, and respect for yourself.

Answer 3

Could a "Baby Steps" approach be used here somehow? That is to suggest in the beginning that you'd meet more frequently to help get down some basics and understanding so that things aren't going way off the rails early on. At least in the first couple of cases I would highly suggest this kind of approach as if you don't communicate for 2 weeks, there could be a huge amount of changes coming and someone has to manage this kind of thing.

My general idea with the "Baby Steps" approach is to try to crawl a little before trying to run and thus get a feel for how this would work. While the other side may not know there is so much stuff to do, this is where there is some educating to my mind as some people may not mind if the app crashes horribly because someone enters an X for a number while others may want all kinds of safe guards. In the case of a job, this is basically doing that simple problem to show all of the following:

1. Yes, I can write code. See?
2. Yes, I do know about edge cases and basic testing.
3. Yes, the vagueness here led me to make a few assumptions to actually have the prototype I do for you.
4. Yes, I do communicate. See here, here and over here?

...

Answer 4

Frankly this is all pretty simple.

Most people don't know anything about these problem domains, just as I know nothing about plumbing for example. What I view as being a simple task, say get my sink so crap isn't coming out of it, may intact be quite difficult. In dealing with a good plumber I expect them to give me a cursory description and an honest estimate. If its more than I am willing to pay, so be it. Programming is really no different.

In otherwords, be upfront about the costs and realistic timeline estimates and if it doesn't happen that simply saves everyone's time, emotions and effort. Plus don't be a arrogant prick, enough people have a deservedly negative opinion of people in our profession, don't contribute to it. You can easily make a lucrative career out of being a sociable interface between technical and nontechnical worlds. Your career prospects or chances of repeat business are ten fold that of the antisocial locked in a closet coder type.

Lastly to the know it all customer types, this is by no means a problem confined to programming. Still be honest and accurate with your estimates and everything should work out. That said, if you don't think you can work with a client walk away. People so often feel obligated to jump at every opportunity while often its in your best interest to stay away.

Lastly I mention the old saying.

How much to fix my computer?

50$ per hour. 100$ if you want to help.