Broadly speaking, I think there are two major classes of software.
"Class 1" software is produced under tight budget constraints, often for a cost center. These are the payroll systems, the receivables tracking apps, employee training websites, admin portals, etc. Big consultancies write a lot of this stuff (Deloitte, IBM, etc.) This kind of software is tremendously important, but isn't seen as differentiating by management. "Success" here means (1) it works "well enough" and more importantly, (2) we didn't blow the budget writing it. Cost is always a factor.
"Class 2" software contributes directly to the bottom line of the company. It's produced by expensive, in-house developers who take their craft seriously and want to deliver the best product possible. Budget is defined by P&L and success means "the project will generate a lot of revenue". Note that cost control isn't as big a concern here.
Now, having worked in the industry, I've realized probably 90% (99%?) of all software produced in the world is "Class 1" software. But you really, really want to be working on "Class 2" software; it's better in every way, including attention to quality, willingness to pay developers, etc. For developers, the experience of making Class 2 software strictly dominates Class 1.
As for the article, I've noticed how when management crosses over from one class to the other, there's a lot of conflict. Beware of "operations"-type people working as project managers. You really want line management to be former developers who "get it". It might take moving to a different geo, or working remotely, but just don't work on crap.
Note: as I write this, I realize I'm reiterating a stack exchange answer I saw a while back -- great reading for all developers. http://programmers.stackexchange.com/questions/45776/why-do-...