How Do Programmers Interact With the Rest of the Team?

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.

Should Developers Do Testing?

First up, should developers have responsibility for testing?  If so, how much, and what do the testers do?

The answer to this question is yes, developers should do some testing.  When you write code, build it, and run it, you should absolutely be confirming that it does what you thought it would.  This is simply part of being a professional programmer.  

However, testers are important as well.  There is a limit to how much testing the programmers should do when it comes to the software.  And this isn’t because programmers need to specialize only in programming.  Rather, it’s the same reason that you don’t write a paper and edit it yourself.  You’re too close to what you just did.

Programmers should check to make sure they’re not making sloppy mistakes.  But you need a team of testers to act as a fresh set of eyes and to bring a relatively unique set of skills to bear in critically analyzing the software.

Should Developers Do QA?

Expanding outward a bit, should developers have responsibility for quality assurance?  And, if so, where do we draw the line in roles?

Again, the answer to this question is yes, developers should have some hand in quality assurance.  In fact, everyone on the team should have some hand in quality assurance, since the team, collectively, makes the product.

There are dedicated people that handle the testing and whose role more broadly falls under quality assurance.  And you can also rope different groups into the mix to help with quality, including users/customers.  (This is a practice known as Beta Testing.)

So with everyone putting an oar in the water to help, the developers are no exception.  Their hand in QA starts by writing good code and automated unit tests (which I’ll get to shortly).  But it also includes being aware of what end users want and keeping them in mind during development.  It also includes using the software that they write (known as “dogfooding“) and making sure it’s of the caliber they would want as users.

Programmers should always have quality assurance at least in the back of their minds.

Should Developers Write Test Cases?

Another question that I see fairly often is whether developers should write what are known as “test cases.”  In their simplest form, test cases are simply scripts for how to test that some piece of software behaves properly.  For instance, a very simple test case for makemeaprogrammer.com might be called “read a blog post” and involve the following steps:

1. Go to your browser and enter https://makemeaprogrammer.com.
2. Scroll down and verify that blog posts appear.
3. Click on the first blog post.
4. Verify that you can read the post in its entirety.

Historically, this responsibility has fallen to the testers.  They execute the testing itself, so it stands to reason that they’d create their scripts.  They also then organize and manage these test cases.

So, given that historical approach, should developers write test cases?

The answer is, counterintuitively, yes.  Programmers should not have sole responsibility for this, but they should participate.  A practice known informally as the “three amigos” says that programmers, testers, and business analysts should all collaborate to write the test cases.  This lets them agree ahead of time on what it means for a feature to be finished and correct.

So developers should absolutely participate in the writing of test cases.

Should Developers Do Support?

Let’s move onto a different concern, typically carried out by a different group of people.  I’m talking here about support.

Take makemeaprogrammer.com again, and assume we weren’t just using WordPress.  As a programmer, I might write the code that drives this site.  Once I was satisfied, I’d release it into production, and you’d interact with the site.

But let’s say you had a problem.

Who would offer you customer support?  If this were a one-person operation, I might.  But at most organizations, someone else would.  And that line of work is known collectively as support.  Programmers write the software and then toss it over the wall, at which point support handles any customer issue that comes up.  Only rarely, if there’s a big, fundamental problem, does it become an issue for the programmers.

Now you’re probably wondering, why do businesses operate this way?

Well historically, the answer is that programmers command a higher rate of pay because they offer a more specialized skill.  You don’t want programmers doing support for the same reason you don’t want them doing the custodian’s job—you’re overpaying for that labor.

But more recently, the DevOps movement has created pushback on this concept.  If programmers have responsibility for support, they have a lot more incentive to eliminate errors earlier and deliver a smoothly running project.  After all, they’re the ones getting phone calls at 3 AM if things go wrong.

So should developers do support?

It’s kind of an open question in the industry with different opinions.  But prevailing wisdom these days says that yes, developers should have at least partial responsibility for supporting the code they build and release.

Should Developers Do Unit Testing?

Let’s close with one last common question.  Should developers do unit testing?  But before we can answer that one, let’s answer a more fundamental question.  What is unit testing?

Well, you can read a lengthy description here, but at the core of it, unit tests are small, automated tests that software developers write to test bits of their code in automation.  They run quickly, are very granular, and let developers know at a glance about the state of the codebase.

Outside stakeholders may have some interest here, mostly wanting to know if all tests are passing or if there are issues.  And sometimes management is interested in metrics about the unit tests, such as one called code coverage in particular.  But mostly this is a programmer-specific concern once you get into any detail.

So now the answer might seem obvious.  Should developers do unit testing?

Categorically, yes.  Unit testing provides myriad benefits to the team, and it’s a technique that’s very developer-specific and developer-centric.  

A Common Theme: Close Collaboration

Throughout all of this, you’re probably noticing a theme.  And that theme is collaboration.

Testing, project management, quality assurance, business analysis, and support are all things that fall outside of the bounds of simple programming.  And yet, programmers are increasingly taking responsibility for pitching in with all of these concerns.

And that’s a good thing!

Programmers are in the business of making software.  And the other roles I’ve mentioned here are in the business of supporting that effort.  But you, as a programmer, are really at the core of it all.  So it stands to reason that you should have a hand in all aspects of the business of building software.

This post was written by Erik Dietrich. Erik is a veteran of the software world and has occupied just about every position in it: developer, architect, manager, CIO, and, eventually, independent management and strategy consultant. This breadth of experience has allowed him to speak to all industry personas and to write several books and countless blog posts on dozens of sites.