Ask HN: Could savvy business analysts replace programmers?
1. some sales team promises the client software with new features/replacing existing features they already have
1. the client agrees to pay for the use this software
1. a team of business analysts works with the client to write technical requirements on what the software should do
1. programmers turn the requirements into code (with help from architects/directors/resource managers/project managers), then deploy it to QA
1. QA tests the code, hoping programmers didn't introduce any bugs or miss any details when translating the requirements into code
1. the code is promoted to an environment where the client can have their own QA team sign off/accept it
1. the code is promoted to production where it is used + maintained + supported
I noticed that some of the business analysts I worked with were very bad. However, some were very good. Some were very technical, but maybe not up to date on the latest and greatest nuances of writing in one of the top 10 programming languages these days. I started wondering if they were given a template that compiled to deployable code, how far could they get in the process of replacing a programmer?
9 comments
[ 1.9 ms ] story [ 32.3 ms ] thread1. backend service - APIs/talking to databases, message queues, or caches/talking to other APIs/doing light data transformation
1. UI - giving the user tables of data/links to other tables of data/giving the user basic CRUD operations around data through backend services
1. batch jobs - hourly/nightly/weekly jobs that perform basic logic over some form of input and generate some type of output/response (lines from a file, database rows, messages from a queue)
I'm obviously playing devil's advocate when I pose this question (along with oversimplifying the entire nature of technical programming work).
If a "savvy Excel" worker or your average technical documentation writer was given a specific plain English format (kind of like a programming language) to follow that compiled to a deployed service (REST endpoint), batch job, or UI page, how far would this get at replacing the bottom 30-50% of programmers? On top of that, what would be stopping this English-to-deployed-code from replacing say, the top 85% of programmers?
I think I'm focusing too heavily on the web development industry (this obviously wouldn't work for something that needs to be performance optimized like a game engine), but I also don't know if that's a bad thing. The web development industry is probably large enough to be solely focused on for the point of this hypothesis.
I'm sure this has been tried before but I don't know what terms to search for to research.
I do also think that once a "business analyst" understands how systems work (pass certain types of request parameters into a function that does filter/map/reduce/calls other functions/loads other data, returns a specific response format), they are pretty much a programmer at that point, right? Maybe the overlap of "people who write technical requirements for corporate software deals" and "people who understand code flow" is very small and I'm proposing something very dumb.
Curious to hear the thoughts of those smarter than me!
Simply changing from programming language to one with a different target audience isn't going to make those responsibilities go away; you'd just be pushing them to people who don't necssarily have the skillset to translate a requirement to the highly strict format that a programming language provides.
Your idea is analogous to saying "if only I created an amazing enough 3D printer, architects would no longer require engineers and construction workers to erect a building". But this ignores the fact that an architect doesn't know the first thing about bylaws, material strength, logistics, rain, etc. In reality, now the architect would be responsible for having the expertise of one or more other prefessions.
I like this counter argument because as a developer, it stinks tracking down bugs. In a perfect world, if the English to code compiler worked pretty well, couldn't the blame of bugs be moved to the business analysts writing the requirements?
> writing tests
if the code does exactly what the business requirements say, why are tests needed?
> integrating 3rd party libraries
a huge portion of programming to me is "calling a function or an endpoint of a 3rd party library". to me, that could very easily fit into the plain English format I'm proposing for this "technology language"
"In theory, theory and practice are the same. In practice, they are not"
In practice, the so called "english to code compiler" is an abstraction, which means more code, which means more bugs, abstraction leaks, complexity, etc.
> couldn't the blame of bugs be moved to the business analysts writing the requirements?
Shifting blame is just avoiding responsibility. Someone still has to be responsible. If what you're proposing is that the BA has to shoulder the expertise of formulating requirements, implementing them, testing them, etc, at some point an organization with half a brain will just hire different people for each responsibility.
> if the code does exactly what the business requirements say
People write tests precisely because code doesn't always do exactly what the requirements say (especially over time, as requirements change and technical debt mounts).
> that could very easily fit into the plain English
This is the old story of "make me a toast". Well, actually, that means opening the bread bag, getting a slice of bread out, putting it in the toaster, making sure it is plugged in, tweaking the timer knob, starting the toaster, waiting, taking the toast out, putting it on a plate, etc (never mind you have to actually buy the bread if you don't have any on hand or wash the dishes if you don't have a clean plate). Similarly: "make me carousel". Well, actually...
So, in a perfect world, formulating the requirements would be implementing them with this "compiler/language/abstraction layer". Does that help make it any clearer?
Sounds more like "becoming a programmer" than "replacing a programmer". shrug
What does this mean? If they aren't up to date with a programming language, how will they make any changes to the ever-changing requirements that are presented? How do they know how to fix a bug that was introduced?
No, savvy business analysts could not replace programmers.
The requirements are the code. Need to change the code? Change the requirements.
> No, savvy business analysts could not replace programmers.
What could replace the bottom 50% of code monkeys then?
;)