20 ms·

I think this gets it wrong. The real reason enterprise software sucks is that enterprises have complex and unique workflows and would prefer to buy software tha

I think this gets it wrong. The real reason enterprise software sucks is that enterprises have complex and unique workflows and would prefer to buy software that they can fit to their workflow rather than change the workflows of their profitable business with tens of thousands of staff who will need retraining. If you look at all of the most successful software of all time they are the complete antithesis of the Unix philosophy that so many designers and developers prefer. Word, Excel, SAP, Photoshop, Salesforce, JIRA. People hate them because they are complex, configurable, and have 1000 features. But that's the same reason they can sell into law firms and oil refineries and animation studios and all those other very diverse businesses. And most enterprise software sucks because 1) writing complex, highly configurable software is hard and 2) very few companies have the billions of development dollars the above handful of companies have to throw at the problem to try to make it tractable. That the end user isn't the purchaser isn't going to change that fundamental reality that businesses are complicated.

hyperpape 7y ago
I would say yes and no. It's true that enterprises have complex and unique workflows, and that this drives the complexity of enterprise software. What I doubt is that this complexity is actually adding value in most cases. There is a nice equilibrium where companies adopt simple best practice workflows for non-core competencies, and vendors compete on how effectively they can implement those simple workflows. In reality, we're stuck in the equilibrium where companies cling to baroque workflows for everything, and vendors compete to support those workflows, sacrificing ease of use, implementation time, and agility.
- PeterisP 7y ago
  Thing is, enterprises have multiple incompatible workflows but still need to make it work. I.e. due to mergers and acquisitions different parts of the company have 3 different, incompatible IT workflows for part procurement. Of course that's bad and a single system is highly desired - so the company is working on it, and within a year these three workflows are going to be combined in a single system. Naturally, that system isn't simple as it needs to combine the peculiarities of these three workflows. Of course that's bad, and a single simpler workflow is highly desired - so the company is working on it, and within 2-3 years the processes are going to be adjusted and unified so that there's a reasonable single process. However, there's another acquisition that's going to be finalized soon, and during these 2-3 years at least one more is going to happen, so by the time these workflows are unified and simplified, they will be joined by new parts of the company using different workflows, and the enterprise will be back to square one with 3 separate systems with incompatible workflows for doing the same thing.
  - hyperpape 7y ago
    Oh, I'm aware. I work in enterprise software. I see what the customers want. I've also been on the receiving end: my company has one tool that doesn't work well. So for three years, there's been a push to get rid of it, but there's never been agreement on any replacement. There's one particular use case that stakeholders think isn't handled by the replacements. The result is that we use both tools, and manually synchronize them. Someone wrote a bespoke automated tool to bridge those two SaaS apps, but it doesn't remove the manual synchronization, just reduces it. Oh, these tools? They aren't for something low touch. People are in both tools constantly. There are questions about which pieces of information are accurate, and who's responsible for which updates. The time waste is significant. But the problem isn't the software. The problem is that people can't make a decision. When you ask someone higher up, you get vague assurances that we're still thinking about the issue. In the case of the companies with their mergers, having one tool support both systems isn't doing anyone any favors. It just lets them limp along with excess complexity.
- zerkten 7y ago
  > In reality, we're stuck in the equilibrium where companies cling to baroque workflows for everything, and vendors compete to support those workflows, sacrificing ease of use, implementation time, and agility. Enterprises are setup to support all of these baroque workflows and that's where most of the value is derived. However users and the business don't get that value, and the project to replace the previous one will deliver "value" to IT stakeholders. The cycle repeats. You have enterprise architects who in the worst case are creating uncertainty by supporting different factions and introducing new tools which interest them versus meeting goals for the company. IT outsourcing vendors are responsible for the implementation and frequently do a less than stellar job. Security are split between trying to keep tabs on how the outsourcer is running things, while trying to limit how much damage business areas do by just delivering their own solution with SaaS or a small vendor. This is a real mess that requires huge amounts of energy, and is hard to fix because everyone is doing pretty well from it in their own way.
ch4s3 7y ago
People love excel and Photoshop. I’ve never met any heavy excel user that prefers any other spreadsheet software or even has anything negative to say about it.
- fasicle 7y ago
  Yeah me too, I find MS Word very useful too tbh. Not sure why higher level comment thinks people hate them.
  - sam_lowry_ 7y ago
    Try to use the French version of Excel, and you'll understand. They renamed function names. Everyting. Not a single word makes sense anymore.
    - throwaway744678 7y ago
      I switched the language of the OS on my computer for this very reason. This is idiotic.
    - mattkrause 7y ago
      Wait, really? As in '=somme(A1:A10)' to add a column?
      - Udik 7y ago
        Yes, same in Italian, and I guess in every other language. It's dreadful but probably once you memorized all your favourite functions is quick to use. It's definitely not a tool for developers.
        wolco 7y ago
        People have asked for this or the Spanish version of Angular or Russian Java. If I only spoke those languages I might want that as well. Surprised no one has tried to introduce this into popular programming languages.
SomeOldThrow 7y ago
> The real reason enterprise software sucks is that enterprises have complex and unique workflows and would prefer to buy software that they can fit to their workflow rather than change the workflows of their profitable business with tens of thousands of staff who will need retraining. Bingo—the dysfunction of the software reflects the dysfunction of the organization.
- astura 7y ago
  I have my doubts that "complex unique organizational workflows" automatically means "dysfunctional organization."
  - SomeOldThrow 7y ago
    And it would be ludicrous to interpret me that way! The part that implies the dysfunctional organization is “enterprises”.
- Goladus 7y ago
  No, it can just be one or two bad decisions that cascade and wind up being hard to get undone. The decision might have come from a committee or might have come from a single executive that turned out to be a bad hire.
felideon 7y ago
You raise a good point, but it doesn't mean the OP is wrong. There is an inflection point where, even if the software was originally designed with a target user (persona) in mind, the features that keep getting added are designed for the buyer. It is impossible to design software that works for wide set of personas. Melissa Perri calls it the Build Trap: https://www.mindtheproduct.com/escaping-build-trap-melissa-perri/ https://www.mindtheproduct.com/escaping-build-trap-melissa-p...
dredmorbius 7y ago
That sounds like a Conway's Law, but of large purchasers, rather than of software developers. https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
investinme 7y ago
Nobody hates Photoshop. In fact it's one of the most loved software out there. I'm a developer and a Photoshop user and love it. The Unix philosophy would be a disaster for a image editing software (ImageMagick much?) Once a developer who spent all day in VIM & co was honestly arguing with me that Photoshop should be a command line app. I filled that under "shit developers say" and "delusional".
- dredmorbius 7y ago
  Not so much in Venezuela right now. And, FBOW Linux has the Gimp, which I prefer to Photoshop, though that's largely on account of familiarity. ImageMagick itself is invaluable when what you need to do is programmatically change large numbers of images. I've seen it used on large (multi-million user) image-heavy sites as the standard image handling flow (thumbnails and default previews of standard sizes).
  - investinme 7y ago
    That was exactly my point. ImageMagick and Photoshop serve completely different needs. You can't replace one with the other.
  - pier25 7y ago
    > Not so much in Venezuela right now. Yeah but that's not because of the software itself.
    - dredmorbius 7y ago
      It's definitely a consequence of the software's implementation.
- kragen 7y ago
  It's strange that someone who spends all day in Vim (which is not an acronym, by the way), an editor driven by keystrokes rather than the command line like ex or edlin, would prefer a command-line Photoshop. I'm not saying you're lying but maybe they misspoke or you misremembered. A keystroke-driven Photoshop might be something like Blender. I think netpbm is more Unixy than ImageMagick. I've had good experiences with it, especially for images bigger than my RAM, but a paint program it is not.
jasode 7y ago
>Word, Excel, SAP, Photoshop, Salesforce, JIRA. I'd refine your examples somewhat. The author's idea of "enterprise software" would be more like SAP/Salesforce/JIRA. A client-server model type of software (data lives in big central corporate databases) instead of being documents-oriented (user data lives in files like .xlsx, .docx, .psd). In contrast, the other desktop software of Photoshop/Word/Excel is often bought by consumers outside of enterprises because that's the software they prefer. (E.g. artists buy Photoshop instead of using GIMP.) And in the workplace, a lot of analysts like using MS Excel.
- airstrike 7y ago
  In the workplace, people like using MS Excel because the alternatives are ridiculously inferior
  - v77 7y ago
    Yes, I certainly wouldn't call Office enterprise software.
  - collyw 7y ago
    I would say that its because people understand how to use it. Excel is frequently used as a database, not because it makes a good database but because people don't understand how to use Access (or any other relational database) but Excel is easy enough that they can get something usable.
    - airstrike 7y ago
      That's part of it, but not all and also not the most important IMHO Excel clones simply don't cover the breadth of functionality provided by the OG, not to mention key UX features like countless hotkeys and menu accelerators Every Excel user understands Google Sheets. They just don't like feeling like they're strapped to a wheelchair
    - vetinari 7y ago
      Often they understand Access, they just don't have it. Office Standard and Home & Business SKUs are without it, you need Office Professional Plus. Because it costs few hundred more for just Access and Skype, most workers will get the Standard one.
maxerickson 7y ago
What if the Unix philosophy is accidentally successful just because it encourages the design of effective tools? (with the separation of concerns not really mattering in the usage of the tools)
khendron 7y ago
What you say sound more or less the same as what the Twitter thread says. Enterprises with complex and unique workflows come to a software vendor with a checklist of features, and complex highly configurable software checks all the checkboxes. It doesn't matter that the software is almost impossible to use. For some reason, usability is never one of the checkboxes. The root of the problem is that the people holding the checklists are not the same people who have to use the software. Which was the point of the Twitter thread.
Juliate 7y ago
The thing is ... very few companies do actually use all the complex configuration of said purchased software. Rather, they are stuck with it. And deal with it, limiting the contact surface, until they cannot bear it anymore, and spend more to upgrade/get some consulting to have the solution reorganized for them. On one hand, you have purchase departments that are not the target users, and decide only based on paper reports, what to purchase. Losing the run from the start line. That's a given. On the other hand, you have those who prefer to outsource the understanding of their own workflow/tooling/business, that could leave them somehow unique and different, to some outside flexible product that claims to solve that (and that meets this and this requirement from that body & that set of laws), but still requires armies of consultants to make it work properly, although it does not cover really your use case, so you better adapt your way of work to what "they" say is good (got Agile anyone?). Why? Because regulations. Because market/business standards. Financial due diligences. And why would they not prefer that? They (anyone, we) do not care. We are not paid to care for that. Or rather, we get rapidly burnt for caring. That's like the entropy law for software & processes in enterprise in general. Oracle, for instance (but that's valid for so many, if not all, enterprise-targeted solutions), didn't sell itself based on technical merits, you know. Business are complicated, yes. And they get even more complicated because of people lacking of the courage to say fuck you to the salesman.
- basseq 7y ago
  > The thing is ... very few companies do actually use all the complex configuration of said purchased software. That's the point, though. Enterprise software is a superset (E) of all features that a large group of very diverse customers need. An individual customer has a need for a much smaller set of features (C). That enterprise software may very well be the best software that includes all those needed features: C ⊆ E There are niche providers, so a logical customer would select the software that meets all of their needs and as little else as possible. But there may not be a niche provider that meets that criteria. So as an individual customer, you may be stuck between an Enterprise software that meets all your needs, but is "more than you need" and a niche software that doesn't meet all your needs.
  - 7y ago
pier25 7y ago
> Word, Excel, SAP, Photoshop, Salesforce, JIRA I agree about SAP and JIRA, but the other ones are IMO universally loved. I've never found a designer complaining about Photoshop which is the holy grail for bitmap work.
mr_tristan 7y ago
It's not just organizational complexity either; sometimes it's just scaling concerns. And sometimes it's not your original target market. One company I worked for had Google as a customer when it was very small, and of course, as Google grew like a rocketship, used the product at a scale well past where it was used by anyone else. And then comes subtle little features to help them manage it at their scale. At one point, I think there were around a hundred "secret" undocumented options and another hundred "super secret" options. Needless to say, complexity is just something that has to be managed, and there are always rational "business justifications" for practically everything. The complexity often isn't designed; it's just brought in one step at a time from a variety of places. And _that_ usually ends up in a pile of crap.
SquishyPanda23 7y ago
> they are complex, configurable, and have 1000 features. If enterprises were selecting for this then you would expect emacs to be the most used enterprise software of all time. :-P
Crinus 7y ago
> they are the complete antithesis of the Unix philosophy that so many designers and developers prefer. Word, Excel Interestingly, Word and Excel were the origins of OLE in Windows 3.x times that was meant to allow embedding documents of one application inside another so that each application can focus on doing one thing well. The original documentation even explicitly wrote something along these lines. I always thought that OLE was basically Microsoft's attempt to bring Unix's "do one thing well" composability to GUI applications. (things changed considerably with Windows 95 and COM though and that part about doing one thing well was removed)
wikiman 7y ago
In my experience with most Enterprise software, the problem isn't the number of features it's the total lack of discipline in deciding what features are actually needed. Jira is the worst at this because people throw spaghetti at the wall until they get something that "works" for PMs but nobody else understands. I've worked at exactly one place that really was careful about JIRA and what made sense from the tool and it was a joy. I imagine the same is true of Salesforce though I've never seen anyone actually pull it off
blantonl 7y ago
very few companies have the billions of development dollars the above handful of companies have to throw at the problem to try to make it tractable. 95% of "enterprise software" is typically a small developer team of 5-10 people that delivers a product with some features, usually developed in and around J2EE, CORBA, COBOL, etc. It's then sold and supported by a marketing, sales, conference, booth, and sales engineering budget of billions of dollars. Haha! The other 5% of enterprise software is what you described above. :)
- ian0 7y ago
  On point! And so begins the large IT company lifecycle... - Those hundreds of sales engineers weave a spaggeti junction of pseudo products around the core application to suit the whims of the C-level clients and their buzzwords of the month - The company gets frustrated when this begins to break down leading to sales delays and embarks on a disasterous rearchitect which pits the sales engineers (microservices!) and core engineers against each other. - The sales delays lead to cost cutting and the old guard make a timely exit with a nice package. The laid off sales engineers get a better gig due to the buzzwords on the cv. - At some stage in the old guard are brought back to maintain the old core that is still running the company, but now charge a hefty consultant rate.
swalsh 7y ago
Sometimes I wonder, what if we just fundamentally took a new approach the OS. Today at the root of your operating system is the file system. It would be interesting if the file system was changed to essentially the concept of a simple object store. In much the same way we have "standard file formats" today, we could move to something like a "standard class". Objects would be a first class citizen in the OS. I think this becomes more interesting too if you start to ignore where the object lives. It doesn't matter if an object you care about is local, or on a server in your enterprises network, or if it's a thousand miles away. The second big change, is I would do away with "applications". opting instead for a smaller unit of executable. Probably integrated with the object system. The idea here is you don't buy an entire system from a single vendor. You buy features from multiple vendors... and the design of the OS makes it really easy to integrate together. I guess this is kind of the unix philosophy... but maybe taken to the next level. Thirdly, I think it would make sense if the system was natively "reactive", I think that would help with making aspect-oriented programming more normalized.
- journalctl 7y ago
  Filesystems that abstract away things like directories aren’t new, they just haven’t been commercially successful (I believe Vista was going to include WinFS, which was a database-like filesystem, but it was scrapped). It’s not that systems research has suddenly stopped, it’s that it’s really really hard to not only introduce radical ideas to the public, it’s also hard to make sure you don’t break existing billion-dollar systems at the same time. And as anyone who’s had the misfortune of using a network share over a flaky connection can tell you, abstracting files away over networks is tricky business, and when your connection fails (which it will), that abstraction breaks.
- joncp 7y ago
  > do away with "applications". opting instead for a smaller unit of executable This sounds a lot like Android's "activities" concept which doesn't get enough love, in my opinion.
  - amenod 7y ago
    This! Also the concept of Intents is pure genius.
_pmf_ 7y ago
SAP sucks companies dry.
xivzgrev 7y ago
This makes sense. Given my experience in tech startup land, im going to take a stab at how this happens from inside the company. Lets say you are starting sn enterprise saas company, woohoo! You have your initial product and customers love it, yes! Things are starting to hum along nicely. Now your sales people are identiying new markets and saying “hey if we add feature x and y, we can make $x million more per year from x y and z clients”. At this critical juncture, managwment most likely approves and has UX involved, but adding the features will be the priority regardless. Theres no overrulin g UX voice that can say “no, dont build that feature because theres no way to maintain the delightful user experience” because MONEY IS ON THE TABLE! Execs got revenue goals to hit, sales people have revenue goals to hit, and this seems like a match made in heaven. Additionally, its important to point out that pioneering companies dont know all the end state user flows at the beginning so they are hacking along, reacting as they learn more about end customers. Now fast forward a decade. The software is bloated but has grown a lot. Users hate it. New startups look at your product, your end customers, and say “hey! We can do this more simply and steal their customers”. And they can, because they have the advantage of starting from the ground up, KNOWING THE CUSTOMERS and their workflows. So of course they can build a more efficient product because they have the clear end vision - your product, but with the bloat cut out. Your team has already done the hard work of identifying the best and largest customer use cases. So what’s the solution? Acquire these upstarts or make your company a platform. I dont what blackboard has done here but salesforce is still by far the largest game in town despite universal hate. Why? In large part due to the vast network of 3rd party developers who can configure salesforce to a customer’s complicated workflows. They’ve actually taken this problem (it’s complicated to use) and turned it into a retention feature. No wonder they have a giant skyscraper in san francisco.
- vgetr 7y ago
  This makes sense to me. Sometimes it’s not even about more money but existence entirely. Seeing as that VisiCalc was _the Spreadsheet_ up until Lotus came along and ate their lunch, it’s easy to see that sometimes features and other external forces may have more of an impact than the raw popularity of a product in the end.
- dmix 7y ago
Spooky23 7y ago
Exactly. They also control the workflow. If you don't like the 15 steps it takes to update your expense report, good for you, you won't get paid. Companies will lose deals unless they do what customers want. Eventually, that chunks up the software and makes it awful. That's just the nature of the beast, and it's no different than things were pre-computer. I had a .gov customer that had a very specific ruleset about stapling paper forms a certain way, which impacted how certain processes worked after they were computerized. Nobody understood why, then we found out -- in a tragic accident, a key employee in one of the paper processes in the 70s lost an arm. They ended up stapling things a certain way to accomodate his constraint and optimize throughput. The practice spread to other areas. 30-40 years later, after the employee was long retired and dead, the process lived on. In the case of something like Word, people who write need to do stuff. I probably use 30% of Word features, but in the 2 times in the last decade that I needed to create a document with a table of figures, it's there.
- corebit 7y ago
  This story needs a write up! I'm fascinated!
  - Spooky23 7y ago
    Someday I’ll write a book or something. There’s a deep well of crazy stories like this that I’ve run into!
    - polymatter 7y ago
      please do
- maerF0x0 7y ago
  There's a similarly apocryphal story about cutting the ends of ham off. https://sixsigmadsi.com/grandmas-ham-a-story-of-cultural-training/ https://sixsigmadsi.com/grandmas-ham-a-story-of-cultural-tra...
  - 7y ago
ThomPete 7y ago
Exactly or put another way. Companies only use 5% of the features the more sophisticated enterprise software is offering but it's a different 5% each of them use.
Goladus 7y ago
> The real reason enterprise software sucks is that enterprises have complex and unique workflows and would prefer to buy software that they can fit to their workflow rather than change the workflows of their profitable business with tens of thousands of staff who will need retraining. This is the nominal reason executives responsible for inflicting terrible software on their workers tell themselves. But it's not always true. In fact it may often not be true. In many cases the assumptions about how much training is necessary to use the software are all wrong in the first place and the only reason so much training is required is because they chose such terrible software in the first place. > People hate them because they are complex, configurable, and have 1000 features. No, in fact it's often that they LACK features and are NOT properly configurable, because they are simply bad software from the very core. You often have a rigid and unwieldy platform with features inelegantly bolted on by underpaid programmers to satisfy corporate buzzword checklists. The end-user experience is furthermore left for last. So not only are you trying to design a UI on a garbage platform, it's your lowest priority. So worker efficiency takes a hit, a hit that you can't measure so you just dismiss and issue beatings to anyone who doesn't use your awfully-designed software effectively. For a real-life example: Good Trouble Ticketing Software designed around trying to help teams track work and be more efficient: Request Tracker from Best Practical. Bad Trouble Ticketing Software nominally designed around being "ITIL compliant" and providing nice reports to management, but is actually just really large badly designed CRUD: Service Now.
rossdavidh 7y ago
I think this gets it fundamentally correct, although your point has some validity. But the reason that enterprises often wish to pay for configuration of the software instead of changing their own workflows, is that one of these requires no work from them (the decision makers), and the other does. Much of what is called "enterprise software" is actually more like a proprietary programming language or framework, which you will have to pay specialists to program your application in, with bad debugging tools. Lastly, Oracle and SAP and etc. aren't actually good at the problem you describe, as attested to by the many users who hate their products. They're just good at selling their software to the decision makers (not the users).
ridaj 7y ago
No, this does completely get it right. Enterprises thought they needed all the control and security features of Blackberry until the iPhone came along and made the UX gap unsustainable. Enterprises thought they needed on-premise hosting of Exchange, Office and SharePoint instances under their control for email and productivity, until GSuite came up with a better, less configurable user experience based on consumer features that is making inroads in the market and generally works better for users. Slack is another proof point - the "consumerization of IT" trend in general. There absolutely are outlier businesses like banking, government, healthcare and other highly regulated fields where they do have critical control needs. Notice how all of these are associated with crappier UX. But the average business does not really have such needs, or at least it can be a mistake to blindly trade off employee happiness and productivity against feature checklists, yet that is typically the approach employed by procurement experts.
- Goladus 7y ago
  Exactly right, even to the point of bringing up a few specific industries that do in fact have specialized needs.
  - shadowgovt 7y ago
    But when the enterprise software authors want to capture 100% of the marketplace, they are, of course, writing their offering to support those few specific industries. ... which adds features to the product as a whole, which other customers will need to be aware of and might take advantage of.
    - alistairSH 7y ago
      Heck, even within my niche corner of the enterprise world (coincidentally a similar niche as Blackboard), there's always a noisy client who demands X. I can make all the good-faith arguments about why X really isn't needed, but if that client is threatening to go to a different vendor or sue, X is getting built. As a developer, there's only so much I can do before an account executive or C-suite tells me to quite bitching and just do it (and more often than not, they don't disagree with me in principle, but money makes the world go around).
sambeau 7y ago
Companies like Basecamp and Trello are here to prove that assertion wrong. Basecamp is in every fortune-500 company more than once and never officially. Why? Because you don't need IT to approve it first and it's price is just under what most managers can stick on their company credit card. One of Basecamp's mottos is "Do Less". It's also worth pointing out that the simpler the software, the more likely it is to fit in with more companies' workflows. As soon as you start adding niche features the more likely it is that they won't fit neatly with most places they are sold into.
- marcus_holmes 7y ago
  Totally agree, but it takes a really strong product manager to stand up to a sales person with $10K in revenue from an enterprise buyer "if we just add this one feature they want". The fact that the enterprise buyer doesn't actually need the feature, or could do it easier/cheaper/better is immaterial. A Purchasing Department worker in the enterprise is looking at your product and Product X, and Product X has that feature that some manager somewhere in the purchasing process said they'd like to have. They really like your product, but they can't justify picking it over Product X without that feature. Telling salesfolk that they have to walk away from the sale they spent months cultivating is hard, and there are often board-level ramifications to doing it. The entire company has to be behind "Keeping it Simple", including the directors and shareholders. This is why these companies (and products) are rare.
  - zerkten 7y ago
    Product managers also need to stop living in idealized bubbles and actually understand their users and customers. What they want can at times can be dirty or ugly, and require PMs to challenge engineering stakeholders. There needs to be give and take there. Often PMs are getting crunched in the middle and don't have the wherewithal to deal with these situations. Requirements also change over time and PMs can end up chasing a vision that doesn't exist. If PMs get out of their bubble and acknowledge this more they'd be trusted since there would be alignment on the long-term value for the customer and therefore sales. There are times that PMs need to show backbone when dealing with sales, or leadership, on features that might derail the product, but this doesn't have to be the default.
geofft 7y ago
This is the exact opposite of the advice I've heard about how to successfully deploy SAP - while it is endlessly customizable and you can staff a large, doomed engineering project to customize it to fit your business, you are a lot better off adopting the workflow and processes SAP wants you to use than adapting SAP to what you've been doing internally.
- codesforhugs 7y ago
  Yes, that's usually what enterprises end up doing for their second SAP implementation after the first one crashes and burns.
therealdrag0 7y ago
> writing complex, highly configurable software is hard. Especially overtime! And especially when different parts of the elephant are done to please different customers! It's hard to manage tech debt and feature creep when the software is being pushed in 4 directions by business, even if business has VERY close relations with customers (like companies I've worked for do).
dyeje 7y ago
I think it's spot on. Anybody who has participated in an enterprise sales cycle knows it's a ridiculous game of checking boxes created by random stakeholders who all need to have a say because they're Important with a capital I. At a certain point even a dev team with the best intentions can't create a usable piece of software with the resulting incoherent set of requirements.
ken 7y ago
I don't buy it. I've worked at a Fortune-100 company with "complex and unique workflows", and we used plenty of customized enterprise software, and they were the worst systems you ever saw -- both before and after our customizations were implemented. The best ones were those where we completely replaced the native UI, and the only reason we weren't running our software against a plain database is legacy momentum. You're either so big you're essentially doing custom development (or should be), or you're small enough you can't afford that and use whatever you're given with minimal tweaks to the UI. I believe it's possible to make software that's both good, and flexible enough to stay good while avoiding complete custom development, but it's incredibly rare, because the 'users' in that case (i.e., local developers) are twice removed from the sales process. "We have complex and unique workflows and need to customize the software to our needs" is simply another excuse used by executives to buy crap that users will hate.
pjc50 7y ago
> prefer to buy software that they can fit to their workflow rather than change the workflows of their profitable business True - and this is why the huge software spend rarely produces productivity benefits. Because the software-enabled workflow should be different from the pre-software workflow. But every organisation has two parallel workflows: the one written in the manual and the one everybody actually performs. The more rigid the organisation, the more likely these are to diverge. In a paper-and-humans system, the humans can make up for the deficiencies in the "official" workflow. In the automated system, it's baked in. Lots of big failed deployments replace a human-judgement system that was working "unofficially" with a machine-implemented one that doesn't work at all, because the process as written didn't work. And of course it's impossible to tell management that the process doesn't work in that kind of environment. (Hence the huge advantage of Kaizen - make the official process match the one that actually works for humans)
taude 7y ago
Maybe the OP wanted to say the UX of enterprise software?
IshKebab 7y ago
This gets it right in my experience. I worked at a company that used Siemens Teamcenter. It's awful awful software, based on Eclipse but somehow even slower. Everybody hated it. I once put a slightly sarcastic comment on an internal wiki about it being rubbish (literally everyone know this), and to my surprise got told off by some purchasing manager somewhere - I wasn't allowed to criticise Teamcenter because some important people higher up had made the decision to buy it. The fundamental problem with enterprise software is that the buyers are not the users. Why would you care about usability if the people you are selling your software to never use it?
kd0amg 7y ago
The real reason enterprise software sucks is that enterprises have complex and unique workflows I strongly doubt that support for complex and unique workflows is why Blackboard is so bad at entirely conventional workflows.
LordFast 7y ago
Enterprise software sucks because not "sucking" is not its top priority. For its actual intended purposes, enterprise software doesn't "suck".
JackRabbitSlim 7y ago
The Pitch: "Structural support framework product! It's fully extensible and can conform to any design requirements unique to your business requirements. It's worth the price premiums for its amazing flexibility!" The product: 5 thousand dollar bags of concrete(cut with flour). Just add water, re-bar, molds, trucks, cranes and workers and your all set! Construction is complicated thing, 5 grand ain't unreasonable for a structure that could be around decades right?
closeparen 7y ago
Unix philosophy tools are the best building blocks for software engineers, but enterprise software is primarily marketed to companies that see involving SWEs as a last resort.
your-nanny 7y ago
People hate Word, Excel and Photoshop??? These are examples of wildly successful software used by consumers and in industry alike.
prepend 7y ago
Enterprises think they need and exert more control than they need. I think companies perform better with less rigid “do it this way because.” It’s fascinating how enterprise staff follow processes they don’t understand to get an outcome and don’t know why. I can frequently get better service than my IT staff from free tier consumer stuff. I hear “security” blah blah blah but the security on gmail is better than any local outlook install. I think there’s a myth of security. Whats breaking this is just people ignoring enterprise IT, I think, until someone notices they are spending lots on stuff that people don’t care about.
- solidasparagus 7y ago
  I don't know about gmail vs outlook, but I think security is often a valid concern. B2B products are usually built with a heavy emphasis on the security side of the security-convenience tradeoff. B2C products tend to be more convenience focused. You can have a B2B or a B2C product that is both convenient and secure, but that certainly isn't guaranteed, particularly for young products. For instance Slack is great IMO, but they only introduced bring-your-own-key earlier this year (a requirement for security-serious companies).
ping_pong 7y ago
I've worked in enterprise software for 15+ years. Enterprises don't have complex and unique workflows, they generally have lazy and shitty workflows because people don't care. The reason why enterprise software sucks is many-fold. My top reasons are the following: 1) Enterprise customers spend a lot of money and thus demand a lot from its suppliers. Sales and PMs and VPs will do whatever it takes to make their numbers and make their bonuses, so they will sacrifice software architecture for customer happiness. I'm not saying this is wrong, but it's the reality. 2) Software shouldn't exist for 20 years. Imagine writing a book where the authors change every 2-3 years, and the incentive was to write the best chapter and then leave afterwards. By the end of the book, it's probably going to be a shitty book. The only pieces of software where it works are things like operating systems like Linux where you have someone like Linus who really does care and has been around since the beginning. Even Microsoft fell into this trap, look at Windows Vista which was a disaster.
matchagaucho 7y ago
Blackboard's roots were in the NPO/NGO world, which influenced many design and feature decisions that took them in a completely different direction than B2B SaaS. OP conflating them with enterprise software is not the best premise.
GordonS 7y ago
While I agree in general, I'm not sure SAP is the best example - in enterprise circles, SAP is famous for forcing you to change your workflows and processes to fit the SAP model.
fdjlasdfjl 7y ago
Every company does not need bespoke accounting software. Its much more efficient to drop in an enterprise product and re-train the organization.
ppeetteerr 7y ago
I second this. Writing custom software for a few users with complex and custom business cases is very hard. UX goes out the window because of the large feature set and the low productivity of each programmer.
elwell 7y ago
[Shameless Plug] We're working on a process to help the buyer make the best decision - Vetd Marketing Site: https://vetd.com https://vetd.com Platform Signup: https://app.vetd.com/signup/buyer https://app.vetd.com/signup/buyer
outworlder 7y ago
> I think this gets it wrong. The real reason enterprise software sucks is that enterprises have complex and unique workflows and would prefer to buy software that they can fit to their workflow rather than change the workflows of their profitable business with tens of thousands of staff who will need retraining. No, that's not it. Take something like filing taxes. The tax laws are very arcane and convoluted. And yet, we can take something like TurboTax that (if we disregard the upsell dark patterns) can make the average joe competently file their taxes. It has wizards to guide you step by step, it will hide crap that is not relevant and not even prompt you for it. On the other hand, there are some countries, like Brazil, with their own government supplied software. Compared to TurboTax, they are a nightmare. There is zero guidance on what you have to do, they have all fields you may ever need in any tax situation in your life. The only thing it does competently happens when you press "send". That, and importing older returns (kinda, sorta, provided you have explicitly saved the old backups in the correct format, or you have last year's version installed). > very few companies have the billions of development dollars the above handful of companies have to throw at the problem to try to make it tractable. Sorry, all I hear is a bunch of excuses. You don't need to have billions of dollars, all you need to massively raise the bar is to have a UX team – or frankly, a single UX person that is listened to and is able to engage with actual users.
- dmode 7y ago
  Turbo tax is a consumer product and is optimized for that. Selling Turbotax to an enterprise will yield very different results
  - blat001 7y ago
    I think that this hits the nail on the head. That often the bulk of the people who use enterprise software are not the true end-user. Think of Salesforce which people who use it complain about daily. The end-users are actually all the people who get the reporting and sales management out of Salesforce. They love it as a tool. The sales people are only data entry people... Therefore its optimized towards the true end-users.
fulafel 7y ago
I think there should be a distinction between commercially high revenue software and software that is simple and effective. I'd rather call the latter succeful.
dmode 7y ago
This is very true. The other part it misses out is the impact of sales process on product development. Enterprise software companies have large dedicated salesforce, and product managers are under pressure to deliver a feature that will close a large sales deal. I have been there, and we have compromised many times to satisfy a Walmart or a GM because of large $$ associated with that account. Also, the data in our systems actually don't belong to us. So it was very difficult to run any kind of experiments or metrics to understand product usage to improve usability. You basically have to launch something and hope it works. Finally, enterprise software companies invest a lot more on sales force vs. software development. Which compromises the quality of the product.
cjfd 7y ago
No these tweets get it exactly right. A problem is software that gets sold on golf courses without any regard the people who are actually going to use it.
- cjfd 7y ago
  Also, since you name jira. Try doing a so-called 'bulk change' in jira for, let us say, three stories, and marvel at the needless sequence of screens one is guided though. It has nothing to do with any necessary complexity. It is just bull$hit software being sold at golf courses.
conexions 7y ago
I really would say your just restating the OP conclusion from the point of the of the purchaser instead of from the point of view of the software developer. An executive at an Enterprise would state their search for some piece of software as: I have such and such problem. I wish someone would make a magic wand and fix it for me(how hard can it be anyway). To which some software developer will reply. Hey we make magic wands. We make incredible magic wands. Let's schedule some time to show them to you. And the fact that the people who have to use it are not involved makes a huge difference in quality. You give Word, Excel and Jira as examples of Enterprise Software. If these are examples of Enterprise Software they are by far the best examples of such Software. Enterprise Software that currently makes my life miserable on a daily basis would be products like Remedy for workflows and approvals, Serena and Harvest for Change Management, WebSphere Middleware, CyberArk for secrets management, and WebMethods for an Enterprise Service Bus. All of these have horrible documentation, are extremely expensive, and most have superior open source equivalents. The only reason that companies like this can still stay in business is because there are executives who still believe in magic wands and then believe sales people when they say they have them for sale.
lliamander 7y ago
> If you look at all of the most successful software of all time they are the complete antithesis of the Unix philosophy that so many designers and developers prefer. Word, Excel, SAP, Photoshop, Salesforce, JIRA. Setting aside for the moment the fact that Unix itself is also incredibly successful (both in a commercial and mindshare perspective) the items in that list are not necessarily commensurate. Yes, they all have lots of features, but Excel and Photoshop were definitely built for their users, whereas SAP was not so much. As a consequence, Excel and Photoshop have very enthusiastic user communities, and SAP (et. al) users gripe a lot. My thesis is that Excel and Photoshop were built around empowering the workflows of individual users. As such, it becomes possible to market directly to the users, even if someone else ends up writing the check. Products like JIRA, Salesforce, and SAP are intended to optimize the flow of an organization. There's no single user you sell the software to that will benefit from using the software independent of what other people are using. Also, the Unix philosophy isn't about limited functionality - it's about achieving rich functionality by having orthogonal bits of functionality that can be composed together in new and unexpected ways that can be reasoned about. Programs/applications within Unix may be simple and single purpose, but Unix itself is not. Likewise, we may look at Excel as an application and deem it to be overly complex. However, as a platform Excel is fantastic in that it has lots of independent pieces of functionality that can be easily combined together.
unethical_ban 7y ago
I don't think it's either/or. You make a good second point. We have ServiceNow where I work. It is, in a way, SUPER customizable for tons of workflows... if you don't mind your workflow/work request being labeled a "shopping cart" with a "checkout". Meanwhile, my team has an internally built request system. Bottle/SQLite (later converted to mssql). Built it with three people in three months with feedback from actual users (requests and fulfillment). It is so good, other team who were forced onto SNow were and still are jealous. There are some downsides to maintenance, and it still doesn't have the API we wish it had, but damnit if it isn't 100x the form they built out for us in SNow.
inimino 7y ago
> prefer to buy software that they can fit to their workflow rather than change Existing users' familiarity with existing tools and the ability to accomplish existing tasks with existing skills are all part of the competitive landscape for any tool that must compete for people who use it by choice. In other words, if the user chooses the tool, they will choose a tool that allows them to accomplish what is necessary, given their existing skills. That this choice is so often lacking is just a symptom of the reduction of individual agency in the modern corporation. There is no fundamental law preventing software from becoming more usable and more powerful over time. In fact, for as often as enterprise procurement keeps old interfaces around longer than they should be, it is just as often responsible for replacing something that everyone knew how to use with something worse, rendering institutional knowledge worthless overnight. > most successful software of all time By what definition of success? > People hate them because they are complex, configurable, and have 1000 features. > But that's the same reason they can [meet the need.] Good design is precisely about enabling complex work with well-chosen, simple yet powerful tools. Your statement implies or at least suggests that any tool that meets a complex set of business needs must be something people hate, which is equivalent to saying that well-designed tools cannot exist -- equivalent to giving up on design. All the evidence shows us is that good design is rare, and much more so whenever tool users are not tool choosers. If you believe good design is possible (as you suggest later, that it is just expensive) then what you're saying is simply that bad design is cheaper, and is the default outcome when good design is not valued, all of which is certainly true. However, you still have to explain why good design fails to thrive in the market, and why large numbers of people are using trash tools that everyone hates and no-one could ever love. This may be explained by the principal-agent problem, by network effects, as in the case of platforms and productivity tools, by a lack of user awareness, or various other reasons, but simply saying that good design costs and doesn't happen by accident is not a sufficient explanation for what we see happening in the market. You might believe that the market is correct here, and good design simply isn't worth the cost, but it wasn't clear to me if that's your position. > That the end user isn't the purchaser isn't going to change that fundamental reality that businesses are complicated. The fundamental reality here is that good design will only be rewarded when the people who suffer from bad design are empowered to choose otherwise. As long as the cost of good design is borne by party A, while the pain of bad design is borne by party B, and party A pays for and chooses the tools, then bad design will continue to dominate.
dingo_bat 7y ago
Who hates excel though?
rstuart4133 7y ago
> The real reason enterprise software sucks is that enterprises have complex and unique workflows and would prefer to buy software that they can fit to their workflow rather than change the workflows of their profitable business with tens of thousands of staff who will need retraining. Call me cynical, but as I see it the complexity of the problem grows to fit the number of dollars available. If it's a large organisation they will invariably choose something that takes a colossal number of people to install and maintain it. I've seen this as a person who designed and built cash registers. Supermarkets selling 10's of thousands of products can only tolerate a limited amount of complexity - so they have the simplest systems. Liquor markets has less products, and so they start branching out into weird pricing scheme (eg, mixed dozen of certain wines - something a supermarket would never contemplate). Go to a restaurant and limited products, and hell even McDonald's will even create a product especially for you on the spot - how many patties would you like on that quarter pounder Sir? A regular restaurant creates the most insane products you've ever seen - how would like it cooked, what sauce, kids meal, and even "which of the items on this bill will your friend be paying for?" You could argue this complexity does help sales in some way. Bureaucracies are special they add totally unnecessary complex to justify their existence. So the article gets it right in one way: in order to justify that ongoing money in people needed to maintain it they need a product that cost a lot, and so justify that it needs to have a lot ticked boxes. It is in the products makers interest to make the task seem as complex and yet attractive as possible. Or to put it another way, a big organisation invariably consists of a number bureaucratic fiefdoms whose evolutionary imperative is to make themselves indispensable as possible by ensuring their is work that must be done by them in order for the corporation to function. They are constantly trying to grab work from each other in a dog eat dog world. The worst at it get eaten by the best. I recently saw this first hand. An organisation is installing SAP for payroll. It's taken a team of 10 or 20 3 years so far, and it's not done. Hmm, I thought, they must be big. Nope - turns out they have a total of two offices. I could write a system that serves the payroll needs of 200 people in 2 to 3 years, and it would be customised to their exact way of operating and would only take one person to maintain it. So why SAP? They only reason I can see if a bureaucratic mandarin can pull getting it installed, he's got a guaranteed job managing 20 people for years with plenty of opportunity to grow it. IT bureaucracies seem to be particularly cancerous. I suspect that is because most companies core competency isn't IT, yet reducing head office staff through automation depends on IT and everybody knows that. So IT can get away with more in the way of snow jobs than most.
heeen2 7y ago
SAP migrations often fail after millions invested because SAP prescribes a business model and if you want to change it you'll pay out of the nose for consultants trying to tailor it to your special snowflake business

hyperpape 7y ago

I would say yes and no. It's true that enterprises have complex and unique workflows, and that this drives the complexity of enterprise software. What I doubt is that this complexity is actually adding value in most cases. There is a nice equilibrium where companies adopt simple best practice workflows for non-core competencies, and vendors compete on how effectively they can implement those simple workflows. In reality, we're stuck in the equilibrium where companies cling to baroque workflows for everything, and vendors compete to support those workflows, sacrificing ease of use, implementation time, and agility.

PeterisP 7y ago
Thing is, enterprises have multiple incompatible workflows but still need to make it work. I.e. due to mergers and acquisitions different parts of the company have 3 different, incompatible IT workflows for part procurement. Of course that's bad and a single system is highly desired - so the company is working on it, and within a year these three workflows are going to be combined in a single system. Naturally, that system isn't simple as it needs to combine the peculiarities of these three workflows. Of course that's bad, and a single simpler workflow is highly desired - so the company is working on it, and within 2-3 years the processes are going to be adjusted and unified so that there's a reasonable single process. However, there's another acquisition that's going to be finalized soon, and during these 2-3 years at least one more is going to happen, so by the time these workflows are unified and simplified, they will be joined by new parts of the company using different workflows, and the enterprise will be back to square one with 3 separate systems with incompatible workflows for doing the same thing.
- hyperpape 7y ago
  Oh, I'm aware. I work in enterprise software. I see what the customers want. I've also been on the receiving end: my company has one tool that doesn't work well. So for three years, there's been a push to get rid of it, but there's never been agreement on any replacement. There's one particular use case that stakeholders think isn't handled by the replacements. The result is that we use both tools, and manually synchronize them. Someone wrote a bespoke automated tool to bridge those two SaaS apps, but it doesn't remove the manual synchronization, just reduces it. Oh, these tools? They aren't for something low touch. People are in both tools constantly. There are questions about which pieces of information are accurate, and who's responsible for which updates. The time waste is significant. But the problem isn't the software. The problem is that people can't make a decision. When you ask someone higher up, you get vague assurances that we're still thinking about the issue. In the case of the companies with their mergers, having one tool support both systems isn't doing anyone any favors. It just lets them limp along with excess complexity.
zerkten 7y ago
> In reality, we're stuck in the equilibrium where companies cling to baroque workflows for everything, and vendors compete to support those workflows, sacrificing ease of use, implementation time, and agility. Enterprises are setup to support all of these baroque workflows and that's where most of the value is derived. However users and the business don't get that value, and the project to replace the previous one will deliver "value" to IT stakeholders. The cycle repeats. You have enterprise architects who in the worst case are creating uncertainty by supporting different factions and introducing new tools which interest them versus meeting goals for the company. IT outsourcing vendors are responsible for the implementation and frequently do a less than stellar job. Security are split between trying to keep tabs on how the outsourcer is running things, while trying to limit how much damage business areas do by just delivering their own solution with SaaS or a small vendor. This is a real mess that requires huge amounts of energy, and is hard to fix because everyone is doing pretty well from it in their own way.

ch4s3 7y ago

People love excel and Photoshop. I’ve never met any heavy excel user that prefers any other spreadsheet software or even has anything negative to say about it.

fasicle 7y ago
Yeah me too, I find MS Word very useful too tbh. Not sure why higher level comment thinks people hate them.
- sam_lowry_ 7y ago
  Try to use the French version of Excel, and you'll understand. They renamed function names. Everyting. Not a single word makes sense anymore.
  - throwaway744678 7y ago
    I switched the language of the OS on my computer for this very reason. This is idiotic.
  - mattkrause 7y ago
    Wait, really? As in '=somme(A1:A10)' to add a column?
    - Udik 7y ago
      Yes, same in Italian, and I guess in every other language. It's dreadful but probably once you memorized all your favourite functions is quick to use. It's definitely not a tool for developers.
      - wolco 7y ago
        People have asked for this or the Spanish version of Angular or Russian Java. If I only spoke those languages I might want that as well. Surprised no one has tried to introduce this into popular programming languages.

SomeOldThrow 7y ago

astura 7y ago
I have my doubts that "complex unique organizational workflows" automatically means "dysfunctional organization."
- SomeOldThrow 7y ago
  And it would be ludicrous to interpret me that way! The part that implies the dysfunctional organization is “enterprises”.
Goladus 7y ago
No, it can just be one or two bad decisions that cascade and wind up being hard to get undone. The decision might have come from a committee or might have come from a single executive that turned out to be a bad hire.

felideon 7y ago

You raise a good point, but it doesn't mean the OP is wrong. There is an inflection point where, even if the software was originally designed with a target user (persona) in mind, the features that keep getting added are designed for the buyer. It is impossible to design software that works for wide set of personas. Melissa Perri calls it the Build Trap: https://www.mindtheproduct.com/escaping-build-trap-melissa-perri/ https://www.mindtheproduct.com/escaping-build-trap-melissa-p...

dredmorbius 7y ago

That sounds like a Conway's Law, but of large purchasers, rather than of software developers. https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law

investinme 7y ago

Nobody hates Photoshop. In fact it's one of the most loved software out there. I'm a developer and a Photoshop user and love it. The Unix philosophy would be a disaster for a image editing software (ImageMagick much?) Once a developer who spent all day in VIM & co was honestly arguing with me that Photoshop should be a command line app. I filled that under "shit developers say" and "delusional".

dredmorbius 7y ago
Not so much in Venezuela right now. And, FBOW Linux has the Gimp, which I prefer to Photoshop, though that's largely on account of familiarity. ImageMagick itself is invaluable when what you need to do is programmatically change large numbers of images. I've seen it used on large (multi-million user) image-heavy sites as the standard image handling flow (thumbnails and default previews of standard sizes).
- investinme 7y ago
  That was exactly my point. ImageMagick and Photoshop serve completely different needs. You can't replace one with the other.
- pier25 7y ago
  > Not so much in Venezuela right now. Yeah but that's not because of the software itself.
  - dredmorbius 7y ago
    It's definitely a consequence of the software's implementation.
kragen 7y ago
It's strange that someone who spends all day in Vim (which is not an acronym, by the way), an editor driven by keystrokes rather than the command line like ex or edlin, would prefer a command-line Photoshop. I'm not saying you're lying but maybe they misspoke or you misremembered. A keystroke-driven Photoshop might be something like Blender. I think netpbm is more Unixy than ImageMagick. I've had good experiences with it, especially for images bigger than my RAM, but a paint program it is not.

jasode 7y ago

>Word, Excel, SAP, Photoshop, Salesforce, JIRA. I'd refine your examples somewhat. The author's idea of "enterprise software" would be more like SAP/Salesforce/JIRA. A client-server model type of software (data lives in big central corporate databases) instead of being documents-oriented (user data lives in files like .xlsx, .docx, .psd). In contrast, the other desktop software of Photoshop/Word/Excel is often bought by consumers outside of enterprises because that's the software they prefer. (E.g. artists buy Photoshop instead of using GIMP.) And in the workplace, a lot of analysts like using MS Excel.

airstrike 7y ago
In the workplace, people like using MS Excel because the alternatives are ridiculously inferior
- v77 7y ago
  Yes, I certainly wouldn't call Office enterprise software.
- collyw 7y ago
  I would say that its because people understand how to use it. Excel is frequently used as a database, not because it makes a good database but because people don't understand how to use Access (or any other relational database) but Excel is easy enough that they can get something usable.
  - airstrike 7y ago
    That's part of it, but not all and also not the most important IMHO Excel clones simply don't cover the breadth of functionality provided by the OG, not to mention key UX features like countless hotkeys and menu accelerators Every Excel user understands Google Sheets. They just don't like feeling like they're strapped to a wheelchair
  - vetinari 7y ago
    Often they understand Access, they just don't have it. Office Standard and Home & Business SKUs are without it, you need Office Professional Plus. Because it costs few hundred more for just Access and Skype, most workers will get the Standard one.

maxerickson 7y ago

What if the Unix philosophy is accidentally successful just because it encourages the design of effective tools? (with the separation of concerns not really mattering in the usage of the tools)

khendron 7y ago

What you say sound more or less the same as what the Twitter thread says. Enterprises with complex and unique workflows come to a software vendor with a checklist of features, and complex highly configurable software checks all the checkboxes. It doesn't matter that the software is almost impossible to use. For some reason, usability is never one of the checkboxes. The root of the problem is that the people holding the checklists are not the same people who have to use the software. Which was the point of the Twitter thread.

Juliate 7y ago

The thing is ... very few companies do actually use all the complex configuration of said purchased software. Rather, they are stuck with it. And deal with it, limiting the contact surface, until they cannot bear it anymore, and spend more to upgrade/get some consulting to have the solution reorganized for them. On one hand, you have purchase departments that are not the target users, and decide only based on paper reports, what to purchase. Losing the run from the start line. That's a given. On the other hand, you have those who prefer to outsource the understanding of their own workflow/tooling/business, that could leave them somehow unique and different, to some outside flexible product that claims to solve that (and that meets this and this requirement from that body & that set of laws), but still requires armies of consultants to make it work properly, although it does not cover really your use case, so you better adapt your way of work to what "they" say is good (got Agile anyone?). Why? Because regulations. Because market/business standards. Financial due diligences. And why would they not prefer that? They (anyone, we) do not care. We are not paid to care for that. Or rather, we get rapidly burnt for caring. That's like the entropy law for software & processes in enterprise in general. Oracle, for instance (but that's valid for so many, if not all, enterprise-targeted solutions), didn't sell itself based on technical merits, you know. Business are complicated, yes. And they get even more complicated because of people lacking of the courage to say fuck you to the salesman.

basseq 7y ago
> The thing is ... very few companies do actually use all the complex configuration of said purchased software. That's the point, though. Enterprise software is a superset (E) of all features that a large group of very diverse customers need. An individual customer has a need for a much smaller set of features (C). That enterprise software may very well be the best software that includes all those needed features: C ⊆ E There are niche providers, so a logical customer would select the software that meets all of their needs and as little else as possible. But there may not be a niche provider that meets that criteria. So as an individual customer, you may be stuck between an Enterprise software that meets all your needs, but is "more than you need" and a niche software that doesn't meet all your needs.
- 7y ago

pier25 7y ago

> Word, Excel, SAP, Photoshop, Salesforce, JIRA I agree about SAP and JIRA, but the other ones are IMO universally loved. I've never found a designer complaining about Photoshop which is the holy grail for bitmap work.

mr_tristan 7y ago

It's not just organizational complexity either; sometimes it's just scaling concerns. And sometimes it's not your original target market. One company I worked for had Google as a customer when it was very small, and of course, as Google grew like a rocketship, used the product at a scale well past where it was used by anyone else. And then comes subtle little features to help them manage it at their scale. At one point, I think there were around a hundred "secret" undocumented options and another hundred "super secret" options. Needless to say, complexity is just something that has to be managed, and there are always rational "business justifications" for practically everything. The complexity often isn't designed; it's just brought in one step at a time from a variety of places. And _that_ usually ends up in a pile of crap.

SquishyPanda23 7y ago

> they are complex, configurable, and have 1000 features. If enterprises were selecting for this then you would expect emacs to be the most used enterprise software of all time. :-P

Crinus 7y ago

> they are the complete antithesis of the Unix philosophy that so many designers and developers prefer. Word, Excel Interestingly, Word and Excel were the origins of OLE in Windows 3.x times that was meant to allow embedding documents of one application inside another so that each application can focus on doing one thing well. The original documentation even explicitly wrote something along these lines. I always thought that OLE was basically Microsoft's attempt to bring Unix's "do one thing well" composability to GUI applications. (things changed considerably with Windows 95 and COM though and that part about doing one thing well was removed)

wikiman 7y ago

In my experience with most Enterprise software, the problem isn't the number of features it's the total lack of discipline in deciding what features are actually needed. Jira is the worst at this because people throw spaghetti at the wall until they get something that "works" for PMs but nobody else understands. I've worked at exactly one place that really was careful about JIRA and what made sense from the tool and it was a joy. I imagine the same is true of Salesforce though I've never seen anyone actually pull it off

blantonl 7y ago

very few companies have the billions of development dollars the above handful of companies have to throw at the problem to try to make it tractable. 95% of "enterprise software" is typically a small developer team of 5-10 people that delivers a product with some features, usually developed in and around J2EE, CORBA, COBOL, etc. It's then sold and supported by a marketing, sales, conference, booth, and sales engineering budget of billions of dollars. Haha! The other 5% of enterprise software is what you described above. :)

ian0 7y ago
On point! And so begins the large IT company lifecycle... - Those hundreds of sales engineers weave a spaggeti junction of pseudo products around the core application to suit the whims of the C-level clients and their buzzwords of the month - The company gets frustrated when this begins to break down leading to sales delays and embarks on a disasterous rearchitect which pits the sales engineers (microservices!) and core engineers against each other. - The sales delays lead to cost cutting and the old guard make a timely exit with a nice package. The laid off sales engineers get a better gig due to the buzzwords on the cv. - At some stage in the old guard are brought back to maintain the old core that is still running the company, but now charge a hefty consultant rate.

swalsh 7y ago

Sometimes I wonder, what if we just fundamentally took a new approach the OS. Today at the root of your operating system is the file system. It would be interesting if the file system was changed to essentially the concept of a simple object store. In much the same way we have "standard file formats" today, we could move to something like a "standard class". Objects would be a first class citizen in the OS. I think this becomes more interesting too if you start to ignore where the object lives. It doesn't matter if an object you care about is local, or on a server in your enterprises network, or if it's a thousand miles away. The second big change, is I would do away with "applications". opting instead for a smaller unit of executable. Probably integrated with the object system. The idea here is you don't buy an entire system from a single vendor. You buy features from multiple vendors... and the design of the OS makes it really easy to integrate together. I guess this is kind of the unix philosophy... but maybe taken to the next level. Thirdly, I think it would make sense if the system was natively "reactive", I think that would help with making aspect-oriented programming more normalized.

journalctl 7y ago
Filesystems that abstract away things like directories aren’t new, they just haven’t been commercially successful (I believe Vista was going to include WinFS, which was a database-like filesystem, but it was scrapped). It’s not that systems research has suddenly stopped, it’s that it’s really really hard to not only introduce radical ideas to the public, it’s also hard to make sure you don’t break existing billion-dollar systems at the same time. And as anyone who’s had the misfortune of using a network share over a flaky connection can tell you, abstracting files away over networks is tricky business, and when your connection fails (which it will), that abstraction breaks.
joncp 7y ago
> do away with "applications". opting instead for a smaller unit of executable This sounds a lot like Android's "activities" concept which doesn't get enough love, in my opinion.
- amenod 7y ago
  This! Also the concept of Intents is pure genius.

_pmf_ 7y ago

SAP sucks companies dry.

xivzgrev 7y ago

This makes sense. Given my experience in tech startup land, im going to take a stab at how this happens from inside the company. Lets say you are starting sn enterprise saas company, woohoo! You have your initial product and customers love it, yes! Things are starting to hum along nicely. Now your sales people are identiying new markets and saying “hey if we add feature x and y, we can make $x million more per year from x y and z clients”. At this critical juncture, managwment most likely approves and has UX involved, but adding the features will be the priority regardless. Theres no overrulin g UX voice that can say “no, dont build that feature because theres no way to maintain the delightful user experience” because MONEY IS ON THE TABLE! Execs got revenue goals to hit, sales people have revenue goals to hit, and this seems like a match made in heaven. Additionally, its important to point out that pioneering companies dont know all the end state user flows at the beginning so they are hacking along, reacting as they learn more about end customers. Now fast forward a decade. The software is bloated but has grown a lot. Users hate it. New startups look at your product, your end customers, and say “hey! We can do this more simply and steal their customers”. And they can, because they have the advantage of starting from the ground up, KNOWING THE CUSTOMERS and their workflows. So of course they can build a more efficient product because they have the clear end vision - your product, but with the bloat cut out. Your team has already done the hard work of identifying the best and largest customer use cases. So what’s the solution? Acquire these upstarts or make your company a platform. I dont what blackboard has done here but salesforce is still by far the largest game in town despite universal hate. Why? In large part due to the vast network of 3rd party developers who can configure salesforce to a customer’s complicated workflows. They’ve actually taken this problem (it’s complicated to use) and turned it into a retention feature. No wonder they have a giant skyscraper in san francisco.

vgetr 7y ago
This makes sense to me. Sometimes it’s not even about more money but existence entirely. Seeing as that VisiCalc was _the Spreadsheet_ up until Lotus came along and ate their lunch, it’s easy to see that sometimes features and other external forces may have more of an impact than the raw popularity of a product in the end.
dmix 7y ago

Spooky23 7y ago

Exactly. They also control the workflow. If you don't like the 15 steps it takes to update your expense report, good for you, you won't get paid. Companies will lose deals unless they do what customers want. Eventually, that chunks up the software and makes it awful. That's just the nature of the beast, and it's no different than things were pre-computer. I had a .gov customer that had a very specific ruleset about stapling paper forms a certain way, which impacted how certain processes worked after they were computerized. Nobody understood why, then we found out -- in a tragic accident, a key employee in one of the paper processes in the 70s lost an arm. They ended up stapling things a certain way to accomodate his constraint and optimize throughput. The practice spread to other areas. 30-40 years later, after the employee was long retired and dead, the process lived on. In the case of something like Word, people who write need to do stuff. I probably use 30% of Word features, but in the 2 times in the last decade that I needed to create a document with a table of figures, it's there.

corebit 7y ago
This story needs a write up! I'm fascinated!
- Spooky23 7y ago
  Someday I’ll write a book or something. There’s a deep well of crazy stories like this that I’ve run into!
  - polymatter 7y ago
    please do
maerF0x0 7y ago
There's a similarly apocryphal story about cutting the ends of ham off. https://sixsigmadsi.com/grandmas-ham-a-story-of-cultural-training/ https://sixsigmadsi.com/grandmas-ham-a-story-of-cultural-tra...
- 7y ago

ThomPete 7y ago

Exactly or put another way. Companies only use 5% of the features the more sophisticated enterprise software is offering but it's a different 5% each of them use.

Goladus 7y ago

rossdavidh 7y ago

I think this gets it fundamentally correct, although your point has some validity. But the reason that enterprises often wish to pay for configuration of the software instead of changing their own workflows, is that one of these requires no work from them (the decision makers), and the other does. Much of what is called "enterprise software" is actually more like a proprietary programming language or framework, which you will have to pay specialists to program your application in, with bad debugging tools. Lastly, Oracle and SAP and etc. aren't actually good at the problem you describe, as attested to by the many users who hate their products. They're just good at selling their software to the decision makers (not the users).

ridaj 7y ago

No, this does completely get it right. Enterprises thought they needed all the control and security features of Blackberry until the iPhone came along and made the UX gap unsustainable. Enterprises thought they needed on-premise hosting of Exchange, Office and SharePoint instances under their control for email and productivity, until GSuite came up with a better, less configurable user experience based on consumer features that is making inroads in the market and generally works better for users. Slack is another proof point - the "consumerization of IT" trend in general. There absolutely are outlier businesses like banking, government, healthcare and other highly regulated fields where they do have critical control needs. Notice how all of these are associated with crappier UX. But the average business does not really have such needs, or at least it can be a mistake to blindly trade off employee happiness and productivity against feature checklists, yet that is typically the approach employed by procurement experts.

Goladus 7y ago
Exactly right, even to the point of bringing up a few specific industries that do in fact have specialized needs.
- shadowgovt 7y ago
  But when the enterprise software authors want to capture 100% of the marketplace, they are, of course, writing their offering to support those few specific industries. ... which adds features to the product as a whole, which other customers will need to be aware of and might take advantage of.
  - alistairSH 7y ago
    Heck, even within my niche corner of the enterprise world (coincidentally a similar niche as Blackboard), there's always a noisy client who demands X. I can make all the good-faith arguments about why X really isn't needed, but if that client is threatening to go to a different vendor or sue, X is getting built. As a developer, there's only so much I can do before an account executive or C-suite tells me to quite bitching and just do it (and more often than not, they don't disagree with me in principle, but money makes the world go around).

sambeau 7y ago

Companies like Basecamp and Trello are here to prove that assertion wrong. Basecamp is in every fortune-500 company more than once and never officially. Why? Because you don't need IT to approve it first and it's price is just under what most managers can stick on their company credit card. One of Basecamp's mottos is "Do Less". It's also worth pointing out that the simpler the software, the more likely it is to fit in with more companies' workflows. As soon as you start adding niche features the more likely it is that they won't fit neatly with most places they are sold into.

marcus_holmes 7y ago
Totally agree, but it takes a really strong product manager to stand up to a sales person with $10K in revenue from an enterprise buyer "if we just add this one feature they want". The fact that the enterprise buyer doesn't actually need the feature, or could do it easier/cheaper/better is immaterial. A Purchasing Department worker in the enterprise is looking at your product and Product X, and Product X has that feature that some manager somewhere in the purchasing process said they'd like to have. They really like your product, but they can't justify picking it over Product X without that feature. Telling salesfolk that they have to walk away from the sale they spent months cultivating is hard, and there are often board-level ramifications to doing it. The entire company has to be behind "Keeping it Simple", including the directors and shareholders. This is why these companies (and products) are rare.
- zerkten 7y ago
  Product managers also need to stop living in idealized bubbles and actually understand their users and customers. What they want can at times can be dirty or ugly, and require PMs to challenge engineering stakeholders. There needs to be give and take there. Often PMs are getting crunched in the middle and don't have the wherewithal to deal with these situations. Requirements also change over time and PMs can end up chasing a vision that doesn't exist. If PMs get out of their bubble and acknowledge this more they'd be trusted since there would be alignment on the long-term value for the customer and therefore sales. There are times that PMs need to show backbone when dealing with sales, or leadership, on features that might derail the product, but this doesn't have to be the default.

geofft 7y ago

This is the exact opposite of the advice I've heard about how to successfully deploy SAP - while it is endlessly customizable and you can staff a large, doomed engineering project to customize it to fit your business, you are a lot better off adopting the workflow and processes SAP wants you to use than adapting SAP to what you've been doing internally.

codesforhugs 7y ago
Yes, that's usually what enterprises end up doing for their second SAP implementation after the first one crashes and burns.

therealdrag0 7y ago

> writing complex, highly configurable software is hard. Especially overtime! And especially when different parts of the elephant are done to please different customers! It's hard to manage tech debt and feature creep when the software is being pushed in 4 directions by business, even if business has VERY close relations with customers (like companies I've worked for do).

dyeje 7y ago

I think it's spot on. Anybody who has participated in an enterprise sales cycle knows it's a ridiculous game of checking boxes created by random stakeholders who all need to have a say because they're Important with a capital I. At a certain point even a dev team with the best intentions can't create a usable piece of software with the resulting incoherent set of requirements.

ken 7y ago

I don't buy it. I've worked at a Fortune-100 company with "complex and unique workflows", and we used plenty of customized enterprise software, and they were the worst systems you ever saw -- both before and after our customizations were implemented. The best ones were those where we completely replaced the native UI, and the only reason we weren't running our software against a plain database is legacy momentum. You're either so big you're essentially doing custom development (or should be), or you're small enough you can't afford that and use whatever you're given with minimal tweaks to the UI. I believe it's possible to make software that's both good, and flexible enough to stay good while avoiding complete custom development, but it's incredibly rare, because the 'users' in that case (i.e., local developers) are twice removed from the sales process. "We have complex and unique workflows and need to customize the software to our needs" is simply another excuse used by executives to buy crap that users will hate.

pjc50 7y ago

> prefer to buy software that they can fit to their workflow rather than change the workflows of their profitable business True - and this is why the huge software spend rarely produces productivity benefits. Because the software-enabled workflow should be different from the pre-software workflow. But every organisation has two parallel workflows: the one written in the manual and the one everybody actually performs. The more rigid the organisation, the more likely these are to diverge. In a paper-and-humans system, the humans can make up for the deficiencies in the "official" workflow. In the automated system, it's baked in. Lots of big failed deployments replace a human-judgement system that was working "unofficially" with a machine-implemented one that doesn't work at all, because the process as written didn't work. And of course it's impossible to tell management that the process doesn't work in that kind of environment. (Hence the huge advantage of Kaizen - make the official process match the one that actually works for humans)

taude 7y ago

Maybe the OP wanted to say the UX of enterprise software?

IshKebab 7y ago

This gets it right in my experience. I worked at a company that used Siemens Teamcenter. It's awful awful software, based on Eclipse but somehow even slower. Everybody hated it. I once put a slightly sarcastic comment on an internal wiki about it being rubbish (literally everyone know this), and to my surprise got told off by some purchasing manager somewhere - I wasn't allowed to criticise Teamcenter because some important people higher up had made the decision to buy it. The fundamental problem with enterprise software is that the buyers are not the users. Why would you care about usability if the people you are selling your software to never use it?

kd0amg 7y ago

The real reason enterprise software sucks is that enterprises have complex and unique workflows I strongly doubt that support for complex and unique workflows is why Blackboard is so bad at entirely conventional workflows.

LordFast 7y ago

Enterprise software sucks because not "sucking" is not its top priority. For its actual intended purposes, enterprise software doesn't "suck".

JackRabbitSlim 7y ago

The Pitch: "Structural support framework product! It's fully extensible and can conform to any design requirements unique to your business requirements. It's worth the price premiums for its amazing flexibility!" The product: 5 thousand dollar bags of concrete(cut with flour). Just add water, re-bar, molds, trucks, cranes and workers and your all set! Construction is complicated thing, 5 grand ain't unreasonable for a structure that could be around decades right?

closeparen 7y ago

Unix philosophy tools are the best building blocks for software engineers, but enterprise software is primarily marketed to companies that see involving SWEs as a last resort.

your-nanny 7y ago

People hate Word, Excel and Photoshop??? These are examples of wildly successful software used by consumers and in industry alike.

prepend 7y ago

Enterprises think they need and exert more control than they need. I think companies perform better with less rigid “do it this way because.” It’s fascinating how enterprise staff follow processes they don’t understand to get an outcome and don’t know why. I can frequently get better service than my IT staff from free tier consumer stuff. I hear “security” blah blah blah but the security on gmail is better than any local outlook install. I think there’s a myth of security. Whats breaking this is just people ignoring enterprise IT, I think, until someone notices they are spending lots on stuff that people don’t care about.

solidasparagus 7y ago
I don't know about gmail vs outlook, but I think security is often a valid concern. B2B products are usually built with a heavy emphasis on the security side of the security-convenience tradeoff. B2C products tend to be more convenience focused. You can have a B2B or a B2C product that is both convenient and secure, but that certainly isn't guaranteed, particularly for young products. For instance Slack is great IMO, but they only introduced bring-your-own-key earlier this year (a requirement for security-serious companies).

ping_pong 7y ago

I've worked in enterprise software for 15+ years. Enterprises don't have complex and unique workflows, they generally have lazy and shitty workflows because people don't care. The reason why enterprise software sucks is many-fold. My top reasons are the following: 1) Enterprise customers spend a lot of money and thus demand a lot from its suppliers. Sales and PMs and VPs will do whatever it takes to make their numbers and make their bonuses, so they will sacrifice software architecture for customer happiness. I'm not saying this is wrong, but it's the reality. 2) Software shouldn't exist for 20 years. Imagine writing a book where the authors change every 2-3 years, and the incentive was to write the best chapter and then leave afterwards. By the end of the book, it's probably going to be a shitty book. The only pieces of software where it works are things like operating systems like Linux where you have someone like Linus who really does care and has been around since the beginning. Even Microsoft fell into this trap, look at Windows Vista which was a disaster.

matchagaucho 7y ago

Blackboard's roots were in the NPO/NGO world, which influenced many design and feature decisions that took them in a completely different direction than B2B SaaS. OP conflating them with enterprise software is not the best premise.

GordonS 7y ago

While I agree in general, I'm not sure SAP is the best example - in enterprise circles, SAP is famous for forcing you to change your workflows and processes to fit the SAP model.

fdjlasdfjl 7y ago

Every company does not need bespoke accounting software. Its much more efficient to drop in an enterprise product and re-train the organization.

ppeetteerr 7y ago

I second this. Writing custom software for a few users with complex and custom business cases is very hard. UX goes out the window because of the large feature set and the low productivity of each programmer.

elwell 7y ago

[Shameless Plug] We're working on a process to help the buyer make the best decision - Vetd Marketing Site: https://vetd.com https://vetd.com Platform Signup: https://app.vetd.com/signup/buyer https://app.vetd.com/signup/buyer

outworlder 7y ago

> I think this gets it wrong. The real reason enterprise software sucks is that enterprises have complex and unique workflows and would prefer to buy software that they can fit to their workflow rather than change the workflows of their profitable business with tens of thousands of staff who will need retraining. No, that's not it. Take something like filing taxes. The tax laws are very arcane and convoluted. And yet, we can take something like TurboTax that (if we disregard the upsell dark patterns) can make the average joe competently file their taxes. It has wizards to guide you step by step, it will hide crap that is not relevant and not even prompt you for it. On the other hand, there are some countries, like Brazil, with their own government supplied software. Compared to TurboTax, they are a nightmare. There is zero guidance on what you have to do, they have all fields you may ever need in any tax situation in your life. The only thing it does competently happens when you press "send". That, and importing older returns (kinda, sorta, provided you have explicitly saved the old backups in the correct format, or you have last year's version installed). > very few companies have the billions of development dollars the above handful of companies have to throw at the problem to try to make it tractable. Sorry, all I hear is a bunch of excuses. You don't need to have billions of dollars, all you need to massively raise the bar is to have a UX team – or frankly, a single UX person that is listened to and is able to engage with actual users.

dmode 7y ago
Turbo tax is a consumer product and is optimized for that. Selling Turbotax to an enterprise will yield very different results
- blat001 7y ago
  I think that this hits the nail on the head. That often the bulk of the people who use enterprise software are not the true end-user. Think of Salesforce which people who use it complain about daily. The end-users are actually all the people who get the reporting and sales management out of Salesforce. They love it as a tool. The sales people are only data entry people... Therefore its optimized towards the true end-users.

fulafel 7y ago

I think there should be a distinction between commercially high revenue software and software that is simple and effective. I'd rather call the latter succeful.

dmode 7y ago

This is very true. The other part it misses out is the impact of sales process on product development. Enterprise software companies have large dedicated salesforce, and product managers are under pressure to deliver a feature that will close a large sales deal. I have been there, and we have compromised many times to satisfy a Walmart or a GM because of large $$ associated with that account. Also, the data in our systems actually don't belong to us. So it was very difficult to run any kind of experiments or metrics to understand product usage to improve usability. You basically have to launch something and hope it works. Finally, enterprise software companies invest a lot more on sales force vs. software development. Which compromises the quality of the product.

cjfd 7y ago

No these tweets get it exactly right. A problem is software that gets sold on golf courses without any regard the people who are actually going to use it.

cjfd 7y ago
Also, since you name jira. Try doing a so-called 'bulk change' in jira for, let us say, three stories, and marvel at the needless sequence of screens one is guided though. It has nothing to do with any necessary complexity. It is just bull$hit software being sold at golf courses.

conexions 7y ago

I really would say your just restating the OP conclusion from the point of the of the purchaser instead of from the point of view of the software developer. An executive at an Enterprise would state their search for some piece of software as: I have such and such problem. I wish someone would make a magic wand and fix it for me(how hard can it be anyway). To which some software developer will reply. Hey we make magic wands. We make incredible magic wands. Let's schedule some time to show them to you. And the fact that the people who have to use it are not involved makes a huge difference in quality. You give Word, Excel and Jira as examples of Enterprise Software. If these are examples of Enterprise Software they are by far the best examples of such Software. Enterprise Software that currently makes my life miserable on a daily basis would be products like Remedy for workflows and approvals, Serena and Harvest for Change Management, WebSphere Middleware, CyberArk for secrets management, and WebMethods for an Enterprise Service Bus. All of these have horrible documentation, are extremely expensive, and most have superior open source equivalents. The only reason that companies like this can still stay in business is because there are executives who still believe in magic wands and then believe sales people when they say they have them for sale.

lliamander 7y ago

> If you look at all of the most successful software of all time they are the complete antithesis of the Unix philosophy that so many designers and developers prefer. Word, Excel, SAP, Photoshop, Salesforce, JIRA. Setting aside for the moment the fact that Unix itself is also incredibly successful (both in a commercial and mindshare perspective) the items in that list are not necessarily commensurate. Yes, they all have lots of features, but Excel and Photoshop were definitely built for their users, whereas SAP was not so much. As a consequence, Excel and Photoshop have very enthusiastic user communities, and SAP (et. al) users gripe a lot. My thesis is that Excel and Photoshop were built around empowering the workflows of individual users. As such, it becomes possible to market directly to the users, even if someone else ends up writing the check. Products like JIRA, Salesforce, and SAP are intended to optimize the flow of an organization. There's no single user you sell the software to that will benefit from using the software independent of what other people are using. Also, the Unix philosophy isn't about limited functionality - it's about achieving rich functionality by having orthogonal bits of functionality that can be composed together in new and unexpected ways that can be reasoned about. Programs/applications within Unix may be simple and single purpose, but Unix itself is not. Likewise, we may look at Excel as an application and deem it to be overly complex. However, as a platform Excel is fantastic in that it has lots of independent pieces of functionality that can be easily combined together.

unethical_ban 7y ago

I don't think it's either/or. You make a good second point. We have ServiceNow where I work. It is, in a way, SUPER customizable for tons of workflows... if you don't mind your workflow/work request being labeled a "shopping cart" with a "checkout". Meanwhile, my team has an internally built request system. Bottle/SQLite (later converted to mssql). Built it with three people in three months with feedback from actual users (requests and fulfillment). It is so good, other team who were forced onto SNow were and still are jealous. There are some downsides to maintenance, and it still doesn't have the API we wish it had, but damnit if it isn't 100x the form they built out for us in SNow.

inimino 7y ago

> prefer to buy software that they can fit to their workflow rather than change Existing users' familiarity with existing tools and the ability to accomplish existing tasks with existing skills are all part of the competitive landscape for any tool that must compete for people who use it by choice. In other words, if the user chooses the tool, they will choose a tool that allows them to accomplish what is necessary, given their existing skills. That this choice is so often lacking is just a symptom of the reduction of individual agency in the modern corporation. There is no fundamental law preventing software from becoming more usable and more powerful over time. In fact, for as often as enterprise procurement keeps old interfaces around longer than they should be, it is just as often responsible for replacing something that everyone knew how to use with something worse, rendering institutional knowledge worthless overnight. > most successful software of all time By what definition of success? > People hate them because they are complex, configurable, and have 1000 features. > But that's the same reason they can [meet the need.] Good design is precisely about enabling complex work with well-chosen, simple yet powerful tools. Your statement implies or at least suggests that any tool that meets a complex set of business needs must be something people hate, which is equivalent to saying that well-designed tools cannot exist -- equivalent to giving up on design. All the evidence shows us is that good design is rare, and much more so whenever tool users are not tool choosers. If you believe good design is possible (as you suggest later, that it is just expensive) then what you're saying is simply that bad design is cheaper, and is the default outcome when good design is not valued, all of which is certainly true. However, you still have to explain why good design fails to thrive in the market, and why large numbers of people are using trash tools that everyone hates and no-one could ever love. This may be explained by the principal-agent problem, by network effects, as in the case of platforms and productivity tools, by a lack of user awareness, or various other reasons, but simply saying that good design costs and doesn't happen by accident is not a sufficient explanation for what we see happening in the market. You might believe that the market is correct here, and good design simply isn't worth the cost, but it wasn't clear to me if that's your position. > That the end user isn't the purchaser isn't going to change that fundamental reality that businesses are complicated. The fundamental reality here is that good design will only be rewarded when the people who suffer from bad design are empowered to choose otherwise. As long as the cost of good design is borne by party A, while the pain of bad design is borne by party B, and party A pays for and chooses the tools, then bad design will continue to dominate.

dingo_bat 7y ago

Who hates excel though?

rstuart4133 7y ago

> The real reason enterprise software sucks is that enterprises have complex and unique workflows and would prefer to buy software that they can fit to their workflow rather than change the workflows of their profitable business with tens of thousands of staff who will need retraining. Call me cynical, but as I see it the complexity of the problem grows to fit the number of dollars available. If it's a large organisation they will invariably choose something that takes a colossal number of people to install and maintain it. I've seen this as a person who designed and built cash registers. Supermarkets selling 10's of thousands of products can only tolerate a limited amount of complexity - so they have the simplest systems. Liquor markets has less products, and so they start branching out into weird pricing scheme (eg, mixed dozen of certain wines - something a supermarket would never contemplate). Go to a restaurant and limited products, and hell even McDonald's will even create a product especially for you on the spot - how many patties would you like on that quarter pounder Sir? A regular restaurant creates the most insane products you've ever seen - how would like it cooked, what sauce, kids meal, and even "which of the items on this bill will your friend be paying for?" You could argue this complexity does help sales in some way. Bureaucracies are special they add totally unnecessary complex to justify their existence. So the article gets it right in one way: in order to justify that ongoing money in people needed to maintain it they need a product that cost a lot, and so justify that it needs to have a lot ticked boxes. It is in the products makers interest to make the task seem as complex and yet attractive as possible. Or to put it another way, a big organisation invariably consists of a number bureaucratic fiefdoms whose evolutionary imperative is to make themselves indispensable as possible by ensuring their is work that must be done by them in order for the corporation to function. They are constantly trying to grab work from each other in a dog eat dog world. The worst at it get eaten by the best. I recently saw this first hand. An organisation is installing SAP for payroll. It's taken a team of 10 or 20 3 years so far, and it's not done. Hmm, I thought, they must be big. Nope - turns out they have a total of two offices. I could write a system that serves the payroll needs of 200 people in 2 to 3 years, and it would be customised to their exact way of operating and would only take one person to maintain it. So why SAP? They only reason I can see if a bureaucratic mandarin can pull getting it installed, he's got a guaranteed job managing 20 people for years with plenty of opportunity to grow it. IT bureaucracies seem to be particularly cancerous. I suspect that is because most companies core competency isn't IT, yet reducing head office staff through automation depends on IT and everybody knows that. So IT can get away with more in the way of snow jobs than most.

heeen2 7y ago

SAP migrations often fail after millions invested because SAP prescribes a business model and if you want to change it you'll pay out of the nose for consultants trying to tailor it to your special snowflake business