3 ms·
On your point #2 - it is true that enterprise software tends to be complex, but this problem is compounded by the fact that enterprises are unwilling to approac
by saikat 16y ago
On your point #2 - it is true that enterprise software tends to be complex, but this problem is compounded by the fact that enterprises are unwilling to approach building/buying solutions to complex problems with a conquer and divide approach. In the consumer/small business world, small, lightweight tools that solve one problem well(think Redis for databases, Etherpad for collaborative editing, etc.) are easier to make good interfaces for.
When it comes to buying software, big companies don't like choosing small, well-designed tools that they can put together to solve a problem because the decision-making process of choosing technology is expensive and time consuming when you are risk averse. At a large financial institution that I used to work at, we spent months going through different third-party offerings of a new data platform. Everyone hates doing it, and it cost a ton of money in developer time (plus some companies actually charge you to do a lengthy demo). So people just tend to gravitate towards the products that are bloated with features and will solve all our problems at once, and we all know what kind of UX these kinds of products will offer.
- nradov 16y agoIntegrating a whole bunch of small, well-designed tools is just as expensive and time consuming. And the final results are often worse.
- saikat 16y agoMaybe or maybe not - my point is just that this is one way you get tools with good interfaces, and it is less likely that you will take this path when you are a large company.
- akeefer 16y agoYeah, you definitely have a point there. While many problems have a high degree of inherent complexity, there are plenty of others that don't need to and that have features bolted on left and right to appeal to every possible market. And it's definitely true that big companies hate making these sorts of decisions, because it's expensive and time-consuming and difficult to undo. One reason a lot of enterprise software gets bloated is that, in order for the market to be viable, it's hard to just target a single niche, so you end up with a superset of features so that you can sell the same market to customers with different requirements. Even in the best case, though, system specialization can be a knife-edge that cuts both ways. Many of our customers, for example, are in a trouble precisely because they have way, way too many one-off systems. They have this system over here that does just workers comp claims, and another system for handling personal auto claims, and another system for tracking notes, and an entirely different system for first notice of less entry versus for actually handling claims, and then most of their commercial business is in yet another system, except for some specialty lines that are elsehwere. Then they have five different policy administration systems, and a couple of billing systems, and each of those talks to a different document production system . . . it's a total nightmare. So sometimes the choice is between having 3 complex systems or 25 purpose-built systems and a total integration and user training nightmare, and both options suck. Basically, as soon as you have a bunch of data that you need to do a ton of different things with, you're left with two bad choices: you can create one really complex application that tries to do everything, or you can create a bunch of smaller applications and end up with a bunch of complicated integrations. Fundamentally, as soon as you have complex data that you have to do a bunch of stuff with, you're going to be in trouble no matter what you do.