A look into how software developers are taking on more responsibility, and what this means for traditional tech roles

Historically, IT departments have been structured across lines of technology, such as the app, UX, and database teams. More recently, the 2-pizza DevOps team has emerged and evangelized restructuring around lines of business. A single team is now responsible for a particular business capability end-to-end. This has ushered in the era of the full-stack developer – an engineer who can contribute to any facet of the system. DB connection lost? The dev is looking into it. Infrastructure down? Dev is on it.
As the scope of responsibilities of developers broadens, what is left over for classical technology jobs like BA/QA/DBA? In the DevOps era, do they still have a role to play?
The Business Analyst
The Business Analyst is a hybrid role between users and the technical team (ie. developers), described by CIO.com as follows:
Business analysts (BAs) are responsible for bridging the gap between IT and the business using data analytics to assess processes, determine requirements and deliver data-driven recommendations and reports to executives and stakeholders (source).
According to the Bureau of Labor Statistics, the BA job outlook is projected to grow 11% over the next ten years. Despite such growth, many developers consider the BA role outmoded and largely superfluous after the DevOps renaissance.
The case against BAs
The case against BAs is perfectly summed up in this classic scene from Office Space.
The BA job is inherently difficult. They are middlemen between technically competent developers and domain-competent users. Somehow BAs are expected to match the expertise of both, intercede in their direct communication and conjure extra value out of thin air – yikes.
When a BA is bad, and often the organization is at fault here, the BA transforms into the RELAY. In other words, the BA simply deflects all user questions onto the developers and vice versa. It’s quite annoying for a developer to send an email to the BA, only to have it cc’d verbatim. It’s even more annoying when the email lacks context, screenshots, or any other obvious information that the BA should have captured. When this recurs, I just converse with the users directly.
The case for BAs
At this point, you’re likely thinking "why don’t devs always talk to the users?". And sure – that is an option. In startups, for example, there may be no reason to have BAs. But as organizations, applications, and teams grow, the feedback loop between developer and user grows too. Sure, one-off chats with users are fine, but how much time can actually be spared for this? For example, do you routinely set up calls to review feature requests with dozens of users? A good BA should spend hours a day talking to dozens of users, establishing a network and rapport. In this manner, BAs gain a big-picture understanding of the system, for example, that a screen works well for one team but not another. Only after they’ve curated this information should they then hand it off to a developer. Developers should be involved in discussions with BAs and users, but only in a pre-planned and systematic way.
As developers, we aren’t always sensitive to just how expensive a resource we are. If a dev is earning $120k/year and a BA is earning $60k, then it certainly makes sense to offload as much non-technical work to someone else. Furthermore, the negative impacts of too much context-switching drastically hinder dev productivity. And finally, this may be shocking, but many devs simply aren’t that good at user relations. I’ve met many who downright think their users are stupid. One time on a job interview, my interviewer told me point blank that the users of their internal SAAS platform were idiots, despite most of them being PhDs. It’s hard to comprehend the delusion required to conclude that a team of PhDs is stupid rather than that your software sucks and is not user-friendly.
The Database Administrator
The role can be summarized as follows:
A database administrator (DBA) is the information technician responsible for directing or performing all activities related to maintaining a successful database environment. A DBA makes sure an organization’s database and its related applications operate functionally and efficiently (source).
From the Bureau of Labor Statistics, the ten-year job outlook from 2019–2029 is projected to grow at 10% – less than the other roles discussed, but still more than the national average.
The Case against DBAs
As most of the industry migrates into the cloud, the amount of overhead to administrate a database is rapidly declining. In the video below, for example, a Postgres database is spun up in GCP in 5 minutes. Additionally, cloud offerings have identity and access management solutions baked in. As developers gain more responsibility at the data/infrastructure level (ie. the back-backend), they begin questioning why a dedicated role or team is required for data operations.
At a previous job at a big bank, I spent two months trying to get a Mongo instance spun up for a new application. A bureaucratic DBA fought me every step of the way. At one point, he even insisted my application did not need write access to the DB. How can an application work if it can’t write to the DB!? In the end, he ghosted me for two weeks and I found out later he was on his way out of the company and had mentally checked out. This experience prejudiced me against DBAs for years to come.
The Case for DBAs
While developers typically know enough about infrastructure and SQL to build stateful applications, a good DBA brings broader knowledge and perspective. DBAs typically are experts in SQL and can help developers optimize queries and DB-related tasks. However, there is much more to a database than queries. As application developers, we sometimes forget this.
For example, a DBA once proposed a trigger function as a solution to a thorny problem. Until this point, I’d never even heard of a trigger function. Another time we had to restore an old table from a Linux server backup without bringing the production version down. To do this without choking out DB resources took considerable care and expertise by a DBA. We simply don’t give DBAs enough credit for all the tasks they do beyond writing queries.
Finally, let’s not forget the Cambrian explosion of data tech over the last decade. Consider the myriad of DB engines (CouchDB, RocksDB, Aurora, etc…), as well as advances in Data Warehousing (ie. Snowflake), AI, and Data Science. It’s hard to overstate the value of data expertise in this new world.
The Quality Assurance Engineer
The QA engineer is a technical person who ensures that the software being released is ready for end-user consumption. From the article, "What Does a Software Quality Assurance Engineer Do?", their responsibilities, to name a few, include:
- Find new and pre-existing bugs (regressions)
- Perform manual and automated testing
- Review user interfaces for consistency and functionality.
Because of the overlap in responsibility between QA and developers, separate wage statistics were hard to come by. In fact, this overlap forms the core case against the QA engineer.
The case against QA
A common view of QA engineers is that they are simply "testers", or at best, junior developers. They find bugs and run tests, often manually (gasp). Well, shouldn’t software developers should be writing automated tests and finding bugs themselves? When bugs make it into production, it is ultimately devs who accept the blame and responsibility of fixing anyway.
Furthermore, the QA process slows down the release cycle. This can be frustrating when a simple feature takes a few hours to develop, but then sits awaiting QA for days. Often requirements are unclear (ahem BAs), and so QA may test the wrong thing, report non-issues, or simply require a lot of hand-holding. When the QA process is impaired this way, devs will inevitably adopt the mindset of I’ll just test it myself.
The worst QA experience I ever had was in 2015 when our QA team was offshored, and there was only a brief time zone overlap. They’d call us first thing in the morning before we’d even gotten coffee, and go through a spreadsheet of outdated manual UI regression cases. 95% of the issues were unrelated or irrelevant, and the entire process became a frustrating exercise in futility. It prejudiced me towards QA teams for a long time, when really the issue was one of communication.
The case for QA
The case against QAs is valid; however, it contains a couple of assumptions. First, the idea that everything can/should be automated makes sense for greenfield projects. But in practice, especially at large companies, most software is legacy and lacks test coverage. Furthermore, the original developers may be long gone, and most knowledge about the system resides in the QA team. In this case, the QA team will be able to provide invaluable context, perspective, and ideas about the system.
A second assumption is that QAs job is just to find bugs. But really good QA engineers can often identify user traps that transcend code. For example, while a new button may be working fine, QA could realize that some users at the company use lower resolution monitors. In the compact view, the button could easily be clicked on by mistake while copying the text next to it; they’ve seen it in the past. That’s not exactly easy to capture in a unit test…

Let’s also challenge the assumption that automated testing can obviate all bugs – consider the following points.
- Some changes don’t even need testing. For example, certain UI changes can easily be validated by a person but are hard to automate. For UIs with high churn and mostly aesthetic changes, the test suite is a velocity drag.
- Some things can’t be unanticipated. There will always be aspects of a system that are unpredictable. Code reviews may help, but there’s no substitute for an actual person applying pressure. A good QA person will still turn up all kinds of stuff. Have you ever been impatient and insisted to the QA team that your feature is fine and just a basic change, only to have them turn something up? I’ve sure felt that that egg on my face.
Looking to the Future
Will these roles persist?
As the industry continues towards DevOps and Cloud, these fields will thin out. Each of the roles will trend towards more of a specialization, especially the DBA, since the operational overhead of maintaining a DB is rapidly decreasing. They’ll last longer at big companies, but the tolerance for lower performers will drastically decline. However, simultaneously the demand for data expertise will keep accelerating as shown in the forecast below. Growth in warehousing and data science should ensure data specialization remains lucrative, and DBAs are well-poised to transition.

Of the three, the BA role seems safest. The average software developer simply does not have the time (nor often capabilities) to maintain the social network of a strong BA. However, as more companies migrate to DevOps/Agile, the feedback barrier between users and developers will continue to shrink. As it does, BAs that are not technically competent will be pushed out.
The QA role is the hardest to predict. As automation improves, demand for QA persons to run manual scripts and "catch bugs" will disappear. However, modern systems’ growing complexity and performance demands mean quality assurance is more important than ever. For many SaaS companies, even minor downtime is damaging. Slack was recently down for an hour and it made the news. So talented folks who can spot UI traps and deterioration will stay in demand. Whether QA remains a bonafide role or diminishes to specialization is hard to predict.
Regarding the Prejudices of Developers
If you’d asked me two years ago about these roles, my mindset would have been "don’t want em don’t need em". I had just left a stuffy bureaucracy for a startup that consisted of only developers. It seemed like a utopia by comparison. However, when I lost the job due to Covid and transitioned to a mid-size company, my prejudices were laid bare.
In the new job, the BA/DBA/QA persons were quite helpful. Looking back, I realize most of the past friction was attributable to the following:
- Fractured communication (eg. teammates working across oceans).
- Restricted responsibility, such as BAs who can’t do DB queries or QA folks who aren’t able to view/run code.
- Lack of buy-in: good teams win and lose together, regardless of roles.
Finally, software developers tend to think they can do any job themselves. They can wear the analyst hat, but the inverse is usually not true, and this asymmetry feeds the ego. It’s important to remember that just because we can do something, it may not be cost-effective to do so and we’re probably not as great at it as we think.
What do you think? Got a different take; did I get it all wrong? Leave a comment and let me know.