• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • salvin francis
  • fred rosenberger

Business analyst(BA) vs software developer+BA?

 
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I know that a BA has to get requirements from the client, convert them to use cases and then pass it on to the programmers who will actually create the code. Obviously, this is not a trivial task, but its not too difficult either.
I read books on use cases, uml and similar things and saw that its something I can do well, even as a software developer. Then, why can't software developers be allowed to learn the skills of BA and do the requirements gathering themselves?
Won't it be better because you don't have to have an extra person around?

 
Marshal
Posts: 25594
69
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why not, indeed? At the company I used to work at, we didn't have "business analysts", at least not very much. We had people who talked to the users and designed and maintained systems to support them. Of course it did happen that the more senior people did more talking to users and less writing of code, but that reflected the fact that you can't learn how a large business works overnight. It takes time.

And that's the key thing. If you want to have an environment like that, then you have to have people who stay with the business for several years so that they can learn it well enough to maintain its systems. So having programmers come and go every two years doesn't fit into that environment. That's where the "business analyst" idea comes from, I think -- your person who knows how the garbage truck drivers are scheduled based on their union contract, or how packages are delivered to distant locations, or whatever, isn't likely to up and leave to work on the next great thing. So if you can get cheap commodity programmers to work with them, and they can communicate the programming accurately, then perhaps the increase in head-count isn't such a bad thing. However I don't have experience in that kind of environment so I can't say what its good features are.
 
Tony Jaa
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Paul Clapham wrote:Why not, indeed? At the company I used to work at, we didn't have "business analysts", at least not very much. We had people who talked to the users and designed and maintained systems to support them. Of course it did happen that the more senior people did more talking to users and less writing of code, but that reflected the fact that you can't learn how a large business works overnight. It takes time.

And that's the key thing. If you want to have an environment like that, then you have to have people who stay with the business for several years so that they can learn it well enough to maintain its systems. So having programmers come and go every two years doesn't fit into that environment. That's where the "business analyst" idea comes from, I think -- your person who knows how the garbage truck drivers are scheduled based on their union contract, or how packages are delivered to distant locations, or whatever, isn't likely to up and leave to work on the next great thing. So if you can get cheap commodity programmers to work with them, and they can communicate the programming accurately, then perhaps the increase in head-count isn't such a bad thing. However I don't have experience in that kind of environment so I can't say what its good features are.



Makes sense. I guess a BA's job security would only increase with time as compared to a developer who could be treated like a commodity.
One more thing I was thinking was that BA guys can get the requirements for a new project while the developers are completing the final phases of a previous project. By the time they are done, the BA's give them requirements for a new project.
Looks like an example of separation of concerns to me ;)
 
get schwifty. tiny ad:
Devious Experiments for a Truly Passive Greenhouse!
https://www.kickstarter.com/projects/paulwheaton/greenhouse-1
    Bookmark Topic Watch Topic
  • New Topic