I love Joel on Software, but this article about Development Abstraction is a little biased. It's great from the programmers' point of view-- put the programmer on a pedestal and give him everything he needs to get his job done. The reality is even in a software development company the programmer isn't the most important job in the hierarchy. Joel says it best himself that "The level a programmer works at (say, Emacs) is too abstract to support a business."
Why shouldn't it be the goal to remove impediments for every job role in the company? If that's not possible, there must be a balance so that the most needs of all employees are being satisfied. In my experience, most programmers are too myopic to direct the course of development. When it comes down to it, the best software solves the user's needs. Who knows best what those needs are? Not the programmer, who never deals with the user, and is likely on a much higher level of technical aptitude than the user.
Outside the company, it's the users themselves who should be on this pedestal. All functions within the company should cater to the users' needs. Within the company this falls on those that interact directly and translate those needs into functional goals. A more sensible heirarchy would be something like User Experience Analyst > Information Architect > User Interface Designer > Programmer. You could substitute any number of job titles, but that's the basic flow. Not that programmers are at the bottom of the heap-- I'd still put them above sales & marketing, management, human resources...but putting the programmer at the top is like suggesting that a mechanic can best design a car for human comfort.
Comments