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.
Just want to thank you for this comment. I've been wrestling in my mind with trying to define the differences between great jobs and not so great jobs I have had, since 'obvious' things like salary/hours/perks/equipment/thing-i'm-working-on have proven to not be a useful correlation. The closest I had come to is "I want to work on companies bottom line, which means I want to work in a company where the bottom line is the software they make" rather than "the bottom line is getting contacts, the software being made is a side effect of that". Your explanation (and the answer in that stack exchange question) captures my thoughts much more clearly.
Maybe you're right and class 2 helps the company care more about quality and actually paying their developers (but if they don't, why do the devs work for them?), but I think I work in a class 2 project, and it's the worst project I've ever been in.
The management is completely incompetent (no clue how a sw project works), so even though they blow millions every year, the project setup, architecture, separation of teams, is all abysmal. The different teams cause everybody to no longer give a damn, because if something is broken, you are guaranteed to never be able to fix it - you'd need to call in lots of meetings first. So we all build up little fortresses that call the other module's services.
I'd differentiate projects as: those where people in charge care about the underlying build quality (call it technical debt, but that's not nearly all of it), and those where people in charge don't give a damn for anything except their current deadline/objectives (doesn't matter if anything of value makes it into the current build).
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-...