Today’s question is an interesting one that people outside of the programming world ask me a fair amount. Loosely speaking, this question is one of how programmers interact with the rest of the team.
But here’s the thing.
That question typically comes to me in the form of many more specific questions: Should programmers test software? Or how does project management work with the Dev Team?
So let’s today take these questions in aggregate. Who are the rest of the folks that programmers interact with? And how does the division of responsibility work?
What Are These Other Roles?
Before we can really address that, though, we need to take a look at who these folks are. Software development isn’t just a bunch of programmers in a room. Let’s see who else is typically involved with software projects, and what they do.
- Testers—these are people whose role is to run the software and see if it does what it’s supposed to do.
- Quality assurance—testing generally falls under this broader umbrella, and quality assurance people are more generally responsible for making sure the software product is up to snuff, across the board.
- Project manager—the project manager typically deals with external stakeholders, keeps track of progress and schedule, removes obstacles from the team, and generally keeps an eye on the prize.
- Development manager—this is the person in the organization to whom the team reports, otherwise known as the programmers’ boss.
- Business analyst—this person shares some overlap with the project manager, but is primarily responsible for deciding what customers need the software to do.
- Operations/support—people in these roles deal with issues related to the running and use of the software, as opposed to the programmers who build it. (Note that a movement called “DevOps” drives at blending development together with this role.)
Please note here that I’m not getting into specific roles within the software world, which include things like architects, “back-end” developers, “front-end” developers, DBAs, etc. All of those distinctions are topics for another day.
Today, we’re focused on answering questions related to the (typically) non-programming folks on the team.