It can be confusing with the terminology around programmers and developers especially when these descriptions are used interchangeably so in this article I will attempt to differentiate between the two.
I know that not everyone will agree with me and some will think that developers and programmers are the same thing but from looking around when trying to hire resources, I think the market has pretty much adopted the same approach as me.
So for people who may be looking to hire development resources or have a development project on the horizon or are in the development business but still get confused by the terminology or if you are just interested in what the difference is, then this article is for you.
In simple terms, a programmer follows the instructions on a technical specification that has been created for them usually by a business analyst, whereas a developer has experience as both a business analyst and a programmer so combines the roles.
Programmers
A programmer will read some instructions and logically create a system, quite often without questioning the logic of the request. Of course they will ask for ambiguous or incomplete requests to be clarified. For example; “The member drop down box should contain the relevant information” or “The input boxes on the page will cover things like; member name, telephone, etc…” are the types of instructions that are incomplete and “Page 1 should show the details as they are now and page 2 should show the corrected details. “There needs to be a map on the page.” is ambiguous as the programmer would not know which page to include the map.
A programmer likes everything to be clear and follows the instructions to the letter. You get whatever you wrote in the technical specification so the business analyst has to make sure that everything is very well defined. Basically, apart from knowing how to code, the programmer doesn’t need to think about what they are doing as the business analyst (the person that creates the technical specification) has done that already.
A business analysts produces the full specification and the programmer builds it to that specification. The first chance the requestor or business analyst get to check the product is when it is delivered for user acceptance testing (UAT).
Developers
A developer can be likened to an analyst and programmer combined. The programmer in them knows how to code and the analytical side knows how to interpret business requirements. A developer requires programming and analytical skills together with good common sense. Instructions to a developer are not required to be very technical as the developer will have an understanding of the business or will be willing to investigate and learn about it.
The developer will analyse instructions and will know when to use their own judgement (common sense) or when to go back to the requestor for advice to help make better informed decisions. A developer may also create their own specification, mock up some screens or even create a prototype to check they are on the right track before proceeding. With a developer you may get to see the product at a much earlier stage in the development cycle enabling you to critique anything along the way rather than at the end.
Most developers were either programmers or business analysts before they became developers. Having an insight into both the business and technology worlds makes them much more valuable asset so they cost more.
Development resourcing
When hiring programmer’s you need to make sure you have very good business analysts to write the specifications for them otherwise you will find that what is delivered may not be what you were expecting (but it was what you asked for). There will be no comeback as you hired programmers that just follow your specification. So the onus is definitely on the business analyst to get it right and therefore most of their time is spent writing technical specifications up front before engaging the programmer.
On the other hand, if you hire developers, the business analysts are not so burdened writing technical specifications and can spend more time with the business project requestors helping the company to innovate, gathering business-level requirements or checking that the delivered product meets the business requirements.
As a developer already has the business analyst skills you may be thinking that it may not be necessary to have a separate business analyst function but from experience I would disagree. The role of the business analyst would just change slightly, they could cover more projects rather than being tied down to the technical specification of a single project and leave the developer to work out the finer details. They may also take on the role of UAT later in the development lifecycle (after quality assurance testing rather than instead of it).
In a usual situation, a project request will go through an approval process to make sure it will make or save more than it costs to develop it. If a developer is tied up getting projects approved they are spending less time building the products that do. I feel it is better to have a separate analyst doing that job and when they have approval and the basic requirements, hand over to the developer to work out the finer detail.
So my conclusion is that if you hire developers you will need fewer people to cover the projects, will deliver them sooner and will get what you want with far less effort from the business side of your organisation.