What roles are involved in software development?

If you're in business, or running a charity or other organisation, and you have a software project, it can be confusing trying to understand why so many different roles are involved. I will explain the main titles you'll meet, what their specialisms are, and how they fit into the overall project.

While this information is primarily for people who don't consider themselves to be technology experts, it's hopefully a useful reminder for those who have been in the software industry for a while.

In this article the two 'sides' are talked about; people in the business (the 'client' side) and those in the development team (the 'supplier' side). Talk of sides can be unhelpful, as the goal of everyone is to deliver a successful project which meets the needs of the business. However, often the client and the supplier are separate companies, or separate departments in a large organisation. Good communication is therefore critical.

Disclaimer

There's an old saying in technology, which is everything can be answered with the phrase 'it depends'! You may or may not need all of these for a particular project. Also, this article explains the meaning of different roles using some standard terminology, but you may come across other words not covered here.

Business people

Most software projects are started to fulfil a business need; replace older systems, increase performance, support new business opportunities, streamline processes. There are, therefore, people from the business involved (by 'business' we can include other types of organisations who have software development needs).

Subject matter experts

Unless the projects is very small and simple, it's likely that other representatives of the business will need to be called upon by the software development team. These experts provide their knowledge to answer the many small questions that might crop up as development progresses.

From the meaning of some business terminology, to explanations of why a particular component needs to work a particular way, having someone who is an expert in the subject is invaluable.

Project managers

Larger software projects need someone who can be a point of contact for the business. Someone to help guide the project and maintain information about whether it is on track. Project managers will communicate progress, report on timelines and milestones, and very often will be the first person the business call on if they need an update or to request changes.

They are also incredibly useful for development teams, as they take calls and deal with emails that could otherwise be a distraction for people trying to write code and test systems.

Product owners

For many organisations who have large, long-lived software systems, product owners are the people who take long-term ownership to help prioritise work. A product owner understands the requests coming from customers or users of the system, can gauge the business benefit in proposed changes, and deals directly with the development team to set the order in which different pieces of work should be done.

Within large businesses, who may have their own in-house development teams, product owners are the subject matter experts on the systems they are responsible for, and the first point of contact for any proposed changes.

Business analysts

For simple projects all the requirements for the system might be obvious. For larger projects the requirements may take some investigation to find out; in some cases quite a lot of investigation. A business analyst will look at the business closely to figure out exactly what the software needs to do.

This sounds easy, but can be very complex. For example, if the software solution is replacing an older paper-based process, do all the steps in the old process actually need to be replicated in the new system? What about edge cases, where on occasion something non-standard needs to happen?

Architects

Software architecture is a very broad subject, but in a nutshell an architect is responsible for making large-scale decisions about how to implement solutions which would be hard to change later. To equate this to an architect of a house, they don't really care whether you paint your kitchen blue or green, but they do care that the gas and water supplies are routed in a way which makes them safe and easy to maintain.

While there are quite literally dozens of roles involving the word 'architect', they all boil down to these three main groups.

Enterprise architects

A large organisation with many technology systems needs someone who can oversee them all. The enterprise architect makes the high-level decisions about ensuring the systems are fit for purpose, planning and making recommendations that enhance security, improve performance, ensure consistency and simplify support. The enterprise architect also has to keep all of this in line with the wider business goals, keeping costs down and planning the high-level architecture so it can support new business opportunities and fix common problems.

Solution architects

The next level down in architecture are the solution architects. These people get into more detail about projects, planning individual system components and how they relate to each other. Along with product owners, business analysts and subject matter experts they guide the planning of software projects.

Solution architects produce documentation that explains how the business processes relate to technology components, and make recommendations about how the system should be developed to meet performance, security, and consistency aims.

Technical architects

The architects with the most detailed focus are technical architects. Sometimes these people have expertise in particular technologies, such as databases. Sometimes they are knowledgeable about an entire domain of technology, for example 'cloud' computing.

In many companies the role of technical architect is fulfilled by the senior members of the development team, or perhaps by the solution architect. For specialised knowledge it's also common to get outside help.

Designers

Most software has some form of user interface — the bits you look at, click buttons and links, type text in. To make these look and work well you need designers.

Graphic designers

A graphic designer is concerned with the looks of the system: the logos and colour schemes, the layout of web pages. Traditionally a lot of designers working in technology have had a background in print; think posters and books. But to produce effective designs for software, particularly for website and mobile apps, requires a further set of skills.

User experience designers

As well as a good sense of aesthetics, user experience designers will consider how user engage with software in order to make that experience the best it can be. From ensuring buttons are big enough to the be clicked easily, to checking that the contrast of text and the background colour is sufficient so the writing is easy to read, user experience designers take a holistic approach.

User experience designers also pay attention to how the flow of a software system works for users — how they move from one screen to the next. What if they make a mistake? Can they rectify it easily? Attention to detail with these things can have a profound impact on the engagement of users, and in an e-commerce scenario that means increased revenue.

Content strategists

One role which is incredibly valuable, but seldom used, is the content strategist. Most organisations have lots of information. Keeping track of what is out of date, how that information should be organised and presented, and even what 'tone of voice' an organisation should have is the responsibility of the content strategist.

Imagine them like librarians: they organise the library so it's easy to find particular information; they remove out of date information and ensure new information is sourced; they decide what the most important information is and ensure that is the easiest to find. If you've tried and failed to find information on most websites you can see how useful someone with this expertise is!

Agile

It's worth mentioning that a popular way to build software is using the Agile methodology. While a full description of Agile is outside the scope of of this article, in a nutshell it advocates building software in an incremental way. First you build something quick and simple to prove an idea will work. Then you build a bit more, testing that as a business you're happy with the new changes, and that the project as a while is going in the right direction. This process is repeated for as long as you want, until you have a system which is as complete as you need it.

Contrast this with a more traditional way of building software, where a large specification document detailing everything the software should do, is written up front. This is then given to the development team who build it, and only when they are done do you see the final result. There is a very large chance that what you get isn't quite what you want, or that the specification document missed something. This methodology, called 'Waterfall', is largely rejected by most development teams.

Scrum masters

One particular flavour of Agile is called 'Scrum', and essentially involves the development team working in short 'sprints' — normally a week or two in length — in which they do a bit of development, test what they've done, then present it to the client. The scrum master ensures that each sprint is well planned, progressing smoothly, and that the feedback mechanism of regular 'show and tell' sessions is working correctly. They also help keep distractions away from the developers and testers.

Developers

Once you know what you want to build, in whatever detail you're happy with, it's time for the development team — the developers and testers — to get to work. A good project manager or product owner will have engaged the team before now, so they'll have a good idea how they are going to build and test the solution.

There are, to be blunt, loads of different kinds of developers — some people call them engineers. They broadly fall into three types.

Back-end developers

There are many systems that humans don't see. The kind of systems that process data, listen for things to happen, respond to messages from other systems. The world runs on code like that. The developers that write this code are often known as back-end developers, as they write the systems at the back end of the solution.

As an analogy, think of when you buy something from a shop. You see and interact with the salesperson and the cashier, but there are possibly hundreds of people involved in actually delivering that product to you. Back-end developers are there: hidden from view, but crucial to making everything work together.

Front-end developers

On the web, and sometimes building applications for desktops and smartphones, a new breed of developer started to emerge a number of years ago. Front-end developers write code, but their code is to make the visual parts of applications work well. They are the ones who implement the buttons and links.

Often working closely with user experience designers, front-end developers have expertise in making websites fast, work on different devices, and be easy to update. They increasingly create "design systems" which means if they have to, say, build many web pages which have similar characteristics, they don't have to write all that similar code from scratch every time.

By far, front-end development has evolved and grown the most out of all aspects of development for the last few years.

Database developers

Underpinning almost all systems is, of course, data. Database developers are the people who write the parts of the system which makes sure data is saved correctly, stored in an efficient manner, and can be retrieved easily in many different ways for reporting purposes.

While some database developers have specialism in one particular database type, some of the principles of good database development are applicable across the board.

Testers

Despite the best efforts of all involved, systems are rarely created perfect first time. Sometimes requirements have been misunderstood, or aspects missed entirely. Sometimes code doesn't do what it should — especially when something unexpected happens, or when they are deliberately pushed to the limit.

The testers are responsible for quality assurance, by creating comprehensive suites of tests they can run on systems to ensure not just that they behave correctly when everything is working, but that they will respond appropriately in exceptional circumstances. Testers have a particular mindset, which is interestingly the opposite to developers! A developer always has at the back of their mind 'how can I make this work' whereas a tester is constantly thinking 'how can I make this break'.

Automation testers

Manually testing all aspects of a system, even a small system, every time a change is made can be very tedious. If those tests could be automated, so they run automatically and any failures reported, that would save a lot of time - not to mention make the running of those tests more consistent.

Automation testers have specialist development skills to write automated tests. Often these tests are grouped separately for back-end and front-end tests. This suite of automated tests becomes a 'regression pack': a way to prove that if a change is made to a system that nothing which was already there has been inadvertently broken, or regressed.

Automated testing is becoming very popular due to the amount of time it can save.

User acceptance testers

One of the final aspects of the software development lifecycle is a final test to verify that what has been delivered is what was needed. This means the user has to accept what has been built. Often user acceptance testing is done by a representative from the client, in conjunction with the wider test team, and often the product owner. User acceptance is the final seal of approval to say 'yes, this is what I wanted'.

Operations

Now your project is completed and in use by customers, you need a team of people to ensure it stays up and running. Your support team are those unsung heroes, working 24-hours per day to monitor and maintain your systems. Larger companies may have their own full-time staff to do this work, but smaller companies often rely on the expertise of the datacentre companies they partner with.

Your operations team are mostly the ones who implement and test backup and recovery systems, and will put in place disaster recovery plans - so if something catastrophic were to happen to your systems they can them back up and running, and you back in business, as quickly as possible.

These are the people who are seldom celebrated, but have a huge responsibility to maintain the systems which businesses rely on. It's worth spending some time to get to know and appreciate your operations people; you never know when you're going to need them.

Support staff

'Support' is a broad term, covering everything from customer support, to '3rd line' support where bugs are investigated and fixed. Most software projects require some level of ongoing support; very rarely does a piece of software keep running with no need for maintenance — and that's without catering for customers or users who might get things wrong!

Hardware engineers

Software is, by definition, fully reliant on the computers that run the technology. SO experts in that hardware are required. These people monitor and maintain the physical hardware, replacing broken parts and recommending when to upgrade components which are likely to fail. They are also valuable sources of help for how to tune systems so they run as efficiently as possible.

Network engineers

Having a piece of software is no use if your customers and business staff can't get to it. Network engineers ensure that the systems which need to talk to each other can do so, and quickly. They are also the ones who maintain the 'perimeter' of the system, keeping out the bad guys who want to break in and steal your data, or just cause damage.

Database administrators

Most businesses are reliant on their databases. While the database developers can build databases, for them to work best they need expertise in how to make those databases run well — particularly over time when the amount of data starts to build up. Database administrators have deep knowledge of your databases, and are particularly useful in getting things back up and running when they break.

Running your project

Hopefully now you've got an appreciation for all the main roles involved in a software development project, and the responsibilities they hold and value they bring. While not all projects need all these people, as generally the smaller the project the fewer people are involved, you can see that communication is absolutely critical.

Each team, and each organisation, will have their own way of communicating. What is really useful, however, is to make that communication a regular thing. This is where the Agile methodology really shines, as it requires teams to 'show and tell' often to make sure that what is being built is what is needed.