3 ms·
> I've pointed out before that the job description of "Systems Analyst" seems to have disappeared i.e. someone who's job it was to understand and describe requi
by rualca 6y ago
> I've pointed out before that the job description of "Systems Analyst" seems to have disappeared i.e. someone who's job it was to understand and describe requirements.
If the role of "systems analyst" died, it's murderer was the legion of arrogant developers who, armed with their weaponized Dunning-Kruger blend and personal belief they are the perennial 10x, criticize systems analyst and architects and principal engineers and any role whatsoever that involves designing and specifying system architectures as being always and invariably played by incompetent fools who are lesser beings than the flawless and perfect dev and never do anything right. Repeated often enough, this flavor of anti-intellectualism, which advocates that a constant churn of ad-hoc solutions to the problems they created for themselves, is naturally better than any attempt at a rational design based on requirements.
- antonvs 6y agoBoth their one-sided blame story and yours are likely to be just as wrong. There's no question that many people in systems analyst or architecture roles, that are divorced from the details of actual development, came up with flawed designs that were more work to implement and produced worse results. That was one of the antipatterns that Agile was a reaction to. The problem with those roles is that they tended to be embedded in a waterfall architecture model, where system development involved some variety of requirements -> analysis, architecture & design -> development. The amount of interaction and iteration between those phases was often much lower than it should have been. There are many factors involved here. Simply having different teams for those functions is one of them, since that tends to reduce interaction between the phases.