Asking a room of programmers about the value of business analysts is going to result in feedback that is heavily biased.
We need not rely upon opinions here, we can be objective instead.
Let's ask how many business analysts without programming skills have made working software. Similarly, let's ask the same of the managers. And finally, let's ask programmers without any managerial or business skills how many pieces of software they've made.
My guess is that the numbers are 0, 0, and a lot. That's because programming is necessary to write software, whereas management and business analysis is only "nice to have". There is lots of great software that was not crafted by managers or analysts; Linux, Emacs, Google search, Facebook, and so on. Most of the stuff designed by product managers is one-off software that will have made no impact other than paying the team's salary for a while.
That's because programming is necessary to write software, whereas management and business analysis is only "nice to have".
That is an interesting philosophy, but it has never been true in real life. Every major corporation in the world has added business analysts and PMs. Even the great technology companies you mention have many, many business analysts.
I love finding exceptions to rules, but I can't find an exception to the rule that if you want to accomplish truly great things with your company, you will eventually add business analysts and PMs.
Small companies will realize that the value of having a marketing professional over a "growth hacker" is when the marketing professional can call a major company and negotiate an ad deal due to their experience doing so. Or when a finance professional can help hammer out terms of a new round of debt financing that allow the company to grow without giving up equity etc.
As a business professional, I understand that hackers have value, but I also understand that even HR people have value. Just because I don't know all the value they have, does not mean it doesn't exist.
This is a cross-industry problem. As engineers, we are trained to find value in concrete products. We see it in software development, as well as in, for example, construction (ask any structural engineer about how architects are perceived)
We tend to forget that, not so long ago, "classical" engineers looked at programmers as lowly-technicians that only used their computers, which were the real valuable product.
But working software does not mean successful software. If it wasn't used, if it didn't helped people or solved a problem, how can it be considered successful?.
ALL of those products/projects you list did required managment and business skills to be successful.
If it wasn't used, if it didn't help people or solve a problem, how can it be considered successful?.
The team got paid. I've written a lot of software that nobody has ever used. It was fun so I consider it a success. Similarly, many clients have commissioned many silly projects that they paid for and never used. (I was once tasked with writing a fourm system for an insurance company's customers, where they could discuss their experiences in having that company's insurance. Despite the software being up to their spec, the project was cancelled because it was a terrible idea. I got paid nonetheless, which could be considered a success.)
ALL of those products/projects you list did required managment and business skills to be successful.
Where's your proof? I'd say that projects like Emacs and Linux are successful in spite of their leadership's social skills.
I got paid nonetheless, which could be considered a success.
Then that's the problem, we mean different things when we say "success". For me, and for a lot of people I believe, "successful software" does not equals to just "the team got paid".
Where's your proof? I'd say that projects like Emacs and Linux are successful in spite of their leadership's social skills.
So, are you implying that all the others were?
Business/Management != Social Skills. I'm not familiar with Emacs history as a product (and I'm not sure if it was "successful" under your criteria), but Linux did required incredible management skills, and a lot of business-savy people for spreading it in the comercial world.
The team got paid. I've written a lot of software that nobody has ever used. It was fun so I consider it a success.
The question that must be asked here is whether your level of fun should be the best indicator of success. It would seem to me that the entity paying the money should be the one to define the criteria for success, and I think it's quite logical to presume that they would not accept the developer team's level of fun as success criteria for what I hope are self-evident reasons. I believe it would also be self-evident why the entity paying the money should be the one to define the success criteria also. In your case's case, they'd probably say the project was an unfortunate failure and waste of money, but maybe worth the try anyway, so oh well (i.e. we were aware that there were risks, too bad the risks became reality).
For open-source projects, nobody is paying the money usually (as they're usually staffed by volunteers), so of course the developers can define the success criteria in those cases.
I agree. Good/Great programmers do it because they like to. They could go a million years and never make any money with the software they write (assuming they don't need to pay bills) because there is value in the process for them.
To the business, even in a software company where development is tier 1, and not a traditional "cost center" and bundled in with IT, development still needs to produce tangible business results. This requires skills that do not directly overlap with development skills.
Programmer: I can build it, I should get paid more
VS
BA/PM: I can tell you what to build so we can attract paying customers and both get paid.
Software is needed. But so are customers. Getting customers is a more valued skill because its the blood of the business. Programming is necessary, but I'd say 95% of the problems needing to be solved are not technology problems.
We need not rely upon opinions here, we can be objective instead.
Let's ask how many business analysts without programming skills have made working software. Similarly, let's ask the same of the managers. And finally, let's ask programmers without any managerial or business skills how many pieces of software they've made.
My guess is that the numbers are 0, 0, and a lot. That's because programming is necessary to write software, whereas management and business analysis is only "nice to have". There is lots of great software that was not crafted by managers or analysts; Linux, Emacs, Google search, Facebook, and so on. Most of the stuff designed by product managers is one-off software that will have made no impact other than paying the team's salary for a while.