How do you decide if you should take a project?

Question

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?

Edit

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.

Answer 1

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

Answer 2

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.

Answer 3

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).

Answer 4

A friend of my family

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

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

Do you want to work with the other people involved?

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