[j_barbossa]

> Believe me when I tell you that I could have worked on the entire software myself in 5 months.

I find this way of thinking very short-sighted. It may be true that this application can be written in net time in 5 months, but much more important than writing code is to know clearly what is needed, what users need. Moreover, requirements and wishes change over time. I have seen more than once that months of development time were wasted on something the users didn't need, so good product managers and senior software engineers who question things are often more valuable than engineers who write hundreds of lines of code a day.

[JeremyNT]

I think the problem here is that the company has software engineers sitting "idle" without any good requirements.

I don't think it's uncommon at all. The "hard" part of almost every project I work on isn't the ultimately the code, it's the "soft skill" of extracting a good specification from stakeholders.

What's the reason for the dysfunction here? It could be that the software development team is just overstaffed. Maybe if they had lower headcount, they wouldn't be idle so much of the time.

Of course, it could also be that there are too many stakeholders providing incompatible requirements and muddying the waters, and that there's nobody in a position to make a decision about the real requirements.

I think it's easy for an organization to misidentify an organizational problem as a technical problem, then throw more technical headcount at it while ignoring the underlying dysfunction. And this is how you end up with "bullshit jobs."