5 ms·

There's also an established pattern, the cynical might say, that goes a little like this: 1. Sell product to enterprise. 2. Realize there's more money in cons

There's also an established pattern, the cynical might say, that goes a little like this: 1. Sell product to enterprise. 2. Realize there's more money in consulting to them. 3. Continue development of said product, but now motivated not by ease-of-use or effectiveness, but by how much it can add to your consulting business, resulting in the bloated, out-of-the-box unusable enterprise software that we're all familiar with.

mattmanser 16y ago
I used to work for one of these business and it's nowhere near as nefarious as you make out. In their case at least it happened accidentally and gradually. For example the product starts out simple but grows in complexity, so suddenly you notice the 1 hour install that your consultant used to start his usually 4 day client customisation work with has turned into a whole day and you're now charging for 5 days of consultant time. This leads to the perverse economics that writing an installer, which costs you money in dev time and impacts the development schedule, will actually lose you money. So the installer never reaches the top of the priority stack until it's a real pita as you can recoup the costs compared to the lost opportunity of not working on a new client module. Also it's the client themselves that demand the extensibility of software. It's almost impossible to perfectly model someone's unique workflow in any non-trivial system. Say a client has a risk rating they give every new project. Obviously they want to be able to record that rating in their project management software. And then they want particular directors emailed when that project is moved from tender to won. And then they also want accounts notified. And then they want a team auto-assigned. And then, and then, and then. Enterprise software has to be flexible and extensible for many businesses. Because virtually every business is different. We may mock it, but getting it right is very, very difficult. And many of these businesses end up with consultants just to manage extensibility and tailoring because getting it wrong severely impacts the usefulness, and thus ROI, of the new software. I don't think there's any greed motivation as you seem to paint it, I think a lot of enterprise software started with a good, simple product and then gradually got forced into complexity by client sales requirements, big support contract clients and over promising in sales (quite often by accident). The directors of the company I worked for were proud of their product and genuinely wanted to deliver value to their customers. They did, growing amounts of consultant time was not caused by greed but because every client ran their company differently and so wanted their software to be slightly different. Maybe the 37signals type approach is better, but don't mistake it for a nefarious desire to constantly grow the billable hours.
- petervandijck 16y ago
  (I spent 2 years in the sector, and my employers didn't want to create complex software either. But they did want to make money - optimizing things to take less consulting time, as you say, wasn't always a top priority.) It's not necessarily conscious or nefarious, but the pattern is clear. You can say you don't want to do this, and mean it, but actions speak louder than words, and the incentives are compelling.
  - petervandijck 16y ago
    And as a sidenote, don't get me started on the folly of "modeling workflows". That's one of the things about enterprise software that makes me avoid it like the plague as much as I can.
  - justincormack 16y ago
    Somehow the priorities seem to end up this way. Incentives will out. Problem is the competition dont build that stuff in, so you end up sliding down in comparison, being seen as expensive for bad reasons, not for real reasons that add value, like doing manual upgrades... Then its downhill.
  - abalashov 16y ago
    optimizing things to take less consulting time, as you say, wasn't always a top priority. It only becomes a top priority if you're trying to do more with the same consulting time. With straight hourly billing multiplied by people involved, as is common in enterprise, that's never an issue--in fact, in many cases quite the opposite. However, lower down the totem pole of gullibility lie people who feel burned by the enterprise model and insist on fixed-bid projects, which shifts the risk onto the consultancy. Now the incentives are to get the most done with the fewest people in the least time, at least if you have more work than you can handle. In this situation, automation, installers, scripting, etc. become a big win. There are other business-relevant incentives for this type of automation, of course. The biggest one I can think of is to make the deployment process even "stupider," thus theoretically allowing for the possibility of employing even cheaper people to perform it. The second biggest one is standardisation (removing individual customs and habits out of the install process), consistency, and reduction in human error. On a less directly economic level, some manual processes are so tedious that if you don't automate them, your employees will grow demoralised from having to do them over and over. Lord knows we've run into that one a lot. :-)

mattmanser 16y ago

I used to work for one of these business and it's nowhere near as nefarious as you make out. In their case at least it happened accidentally and gradually. For example the product starts out simple but grows in complexity, so suddenly you notice the 1 hour install that your consultant used to start his usually 4 day client customisation work with has turned into a whole day and you're now charging for 5 days of consultant time. This leads to the perverse economics that writing an installer, which costs you money in dev time and impacts the development schedule, will actually lose you money. So the installer never reaches the top of the priority stack until it's a real pita as you can recoup the costs compared to the lost opportunity of not working on a new client module. Also it's the client themselves that demand the extensibility of software. It's almost impossible to perfectly model someone's unique workflow in any non-trivial system. Say a client has a risk rating they give every new project. Obviously they want to be able to record that rating in their project management software. And then they want particular directors emailed when that project is moved from tender to won. And then they also want accounts notified. And then they want a team auto-assigned. And then, and then, and then. Enterprise software has to be flexible and extensible for many businesses. Because virtually every business is different. We may mock it, but getting it right is very, very difficult. And many of these businesses end up with consultants just to manage extensibility and tailoring because getting it wrong severely impacts the usefulness, and thus ROI, of the new software. I don't think there's any greed motivation as you seem to paint it, I think a lot of enterprise software started with a good, simple product and then gradually got forced into complexity by client sales requirements, big support contract clients and over promising in sales (quite often by accident). The directors of the company I worked for were proud of their product and genuinely wanted to deliver value to their customers. They did, growing amounts of consultant time was not caused by greed but because every client ran their company differently and so wanted their software to be slightly different. Maybe the 37signals type approach is better, but don't mistake it for a nefarious desire to constantly grow the billable hours.

petervandijck 16y ago
(I spent 2 years in the sector, and my employers didn't want to create complex software either. But they did want to make money - optimizing things to take less consulting time, as you say, wasn't always a top priority.) It's not necessarily conscious or nefarious, but the pattern is clear. You can say you don't want to do this, and mean it, but actions speak louder than words, and the incentives are compelling.
- petervandijck 16y ago
  And as a sidenote, don't get me started on the folly of "modeling workflows". That's one of the things about enterprise software that makes me avoid it like the plague as much as I can.
- justincormack 16y ago
  Somehow the priorities seem to end up this way. Incentives will out. Problem is the competition dont build that stuff in, so you end up sliding down in comparison, being seen as expensive for bad reasons, not for real reasons that add value, like doing manual upgrades... Then its downhill.
- abalashov 16y ago
  optimizing things to take less consulting time, as you say, wasn't always a top priority. It only becomes a top priority if you're trying to do more with the same consulting time. With straight hourly billing multiplied by people involved, as is common in enterprise, that's never an issue--in fact, in many cases quite the opposite. However, lower down the totem pole of gullibility lie people who feel burned by the enterprise model and insist on fixed-bid projects, which shifts the risk onto the consultancy. Now the incentives are to get the most done with the fewest people in the least time, at least if you have more work than you can handle. In this situation, automation, installers, scripting, etc. become a big win. There are other business-relevant incentives for this type of automation, of course. The biggest one I can think of is to make the deployment process even "stupider," thus theoretically allowing for the possibility of employing even cheaper people to perform it. The second biggest one is standardisation (removing individual customs and habits out of the install process), consistency, and reduction in human error. On a less directly economic level, some manual processes are so tedious that if you don't automate them, your employees will grow demoralised from having to do them over and over. Lord knows we've run into that one a lot. :-)