It's too bad the question is framed as it is. I think a better question might be "How is a 'software contractor' different than a 'software consultant'?" It is these terms that really raise the question, at least here in the U.S.
The term 'software developer' can apply across any type of employment, developer being the type of role or resource one serves. The contractor/consultant issue revolves around employment issues, and again, I am speaking in reference to how it works here in the U.S. But to really answer this question definitively (and you will see, even that is difficult to do!), first we need to define some terms and explore some history.
A software developer, regardless of how they are employed, creates software, and probably does many other tasks related to the creation of software, usually with the exception of a management role, although even that is quite common on some projects, such as team leads. Software project and program managers rarely get involved in the nuts-and-bolts activities of creating software (aside from team leads). Again, these are roles.
As to employment and payment, there are several types (applicable to U.S.). The most common type of employment is regular or 'direct,' where the worker is on the payroll of the company developing the software. They fill out a W-4 with the employer each year and receive a W-2 from that employer at the end of the year for their taxes.
Outside of direct employment, there are contractors, and (depending on definition) consultants. The term 'contractor' is a bit misleading, however. Technically, a contractor is an entity or person who signs a contract with the client company, in this case the one developing the software. But the reality is, nearly all contractors in the U.S. work through a contracting company (also refered to as 'body shops' and even less complimentary terms); they do not 'contract,' per se, directly with the client. These so-called contractors actually fill out a W-4 with the contract company -- not the client -- each year and receive a W-2 from that contract company at the end of the year for their taxes. They are taxed the exact same way as their directly-employed brethren and sisteren. As far as the IRS is concerned all W-2 workers are direct employees.
The point here is that it is the 'contracting company' that actually signs a contract with the client company, not the so-called contractors (the 'contract employees'). The contract employees are actually employed by the contract company, and the contract company is the party to the contract with the client. So the contract and direct employees working on a software project are essentially the same in terms of taxation, and usually work in adjacent cubicles with no particular special status, the only major difference being that contractors are limited to a certain time they can continue working on the project for that client. This is because the contracting company they work for is not supposed to keep them there for longer than that time or our IRS may reclassify them as direct employees, and the parties (client and contracting firm) to the contract would become liable for the difference in taxes.
In my own experience, contractors are often extended by HR trickery, re-classifying a contract employee from, say, 'contractor' to 'temp' or the like. Clients that wanted to keep me on have done that on occasion. The client companies do have to be careful though; the IRS may audit them to determine the true relationship of those contractors. If the IRS finds that the client has been treating them like direct employees, keeping them on site indefinitely for instance, the client becomes liable for any benefits those (now-regular) employees were not receiving as contract employees. And the contracting company can be liable as well. I do not know all of the ramifications, but it can become messy.
Oh, yeah. What is a 'consultant?' That term is kind of 'squishy' -- there have been many wars fought over that sacred territory. It used to be, maybe 40 years ago, that 'consultant' was more-or-less synonymous with 'independent contractor,' meaning a worker who directly contracted with a client. That is, the worker signed a contract with the client (maybe the one developing software, as above). That worker does NOT fill out a W-4 with the client and does not receive a W-2 from the client at the end of the year. Instead, a direct contractor (what was often referred to as a 'consultant' back then) receives a 1099 from the client. The direct contractor usually had their own corporation that paid its taxes at corporate rates and had to obey IRS business tax rules (and of course also enjoyed benefits of being a corporation!).
Along with this very different tax arrangement, the term 'consultant' had a certain aura about it. Consultants were generally more experienced (at least 10 years working in the field) and usually had some area of expertise that might have been difficult to locate, making them very desirable to clients, and clients were willing to pay $500 or $1000 a day (a very generous amount then) for their expert services. Consultants ran with an elite crowd of fairly-well connected people, and it was generally hard to break into those cliques. Membership was necessary if one was to be a successful consultant. There was an organization, recently defunct but being revived now, called ICCA which was sort of an old-boys club for computer consultants. Anyone could join, and I did at one point; being accepted and getting work was a different story.
There was a niche industry also, especially in places like the financial district of NYC, that specialized in brokering contracts for these consultants. But back then, in order to get work in software -- and especially the financial sector -- one had to be well connected (I know because I had tried back then). Today, these brokers have been swallowed up or run out of business by the big placement companies. Independent contracting has been nearly eviscerated (it does exist, but that sector is much smaller now, nearly non-existent) by a series of legislation that has slowly and certainly destroyed independent contracting like that.
Today, the term 'consultant' is rarely used in the software development employment realm. At least, I have rarely heard it. Sometimes a contract software developer is referred to as a consultant, but it is hardly any distinction other than, perhaps, some attempt to flatter or compliment some particular contractor for their expertise in a throw-back to that earlier tiem when the term meant something special.
I should state that there are still software project managers called "software management consultants," but almost all of them are also direct employees to some contractor company that performs the same purpose to these management contract employees as the companies that provide the W-4's to those software developer contract employees. And, as you might imagine, sometimes they are the same contract firms. Some clients want to deal with one source of workers for both developers and managers working on a project.
Genuine, independent software consultancy in the U.S. is mostly dead thanks to changes in federal legislation and the changing landscape of corporate America. As companies (potential consulting clients) get larger, their HR departments become more brutally centralized, arrogantly efficient, and technologically black-boxed. It is nearly impossible these days to contact a hiring manager to discuss an employment opportunity of any kind, direct or contract. Part of this is corporate secrecy and employee protection, but a lot of this is the trend toward ensuring that as many workers as possible are direct employees, or at least working through a contracting company.
The alternative to this scenario, similar to that earlier time of 40 years ago or so, was quite different. Back then, it was more difficult for employers to control the work of their contracted employees, especially the consultant type. Control of workers has been increasingly becoming the main issue of employment in the U.S. to ensure increasing productivity which, in turn, is important for competition with nations like India and Vietnam, whose workers are even more accustomed to ever-increasing demands of productivity.
The key to understanding all of this is to understand that the independent contractor cannot be told exactly how or when to do their work. They usually must provide their own tools. They have to comply with about 20 of these types of constraints for the IRS to recognize them as legitimate independent contractors. Otherwise, those legal issues I referred to above kick in, along with potential lawsuits between contract employees and their contract companies for back-benefits that would then be lawfully due to them.
Sorry for the long-winded explanation, but it really is this complex. I am a software developer who has worked direct for companies and through contract companies. I have many times considered going "indy" but that has become a very treacherous (and intimidating!) road to follow in recent decades. And the corporations, plying and leveraging their influence in government, continue to tighten up this arrangement. The American Software Consultant is dead; any remaining survivors are suffering their last breaths.
