Why?
IMO - Because knowledge work is incredibly hard to encapsulate. And the evolving world of software is even worse. People may move from leadership to high level individual contributor work at the drop of a hat depending on project/company needs - so you don't necessarily want to stick "manager" to anyone. And people should be able to move from one specialty or responsibility to the next without it being either a promotion or demotion within a certain range of responsibility. Since there's no easy to define responsibility or contribution level in any way beyond the relative, it becomes incredibly hard to give someone a title that works long enough to make printing business cards worthwhile.
General term definitions I've come up with:
"software" - makes software. Bugfix, development, software requirements, something where there was no functionality before and after the team comes through there's a new bit of functionality.
"systems" - broader and more eclectic than software. Usually a fusion of disciplines, generally responsible for bigger picture than a single area. Often concerned with how systems come together with users and other key ingredients. May be called the experts of the 'problem domain'.
nothing or "junior" - an entry level engineer - someone with 0-5 years of experience, give or take a few years.
"senior" - capable of working without much (or any) supervision. Knows at least a few major areas well enough to teach others. Knows more than at least some of the other engineers in the company.
"principle" - knows more than senior engineers, responsible (at some level) not just for their own personal improvement but the increase in capabilities of some portion of the overall engineering workforce in the company. Does something major and strategic most of the time.
"developer" - works in a company that actually makes stuff
"support" - does something in the realm of responding to problems - usually customer problems.
"test" - mainly responsible for something in the realm of testing/quality control.
"QA"/"EQA" - really fascinating - in commercial industry, it's similar to someone with "test" in their title. In defense contracting, it's likely to be the person responsible for making sure that engineering follows the process that was promised in the contract. Not the same thing as "product quality", more of a "process quality"
"designer" - does something artsy. Seriously, I usually see this in the softer areas, like where computers encounter Humans, a la "GUI Designer". May or may not have full on software development skills.
"Analyst" - means the company is confused on what this person does too, but they are really smart and should be respected. OK, not really, but it's such a wide range of tasks that it's always fair to ask the analyst what that really means in his industry/company.
"I", "II", "III" - a good case for only being able to define roles relatively. Usually I is least contribution/rank/influence and the higher you go the more important the role. I don't often see much past III.
"Operations" - responsible for something fairly large that is servicing a fairly large number of users who are trying to get something done. I usually find that "Operations" and "Development" are mutually exclusive.
The really sarcastic answer:
Engineers usually get paid good money. The company wants to be able to ask them to just about anything from setting up picnic tables at the company picnic to the hard stuff that requires years of experience and really good judgment. The stuff on the high end doesn't come through every day, more days are filled with easy stuff than hard stuff - especially at the upper levels. So management wants titles to be so vague that no one can argue about the days they are asked to set up picnic tables at the company picnic.
