Archive for the ‘Consulting’ Category

So you want to be an independent contractor?

Friday, February 19th, 2010 Nigel Jones

Today’s post is motivated by the events that happened yesterday in Austin, Texas. For my overseas visitors, a software engineer, Joe Stack, decided to fly his light aircraft into an office building that housed the regional offices of the IRS (the American tax office). He created tremendous damage and likely murdered at least one person, while killing himself. Notwithstanding that I wrote just a few weeks ago about the propensity for engineers to be involved in terrorist acts, what is relevant about this news item is that it appears that Joe Stack’s principal complaint concerned a portion of the US tax code (via Andrew Leonard) that applies almost uniquely to consultants / independent contractors in the software / firmware field.

So while this isn’t a tax advice blog, I thought I’d weigh in on the issue, since it’s something that applies to me, and indeed anyone thinking of becoming a consultant / independent contractor in the USA.

The main issue revolves around who is an employee and who is an independent contractor. From a tax perspective this is an important distinction, because companies can avoid a lot of overhead by classifying employees as independent contractors. For example, employers avoid paying the employer contribution to social security, which for a typical engineer in the USA was around US$7000 per person in 2009. Instead the independent contractor is responsible for this payment. Conversely, independent contractors get some benefits that employees do not. For example an independent contractor can normally deduct from his taxable income the cost of travel to and from a client’s office.

Now whether one prefers employee or independent status is of course a matter of income levels and personal preference. However, what is crucial is that one not fall some where in the middle – because if you do you stand the risk of being re-classified by the IRS – at which point the tax bills can start getting very large for everyone involved. This falling in the middle tends to occur when someone is classified as an independent by the company – but acts like an employee. That is they work the same hours, and do the same work at the same time in the same location as someone who is an employee. If this describes you, or it describes a job that you are considering, then I suggest you read on.

Note that in the following, I have assumed that you want to be an independent contractor. If you are classified this way and instead want to be an employee, then do the opposite of what is advised!

An independent contractor must be free to set their own work hours. Although it is OK for an organization to say you can’t work, e.g. after 9 pm or before 6 am, it is not OK for them to specify your exact work hours. Furthermore, it is important that you exercise this right. For example if you are required to be on site 40 hours a week, then to preserve your independent contractor status it would be smart to work e.g. four 10 hour days, rather than the normal five 8 hour days. I also recommend that you strive to get the right to work from your home office for a certain percentage of the time. This helps establish your home office as a bona fide work place while simultaneously bolstering your independent status.

An independent contractor is normally expected to provide their own tools. Now clearly you are unlikely to own a $25,000 spectrum analyzer. However as an independent contractor it is certainly reasonable that you provide your own computer and other tools such as compilers, email clients etc. The problem with this is that it often clashes with a companies IT policy. When this happens I strongly suggest that you sit down with the various parties (HR, IT, your recruiting manager etc) to address the issue. There are various options available, but the bottom line is you need to protect your status – and the company (if it’s on the ball) will want to do the same.

Multiple Clients
The final way in which I handle this issue is by having multiple concurrent clients. This not only helps you meet the time requirement, but it also strongly reinforces the fact that you are free to work for whom you want, when you want – almost the definition of an independent contractor.

Well that’s my practical guide to not falling afoul of the IRS rules. Hopefully for those of you contemplating going into the consulting business you’ll have found it useful.

I’ll be returning to my more normal fare with my next post. As a heads up, embedded-gurus is undergoing a major face-lift over the next few weeks, which may impact not only my posting schedule, but also all the other bloggers here.

Hardware costs versus development costs

Thursday, December 24th, 2009 Nigel Jones

Earlier this year I posted about how to solve the problem of PIC stack overflow. As part of that article I asked the question as to why does anybody use a PIC anyway when there are superior architectures such as the AVR available? Well, various people have linked to the posting and so I get a regular stream of visitors to it, some of whom weigh in on the topic. The other day, one visitor offered as a reason for using the PIC the fact that they are cheap. Is this the case I asked myself? So I did some rough comparisons of the AVR & 8 bit PIC processors – and sure enough PIC processors are cheaper to buy. For example comparing the ATmega168P vs the PIC16F1936 (two roughly equivalent processors – the AVR has more memory and a lot more throughput, the PIC has more peripherals) I found that Digikey was selling the AVR for 2.60 per 980 and the PIC for $1.66 per 1600. A considerable difference – or is it?

Most of the products I work on have sales volumes of 1000 pieces a year, with a product life of 5 years. Thus if I chose the AVR for such a product, then my client would be paying approximately $1000 a year more for say 5 years. Applying a very modest 5% discount rate, this translates to a Net Present Value of $4,329.

This is when it gets interesting. Does the AVR’s architecture allow a programmer to be more productive? Well, clearly this is a somewhat subjective manner. However my sense is that the AVR does indeed allow greater programmer productivity. The reasons are as follows:

  1. The AVR’s architecture lends itself by design to being coded in a HLL. The PIC does not. As a result, programming the PIC in a HLL is always a challenge and one is far more likely to have to resort to assembly language – with the attendant drop in productivity.
  2. The AVR’s inherent higher processing speed means that one has to be less concerned with fine tuning code in order to get the job done. Fine tuning code can be very time consuming.
  3. The AVR’s greater code density means that one is less likely to be concerned with making the application fit in the available memory (something that can be extremely time consuming when things gets tight).
  4. The AVR’s superior interrupt structure means that interrupt handling is far easier. Again interrupts are something that can consume inordinate amounts of time when things aren’t working.

Now if one is a skilled PIC programmer and a novice on the AVR, then your experience will probably offset what I have postulated are inherent inefficiencies in the PIC architecture. However what about someone such as myself who is equally comfortable in both arenas? In this case the question becomes – how many more days will it take to code up the PIC versus the AVR and what do those days cost?

Of course if you are a salaried employee, then your salary is ‘hidden’. However when you are a consultant the cost of extra days is clearly visible to the client. In this case, if using an AVR reduces the number of development days by even a few, the cost difference between the two processors rapidly dwindles to nothing. Thus the bottom line is – I’m not sure that PICs are cheaper. However I suspect that in many organizations what counts is the BOM cost of a product – and perhaps this finally explains why PIC’s are more popular than AVR’s.

As always, I’m interested in your thoughts.

Consulting as a leading economic indicator – update #1

Saturday, October 3rd, 2009 Nigel Jones

At the beginning of September in the wake of the dismal jobs report for EE’s posted by the IEEE, I wrote an article postulating that consulting is a leading economic indicator for our industry. I also promised an update around the end of September.

The bottom line – it’s still very quiet. I’ve asked some fellow consultants their opinion on this issue. The response has been very guarded optimism, in that they are seeing an uptick in interest, even if it isn’t directly being translated into a lot of work yet. So for those of you out there looking for gainful employment, I’m afraid I really don’t have any good news to report. The best I can give you is that the bad news hasn’t got worse.

Changing topics, if you have not read Mike Barr’s recent posting on binary literals, then I strongly recommend that you do so. It would have fitted very nicely into my series on effective C tips – so if you find my effective C tips series useful, then go take a look.


The consultant's dilemma

Tuesday, September 29th, 2009 Nigel Jones

Today I’m going to talk about an interesting ethical dilemma that is faced by all engineers at various times in their careers but which consultants face much more frequently because of the nature of the work. The situation is as follows:

A (potential) client has a new project that they wish to pursue and they have brought you in to discuss its feasibility, risk, development costs etc. At a certain point in the discussion, the topic of CPU architecture comes up. In rare cases, there is only one CPU that makes sense for the job. However in the majority of cases, it’s clear that there are a number of potential candidates that could get the job done and the client is interested in your opinion as to which way to go. In my experience you have the following options:

  1. Recommend your favorite architecture
  2. Recommend that time be spent investigating the optimal architecture
  3. Recommend the architecture that you are most interested in gaining experience on in order to develop your career.

Let’s take a look at these options:

Favorite Architecture
The advantage of going with your favorite architecture is that presumably you are highly experienced with the processor family and that you already have all the requisite tools in order to allow you to quickly and effectively develop the solution. The downsides to this approach are:

  1. It leads to antiquated architectures hanging around for ever. The prime example of this is of course the 8051.
  2. It means that your skill set can stagnate over time.
  3. It also may mean that the client pays more for the hardware than they would if a more optimal solution was used. This comes about when e.g. an ARM processor is used when an HC08 would have done quite nicely.

Architecture Investigation
With this approach you are essentially asking the client to pay you to work out what the optimal solution is to their problem. Sometimes this is just a few days work and other times it’s a lot more. This is often a tough sell because clients expect the consultant to instantly know what the best architecture for their application is. Furthermore, at the end of the day the consultant may end up recommending an architecture for which they have little experience. Whether you think this is reasonable or not depends on how you view consultants.

Career Development
In the 25+ years I’ve been doing this, I’ve only come across a few blatant cases where it’s clear that an architecture was chosen because that’s what the lead engineer wanted to play with next. My experience is that engineers are way more likely to be too conservative and stick with their favorite architecture than they are to go this route. Nevertheless if you are in the position of asking an engineer (and particularly a consultant) for a CPU architecture recommendation, then you must be aware that this does go on. Your best defense against this is to closely question why a particular architecture is being recommended.

So what do I do when faced with this issue? Well you’ll be pleased to know that I have never recommended an architecture in order to further my career. The decision as to whether to recommend my favorite architecture or to suggest an investigation comes down to one of cost. If the client will be building 500 of the widgets a year, then development costs will dwarf hardware costs and I’ll go with my favorite architecture. Conversely if they will be building 10,000 widgets a year, then an investigation is a must. The middle area is where it gets tricky!

I’d be interested in hearing how you have handled this dilemma.

Consulting as a leading economic indicator

Thursday, August 20th, 2009 Nigel Jones

The IEEE has a rather depressing news release out that claims that EE unemployment more than doubled last quarter to a record high 8.6%. The previous quarterly record was a mere 7% in Q1 2003. Interestingly the unemployment rate for all engineers was a mere 5.5% which suggests that EE’s are taking the brunt of engineering unemployment. If you are one of those unfortunate enough to be axed, then what’s the employment outlook for you?

Well I’m no economist and I certainly don’t have access to, or interest in, reams of economic data. What I can do is give you my micro-economic perspective. Over the 15 years I’ve been a consultant I’ve developed the notion that consultant activity is a leading economic indicator. That is, when companies need engineering help, but are unsure whether to take on employees, then they turn to consultants. Conversely when companies need to cut costs, the first to go are consultants and contractors. In short, consultants are the first to go in bad times and the first to be retained in good times. This hypothesis seems reasonable to me, and broadly reflects my experiences. So with this as a background, what can I tell you about the current economic state of affairs?

Well, firstly the current ‘slowdown’ came on so hard and so fast that my sense is that consultants and employees basically bit the dust simultaneously. OK, so what about the upside? Am I seeing an increase in demand for my services? In short – no. Having said that I almost never see an increase in demand for my services in July and August for the simple reason that too many people are on holiday. Notwithstanding this, my sense is that it is still very quiet.

So am I pessimistic? Actually – no. A large slice of the stimulus money has been funneled to organizations such as the NSF, which are only now getting around to doling out various grants. Thus I expect this to start having an effect on EE demand soon. I also have the sense that a lot of companies having weathered the financial storm are now looking ahead to see how they can best exploit the upturn when it comes. If I’m right, then the phone should start ringing again in September. I’ll post an update around the end of September and let you know if I’m right!