I am a fairly new developer. Professionally I have programed in C# for two years as an intern and 6 months as a junior developer. A friend of my family needs help with a project that is written in VB.net. I have never used VB.net, so I am a little worried there.

But, the real question comes in the fact that once I looked at the documents for the project I have a feeling that nothing really good will come from it. I have a feeling that it will cause more stress then I would like to have in my life currently.

How do experienced developers make the decision of whether to take the project or just let it go? What are some good metrics to make the decision easier?


This actually seems like a very large ERP that he would like me to work on and I don't believe that he knows anything about programming so I don't think the fact that I am very junior has even crossed his mind.

  • 10
    Is this a difficult decision? You don't like the specs and don't believe in them. Why would you want to take this project?
    – Vitor Py
    Jul 14, 2011 at 15:48
  • 2
    This is a real example I have right now, but I felt that it would be helpful in general to open a discussion on how you choose projects, because there are no similar questions.
    – J Lundberg
    Jul 14, 2011 at 15:53
  • @J Lundberg: I've updated my answer in reponse to your update. Jul 14, 2011 at 17:01
  • 3
    If he doesn't know any programming then why is he insisting on VB.NET? He obviously won't be working on the project with you. There is no reason to use it over C# in .NET. You can compile the existing VB.NET and use it as a library in your C# code or vice versa. Jul 14, 2011 at 17:10
  • "needs help" - is this paid or unpaid?
    – user1249
    Jul 14, 2011 at 22:07

8 Answers 8


From my experience: Never do work involving money for family members that you have to spend holidays with or friends that you want to keep. One of the parties involved will always feel like the other party is either charging too much or not paying enough and that they did the other party a favor. When the deadline comes up, they are usually the least understanding, and they usually are ass holes during the beta test because if you have a bug--which you will--they will not understand. It is always a mess.

I used to be idealistic and think that everyone else just needed better people skills, but nope, that's just the way it is. People who do not understand the software development process will ALWAYS freak out when something doesn't meet their expectation the first moment they see it. This is true in business with project managers as much as it is with family members. The problem is, you have to maintain a relationship with family and friends, and things are never strictly business.

That said, if the project is going to increase your stress levels and you don't need the money then why take it? Especially if you already have a software development job that you want to excel in, I would say that you should dedicate as much of your working effort to being excellent in your day job because that is where you will ultimately be rewarded for quality work.

If you do need the money, and you are ok with the potential loss of a family friend, then take the job. The worst thing that could happen--other than the stuff I mentioned before-- is that you learn what you are and aren't good at, or you learn that you bit off more than you can chew causing the project to be a bad headache due to your inexperience. I have done that twice with my current job--fortunately I have very understanding employers. Though it was misery while I was feeling dead in the water, I emerged a much better programmer with a much wider skill set than before.

There is no calculus for determining which jobs to let go and to keep, only experience and your personality. You just need to decide what you value and pursue it. Things to consider:

Is this a project that I will enjoy working on? Is the team a team that I will enjoy working with?

What sort of payment will they be offering? If none, then what professional development will I be receiving? Do they offer any sort of shared risk (i.e. stock options, percentage of profits)? This is a big persuader for me.

Anyways, these are just principles to use in your decision making. It all depends on what you value. For example, I value intellectual challenges and time with my family so I usually place a high priority on what the project is and the skills I will learn in doing so. However, I also make sure to state up front that I am only working 2 or 3 nights a week so that I can spend time with my wife and children since I already work all day. I adjust the deadline to meet this demand. If they don't like that, then I don't take the job.

Whatever you do, make sure you state clearly what you will and will not do, and make sure they clearly state their expectations before you take the job. The worst thing that can happen is for the customer to have unstated expectations and for you to have underestimated those expectations.

P.S. I really wish I had read this article earlier in my career. It applies to my last paragraph. http://www.joelonsoftware.com/articles/fog0000000356.html

  • 5
    +1 for "never work for family". Not unless neither party has too much invested in it and sees it as pure fun, and even then one should be careful. Jul 14, 2011 at 17:43

How do experienced developers make the decision of whether to take the project or just let it go?

Do I need the job? If so, I "take" the project.

What are some good metrics to make the decision easier?

How many choices do I have? More than 1? I can choose between the alternatives.

Only 1? Well. That's it then.

The "stress in my life" question is moot; failure to take a project means failure to maintain employment; which has disastrous consequences.

If you have the kind of financial freedom where "stress" is a deciding factor, that's really great.

  • 3
    +1: You'd think there'd be more to it than that, but that's pretty much what it boils down to every time.
    – Ryan Hayes
    Jul 14, 2011 at 16:08
  • @S.Lott- I am sure you frequently have the opportunity to work on multiple projects. It seems unlikely that you are in "do or die" type situations very often. I might be assuming too much, but this seems to be a bit of a straw man, since someone with your experience surely has chosen to turn down a project here and there and also has probably accepted projects before when you did not need to in the "strapped for cash" sense. Jul 14, 2011 at 17:12
  • 1
    @ironcode: "I might be assuming too much". True. I have never had the opportunity of turning down a project due to stress.
    – S.Lott
    Jul 14, 2011 at 17:15
  • @S.Lott I mean stress in a sense that I already have a job and doing something like this might just leave me with zero time for my family.
    – J Lundberg
    Jul 14, 2011 at 18:26
  • @J Lundberg: Please update your question to include all the facts.
    – S.Lott
    Jul 14, 2011 at 19:10

What will you gain from this project? Money? Experience? Something else?

  • Money: It's from a family member (I try not to do business with family, but that's a whole other discussion), it's small (so you make it sound), you're fairly junior, so don't expect a whole lot of money from it (based on my experiences).

  • Experience: you get to learn a new language! That could be valuable in the future, may give you a slight edge over .NET developers who only know C#.

But your gut instinct tells you that this project will be bad. Why is that? It sounds like you could at least get some experience from this.

Most contractors would start with looking at how much money they will get to decide to take on a project. Ideally, more difficult projects lead to more money. If this is difficult, it should pay well, but I don't know the particulars to know if you actually will get paid well...

In response to the details in your update: Tell him that this is well beyond the scope of a single junior programmer. You might be able to do a few minutes of research and see if there's an existing product that can do what he wants and see if the "Features" page talks about customization/plugins/extensibility. He may also want to talk to a custom-software shop if no existing product is out there, or extensive plugin programming work needs to be done. There's nothing wrong with admitting a project is too big for you to handle - it's far better than taking it on and failing completely (especially if it's a family member - family functions could be awkward and strained for years).

A friend of my family

Personally if this phrase is involved, I do not take the project.


As a freelancer, I only accept projects where I'm confident to be able to complete it in time, in budget, in good quality. Refusing a project doesn't mean unemployment - at least not forever. Accepting a project you can't deliver costs everything - money, reputation, health.

It's sometimes a bit more difficult when a good customer needs help for a new project that simply doesn't fit my skills; but even then, it's better to be honest and let someone else do it.

In your case, you can and should deny the project - you are not experienced enough, you don't know the language, it's too big for you.


My personal take would be to do a little exploration of what is he wanting, what timeline, what kind of costs is he expecting, etc. If this is in fact a large ERP then the help could last for years and really get ugly possibly. Waste Management vs SAP would be an example of just how expensive this could get if you really mean large as in 9 digit project budgets.

My point in doing the exploration is to draw a line in the sand so that it is clear why I'm asking the questions and what I intend to have as a result. "How viable do I see this being?" is the question I'd have as I'd question methodology, budget, and timelines upfront and then do a little research to see whether or not things appear to be on the level or is this something that may end up in some IT humor site like The Daily WTF.


I've been doing freelance programming for over twenty years. For a project to really be successful, it needs at least the following:

  1. Somebody who knows the programming, software, and hardware technologies used for deployment - or technologies similar enough to learn the deployment technologies really fast
  2. Somebody who knows the problem domain, and is able and willing to translate that into specs the programmer can use. (If the programmer is also the domain expert, and the project is simple enough, the specs can be in their head or informal notes.)
  3. Somebody who is able, willing, and experienced at managing the project tasks, timeline, etc. well, and knows the kinds of pitfalls you can get into with things like estimating and how to avoid them
  4. Somebody to manage the communications and relationships among all the project stakeholders, including the programmer(s) and customer(s)
  5. People on both sides, consultant and client, who are experienced at keeping the ongoing business matters solid, including contracts and money. If you don't have this experience yourself, you can get by with an experienced adviser until you are.
  6. An arm's-length business relationship where, if you have to make a tough business decision, you don't have problems outside of work
  7. A large-enough team, with the right combination of expertise, tools, and resources, to deliver a quality product within the required timeline

You describe a friend-of-the-family who knows nothing about programming, who wants you - an inexperienced programmer - to build an ERP system using a technology you don't know.

It sounds to me like this situation definitely misses on #1, #3, #6, and #7, and maybe all of them. As Adam says on Mythbusters, "This is a recipe for disaster."

Heck, I wouldn't touch this one with a ten foot pole myself. I could go on and on about the other red flags I see here, but basically, my advice to you is go with your gut feel, because you're right: "nothing really good will come from it."

Since this is a friend of the family, if I were you, I would just say, "You have a great project, and you need somebody really good, and I'm too inexperienced to give you the results you should have," and leave it at that.

I've also found that when you have a client who's a problem in one area, they're likely to be a problem in others. A prospective client who would even consider having an ERP system designed and implemented by a junior programmer is either so ignorant as to be a hazard to themselves and others, or ridiculously cheap, and either of those would put them in my "stay away" list.

FWIW, as a consultant/freelancer, I wind up filling the roles on my side myself, with advice from my wife. We've figured out what all those items are by seeing projects fail due to lack of them - sometimes, it's been our own projects. And even after twenty years, and despite checking these criteria, I still wind up with an occasional project that doesn't work out - that risk is always part of being in business. I just make sure now that projects don't fail because of anything I've done wrong, and that contracts are structured so I get paid if the other side screws up.


Do you want to work with the other people involved?

The project is just an excuse to meet and associate with people.

  • I like that point of view. We should work on a project together. Jul 14, 2011 at 16:44
  • It has served me very well. Project details can shift like sands in a storm. People can still surprise you, but they change more slowly.
    – bmike
    Jul 14, 2011 at 17:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.