Hacker News new | past | comments | ask | show | jobs | submit login
Why Enterprise Software Sucks (twitter.com/random_walker)
1310 points by randomwalker on Oct 11, 2019 | hide | past | favorite | 554 comments

I worked at a school that used the Frog VLE.

There was a big push for us to use it for student assessment.

I tried, I honestly did.

1. I used it to set homework assignments.

2. .py files were blocked and students couldn't upload them.

3. They submitted code as .txt instead.

4. I'd click on my class to view submissions, it showed the top 5 submissions.

5. I'd click on a submission and it would download.

6. I'd view the submission locally.

7. I'd convert to .py to test the code worked.

8. I'd assign a grade.

9. I'd then have to click (maybe 5 - 10 times) through to a different page to record the grade.

10. I'd then have to go back to the submissions page.

11. After grading the first 5 submissions, I'd click through to the next page.

12. After grading the 6th submission, I would be returned to the first submission page and have to click forward again.

13. When you get to the 30th submission, you're maybe doing fifty clicks for each homework assignment.

14. I had 4 classes all doing the same assignment.

15. This could not be amalgamated into a single marking spree.

I spent weeks trying to grade my students and then just gave up and had them email me their assignments from that point on.

These platforms are all full of features; commissioned, designed, tested and developed by people who have never set foot in a classroom.

And, to be clear, this has nothing to do with "classroom".

The problem is people design these things without any sort of actual testing in actual conditions where the software is supposed to be used.

Displaying 5 results per page is a bug, not a feature. Having restrictions on filetypes is a bug, not a feature. The same could go on to the rest of their "features". (My biggest pet peeve is date formatting — just give me ISO8601 dates, please; HackerNews, you, too!)

At SXSW, there was a coffee-bot vendor. They didn't bother testing with an adequate number of folks, so, the whole thing overflowed on first day. Predictable? Yes. Would be noticed by a committee? Not a chance.

> just give me ISO8601 dates, please; HackerNews, you, too!

Strongly seconding. It's an annoying UX antipattern, especially as it loses precision over time ("28 minutes ago" is fine, but "yesterday" or "5 days ago" or - even worse - "2 years ago" is not; having the date specified to hours or minutes is actually useful, especially in context of a site with international audience). Doubly so on HN, which doesn't even bother with giving the actual date/time in the tooltip, which is the usual cop out (not an actual solution, since there are no tooltips on mobile).

Definitely agree about the loss of precision. It's also a problem for machine readability and SEO. The solution I like is using the HMTL5 <time> element for semantic markup of timestamps. If you do something like this:

    <time datetime="2019-10-11T13:53:36.861" title="Fri Oct 11 2019 13:53:36 GMT-0700">2 minutes ago</time>
Then you get what in my opinion is the best of both worlds: machine readable timestamp in the datetime field, human-friendly detailed timestamp as a tooltip (the title field shows when you hover over the element), and relative time as the default display. Bonus points if your React component or ERB template or whatever switches from relative time format to absolute for the inner text when the timestamp is older than a day or so.

"when you hover over the element"

On the website I'm looking at Google Analytics for right now, fewer than 35% of the visitors are from devices where "hover" means anything...

Well, it would require JS, but you could turn it into a button to show/hide an HTML tooltip or additional displays of the time. That iOS supports a mouse (in accessibility settings) or an Xbox controller but doesn’t properly support an “abbr” tag... it was acceptable in 2007 when we were happy to see the phone load nytimes.com with all its columns. It’s feeling very out of date in 2019, when 12 years later we’re adding downloads and “desktop safari” but we never finished the “desktop-equivalency” parts of the HTML5 spec. It would be amazing if Apple ported some of their iOS native components to web components or to enhance HTML5 elements. The farthest we’ve gotten so far are keyboard search button hints, if I recall correctly. Which is really quite disappointing, that an app made for jQuery UI would work as well as an app from today if you flatten and modernize the design, and add a bit of offline caching...

I prefer the HN method of 28 min, yesterday, 2 hours ago, etc... for HN. The older a comment or post, the less relevant it is to a particular discussion. This site is for real-time discussions of articles, so it is optimized for that use-case. The older a comment, the less relevant it is towards the immediate discussion. Thus, older comments have less precision, because those details don't matter for the discussion.

I'd expect a site/application that is designed for students to manage homework would have different date/timestamp requirements.

HN may be optimized for current discusions, but is also a repository of knowledge; I frequently land on years old threads from Google searches. For older times, an explicit ISO timestamp has at least two benefits: 1) I can compare it easily to other dates (e.g. is that comment older or more recent that event X, or software version Y), and 2) time of the day is a half-decent proxy for telling whether the US or Europe was awake then.

And while you can justify the inprecise stamp on HN, there's no excuse for GMail and a score of other messaging software doing the same. When I'm looking at the date of an old e-mail, I almost always need the exact date and time. "2 weeks ago" is useless. "2019-09-27 08:43" tells me it happened before work, on a day after an important meeting, etc.

ISO8601 date/time can easily be transformed into the fuzzy format HN uses, but not vice versa since the fuzzy format is lossy.

If HN sent dates to the client in ISO8601, the client could then transform that format into the format of their choosing with client-side javascript (either a userscript, or delivered to the user by HN.)

It's hard to be sure this isn't satire.

You mentioned 'for HN' twice in the same sentence.

Your 2nd, 4th, and 5th sentence all try to assert the same thing - older comments are less relevant than newer comments - despite there being no evidence, anywhere, that this is the case. Your 3rd sentence is partly true, though there's some historical record aspect to HN comment threads that you're discounting.

Your second paragraph is a non sequitur. Sites that correlate points in time with timestamps are ubiquitous, and there's rarely a compelling case for using wildly different approaches to displaying same.

They could easily do it the Reddit way and still provide a timestamp but keep the simplicity and relative time format. Just have it pop up the timestamp on mouse hover. That's still very simple and can be effectively done using just CSS.

You don't even need any CSS for that — the title attribute alone would be sufficient.

Personally I like HN the way it is. Very little UI clutter. If we start doing ISO dates and maybe options to switch between high precision and default low precision, we lose the good feel that HN has produced.

I'd prefer both.

I have one word to tell you: timezone

What about them? ISO8601 supports time zones.

> The problem is people design these things without any sort of actual testing in actual conditions where the software is supposed to be used.

I’ll do YOU one better. </Drax>

I work in an industry where software is still created by good, old-fashioned, by-the-book waterfall process, by outsourced developers. You know: the industry-proven, rock-solid, 20-year-out-of-date, slowest-and-least-agile methodology. Not only do the people who write the software never use it anger, they have no clue what the software is supposed to actually be doing. They don't understand our product, don't understand HOW these KINDS of products work, don't understand what engineers are doing TO the products, and don't understand what would be useful to have from software to help DO that. How many steps removed from actually USING the software is that? Well, you can imagine the frustration that end users experience on a DAILY basis, with ALL the tools they're supposed to be using, both home-grown, and customized commercial.

Gee… I wonder why there are so many shared Excel workbooks functioning as ad-hoc database applications on the network drives…

The most damning part of this is that there were some studies done on our engineering processes in relation to our competitors, and the numbers were bad. Really bad. You would think that senior management would sit up, take notice, and connect the dots. But they don’t seem to be doing that, which leads to one of two conclusions, and neither are encouraging.

Sounds god awful. What industry do you work in?

I find it hard to understand how a business like this stays alive. Really, how?

I'd disagree a little, the problem is not testing, it's building the software in the first place when it doesn't solve a real problem.

This so much.

Sadly, what you describe as the anti-pattern is actually the industry standard.

And you don't have to go far to see examples — Slashdot and Reddit redesign come to mind. Both are unusable.

> Having restrictions on filetypes is a bug, not a feature.

It should be - but for many school IT security types it really is a feature to limit file types

I fought this during my entire teaching career.

Blocking file types by extension is pointless. as you can just change the file type.

If you're worried about kids being able to run arbitrary python scripts on your network, then the security problem is not the kids, it's your shitty network.

People are given cash as bug bounties for finding security flaws in systems, but in schools they are punished!

>If you're worried about kids being able to run arbitrary python scripts on your network, then the security problem is not the kids, it's your shitty network.

How is this even possible? Unless your CMS runs on python somewhere and does eval() a lot. Then yes, that is a huge problem. Moreover, why would that stop anything just not called .\+\.py?

If your CMS does `python ${fileIjustdownloadedfromuser}` in a shell then we are in serious trouble.

I think it's also a problem when people are rewarded for finding these kinds of bugs that are not actual bugs.

Some bad person vandalised an obscure public Oracle repository on GitHub that's not even for any public product they're known for (OpenGrok). Instead of being banned, the owners restricted public edits. WTF? It's small things like this that end up being having the anti-pattern become the norm.

Could not agree more!!!

What about security patterns for web browsing?

I feel the logic is somewhat similar but injections to websites / applications may be easier and hard to prevent against, so filtering pornography may be useful. I’m a dev not a security expert so sorry in the lack of understanding. I am actually trying to learn more about security / hacking

Security: it seems to me that in the wild, 40% of it is security theater, another 40% exists primarily to ruin your mood and control you the user, and remaining 20% is actually around the right trade-off between utility and safety.

I agree that it is mostly theatre. I understand not allowing an exe, but if you have to download the file and rename it, how much of that would be unintentional?

This reminds me how for awhile I was emailing myself .tar and .exe files through Gmail or school email systems by renaming them to .jpeg files.

Recent-ish (past year) Gmail patched this (for .tar at least), so I started using base64 encoded text files.

Now though I just pay for my own email service away from Google.

O365 blocks ps1 files by default. ps1 files aren't executable by default on any windows machine.

why is the vendor that makes the OS (MS) making these types of decisions?

Agreed, but trusting the extension at the end of the filename for this purpose screams, "amateur hour."

Extensions were important to filter when Windows explorer was still lacking rules to forbid file execution based on provenance, but was already defaulting to a) hide the file extension and b) display whatever pixels were embedded in an executable as the file icon. The combination of a) and b) was making even moderately security aware users utterly defenseless.

HN? Let Oracle and SQL Server databases start using that without one forcing them to. There's a long list of stuff to be bothered with before even looking at HN.

I work in a corporate environment and I also write software -- both external and internal tools. My intolerance to unnecessary pain is one of the main driving forces in creating software-based tools.

The amount of pain inflicted on employees by enterprise solutions of various kinds is immeasurable. As a developer, I squirm witnessing so much unnecessary work and discomfort associated with simple tasks.

For example, even in 2020, managing expenses is so painful that employees consider not expending their spending.

> managing expenses is so painful that employees consider not expending their spending

That's not a bug for some companies, who would prefer to not reimburse you.

Managing expenses is only a pain because my company doesn’t trust me when I tell them I spent $20 on a meal. And have to give them both a digital, and then physical (signed!) receipt.

It's annoying and could probably be made easier, but these things are required by law. Also, not everyone can be trusted and it's not easy to tell.

No, but there are solutions that involve giving people a fixed amount of money every month for these small expenses (or a fixed amount per day for longer business trips).

I would assume most companies use per diem for business trips. Agree that it would be great with something similar for other small expenses.

But none the less, all company expenses needs to be verifiable by some kind of receipt in the accounting to be legal. At least thats how it works in my country. So someone has to enter that into some sort of system, ideally the economy people would take care of that.

Definitely not. We require digital images only, and not even an image is required for corporate card transactions under a limit.

I agree with everything you say, except the last bit.

You can't believe people aren't aware that concur is a pita and hence it reduces expense valid expense submission...

Concur is a pleasure compared to some internal SAP-based expense reporting systems I’ve used.

Concur, especially on mobile is pretty good. It’s a lot better than every single project manager tool that I have ever used.

I adhere to "dogfooding": use what you make, and use it seriously. Then you'll understand what design documents so often fail to communicate. Programmers and certainly architects should get onto the work floor, and actually participate in the job, preferably before starting their "real" work, but certainly afterwards.

The unfortunate part with enterprise software, is that in the end its all bought on tender basis. Every minute the programmers and architects spend participating in the actual job, they do not spend creating new features. So your product will either have less features than the competition, or your product will cost more than the competition.

Dogfooding enterprise software is mostly impossible, since the people developing it are pushed to deliver features, because that is what administrators/managers use to choose between software. They don't care about usability, because it is not something tangible you can check.

I agree. It’s just hard sometimes if you don’t experience the problem you’re trying to solve in your daily life. How can I dogfood construction software if I’ve never worked construction? Get a construction job?

Who are you making the software for?

If it's your own company or a client, it's not too hard to get them to let you tag along with someone who will be using the software.

If you're launching a startup then you should have customers lined up before you start writing code. Ask them if you can watch them work to better understand how you can help them.

Most people are happy to share when you show interest in their work and it doesn't take much. A couple of days can really break your false assumptions and give you a good idea of what the workflow looks like. You can pick up on details like the order in which information is available.

It's worth doing more than once too, presumably your software is going save time and impact how they work so you'll need to refresh your knowledge.

The real problem is that the people who decide to use the software are not the ones actually using it. This is the problem with top down decision making. And this is why enterprise software often sucks

It's the same reason architects can't design biochemistry laboratories. And trust me, they're bad.

You could have automated this with a macro or program. Or given extra credit to students that did.

Have you ever used Instructure? My university uses it (I'm a student). It's really great on the student side and from what I've seen really flexible and easy to use from the teacher's perspective too.

Strongly disagree. Recently took a graduate level database management course, and using Instructure was one of the hardest parts of the course. Poor information flow, too many places to have to check for notifications, tasks, and basic information.

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.

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.

>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.

The iPhone took almost a decade to get to the appropriate functionality. The part you're leaving out is most executives just ended up carrying two devices and whined to IT about "why can't YOU make my iphone as good at email as my blackberry???"

>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

Except I can count on one hand the number of fortune 500 enterprises that moved to gsuite over o365.

>Slack is another proof point - the "consumerization of IT" trend in general.

I'm not even sure how this is relevant. Companies that were using skype for business or cisco jabber likely still have skype/jabber running alongside Slack.

This reads like someone who lives in the valley and thinks the valley is in any way reflective of corporate America. Hint: It's not.

The iPhone took almost a decade to get to the appropriate functionality. The part you're leaving out is most executives just ended up carrying two devices and whined to IT about "why can't YOU make my iphone as good at email as my blackberry???"

That’s not true. The iPhone became good enough to replace the BlackBerry around 4 or 5 years in. By 2011, the BlackBerry was losing market share as Apple added enterprise features.

And yet neither Android nor iPhone today as as good at doing email as Blackberry was 10 years ago.

They do lots of other things a lot better, but email? Nope.

What did blackberry do so well in email?

I, for example, enjoyed the wheel. Scroll wheel to email you want to read, press wheel to open, scroll to read. To be honest I don't remember how I close email, click wheel again or another button, but the whole experience can be done with one hand/thumb easily, while holding coffee in another hand. Try that with iPhone.

Keyboard. Touch sucks for writing.

I can type so much faster with Swype-style typing. I completely don't understand the die-hard keyboardists

My issue with Swype-style - after having used it for about 8 years before switching to a phone with a keyboard (Android Blackberry) - is that having to wait for each word to confirm it got the right one is where the slowdown is. Touch-typing means I can keep going without confirming, because when I do mis-type, I can feel that my finger wasn't positioned correctly without having to do any visual confirmation.

Based on reactions from co-workers though, it seems I'm much more efficient at touch-typing than most of them, even on a fullsize keyboard. And the experience does translate to a physical phone keyboard, even at the smaller size, so that may well be where some of the disconnect is.

Note also when touch-typing on my phone, I get the full speed by using both thumbs, not just one.

I could touch type on blackberry far faster and more accurate than swype. Swype is better than nothing but it's not as good as the bb keyboard was.

I’ve never had any trouble with typing on a touch screen just as fast as my old Blackberry. Especially if you have autocorrect.

Autocorrect is more often slowing me down. It's only rarely correct.

Yep. Autocorrect's one of the first things I turn off on any device. I'd rather have a misspelled word than an entirely wrong word.

Case in point: people spelling "definitely" as (I assume) "definately" only to be autocorrected to "defiantly" without noticing. That sort of "correction" completely changes the meaning of a sentence.

This does not compute. I am a fast typer on all mediums, but a touch screen is just so slow compared to physical. I think I got around 80 wpm on my blackberry, there is no way I could do that on a touch screen. And iPhone autocorrect is terrible with any sort of tech jargon - frequently causing manual corrections.

it is just a habit. Here is a video from 2010 with 97 wpm on iPhone - https://www.youtube.com/watch?v=NNcTE5WJGdw

I've found that haptic feedback helps. My first smartphone was a handmedown first-gen iPhone, so I didn't really understand the point of haptic feedback because I wasn't exposed to it, but upon switching to a Galaxy SII and feeling a tactile response with each press I've yet to look back.

Every time haptic feedback turns off for "power saving" when I'm running low on battery, I immediately wonder how anyone ever manages to type anything at all without mucking things up all the time.

I'd still prefer a physical keyboard, though.

Search. I could instantly search basically my entire inbox in 2005. That was the power of BES. I still can't do that today on Android or iOS. If I'm looking for an email from 6 months ago or last year it takes FOREVER to find.

I just did a search for a keyword from mail that I knew would be old - 2005. It found it instantly.

For me and for a number of email "power users" whom I know, Blackberry strictly dominates iPhone email experience.

Stipulated, it definitely depends on personal preferences and workflows as to what you personally prefer.

But it is pretty incontrovertible that Blackberry was a finely-honed email tool with departures from that core use case being pretty tightly defined around the things you do ancillary to email (setting appointments, reading attachments, etc.).

iPhone is worse at that particular thing -- but vastly more capable broadly speaking for a universe of other things.

I'm still pretty confused about what blackberry did well. It sounds like they had a workflow that people that liked it liked.

Other than that, what specifically did it enable that the other phones didn't?

BlackBerry couldn’t read many attachments let alone edit them. Modern smart phones can run a decent version of MS Office.

The BlackBerry Email client definitely didn’t have a method of integrating third party storage providers like Dropbox which was definitely a thing by 2011.

I always thought their killer feature was the fact that they'd operate on pager frequencies, so you could get an email (or at least a portion of it) in what was quite often a cellular deadzone. Largely moot these days between the proliferation of WiFi and LTE repeaters.

The BlackBerry phones didn’t operate on pager frequencies did they?

It wouldn't surprise me if the BB push notifications worked over pager frequencies. I can't find anything online about how they actually worked, but the original two-way communications device from RIM was called the "Inter@ctive Pager"[0]. If I were to guess, I'd say it is possible the push notification went over a pager frequency and included a snippet of the message. The device would then be able to request the full message over the cellular data network. The pager networks of the time were more robust (and travelled longer distances), so the BB would be able to received the notice of a message (and part of the payload) even in a cellular dead-zone.

But, that's just me speculating...

[0] http://www.braddye.com/newsletters/2010/n22jan2010.html

So the first ones used pager networks, the next generation used cellular.

The push service was quite good IMHO. Every carrier that supported BlackBerry Internet Service had a leased line or VPN to the RIM NOCs. The phones would connect to BIS servers at the carrier which then communicated over these backhauls to RIM. Because it was all so deeply integrated in the carriers network (I believe the BIS servers acted as a Gateway GPRS Support Node), the BIS servers knew exactly where on the network each phone was, so they could send essentially a UDP packet directly to the device, which was listening on a particular port. No long standing TCP connections, and of course if the device didn't acknowledge messages, they were queued at RIM for when the device reentered coverage.

Email was provided by a server side process that opened MAPI (the original exchange RPC protocol) connections to exchange mailboxes and asked to be pinged if there were changes in mailboxes. When that happened, the BES server would pull the changes, package them, forward them to the RIM NOC over the proprietary SRP protocol, which would locate the right carrier, send the packet over the backhaul, and then from the carrier it would make its way to the phone.

Source: used to run a BES server

This sounds worse than modern ActiveSync - which Apple introduces support for in 2010 (2009?). You also didn’t have to send all of your email through BlackBerry’s servers.

With ActiveSync, my email will usually reach my phone/cellular watch/iPad before it reaches my computer.

True. The messages were encrypted, but ye if RIM went down, no email for you. Even if your email server was working fine.

Well, it being encrypted doesn’t help when RIM had the encryption keys and would give them up to any government entity.



So that applied to consumer users. When connecting via BES, the connection was end to end encrypted, RIM never had the keys.

In what ways?

I mostly agree although I also think a lot of businesses think they are a lot snowflake-ier than they actually are.

But in my experience, smaller businesses can actually be worse offenders in this regard. Large enterprises actually do have a lot of complex needs and even relatively small changes affect a lot of people. But I've had someone at a very small company argue with me that they needed their own Exchange server because Gmail (at the time) didn't have some features like sub-labels/folders that they were used to.

> Except I can count on one hand the number of fortune 500 enterprises that moved to gsuite over o365.

That's maybe another way of showing that UX is not the winning differentiator in enterprise that it is in consumer.

> This reads like someone who lives in the valley and thinks the valley is in any way reflective of corporate America.

I don't live in that valley, and I fully know that it doesn't reflect the rest of US or world, and that is why, indeed, enterprise UX does suck! :)

I think we agree... I'm not hearing an argument from you that it's because of superior UX that people are sticking to O365.

> That's maybe another way of showing that UX is not the winning differentiator in enterprise that it is in consumer.

But it is. That and useful features. Both of which Office has, and GSuite has not.

I don't remember the name of that "Word lite" program that was included with Windows for free around Vista/7, which could open less sophisticated .doc files and was a default binding for .rtf files. But compared to Microsoft Office, GSuite is like that program, but on the web.

I have worked in enterprise for 20 years and have always been watching the vast majority of my colleagues (by the numbers) struggle to make anything but basic use of Office. My experience has been that there are a few advanced users who enjoy the mastery of it enough that they know it inside out, but the majority of enterprise workers really just do pretty basic stuff with it.

Meanwhile, the killer app of G Docs (collaboration) is a very frequently unanswered need. People emailing attachments with ridiculous names like "contract_v2_final_finalforreal.docx", making conflicting edits that cannot be reconciled, carrying USB sticks around because their PPT presentation is too big for email and they can never figure out how to use shared folders, etc.

Hey, I'm looking into a solution to this problem, I wondered if there was a way to DM you about your experience? I've been working on something and would love to hear thoughts around how people solve this where gDocs etc don't. Thanks

Again this goes down to usability vs features.

Word has a lot of features and, for certain publishing needs, these are important.

But what gsuite adds is usability. You no longer need shared drives. You no longer need to email docs around, you no longer need Spec_new_v3_new.doc.

I don't even need my computer any more, I can use anyone's.

I also don't need the immense amount of publishing and formatting options word provides. What I need to do is create documents that can be shared and collaborated on easily.

i believe this was called WordPad. https://en.wikipedia.org/wiki/WordPad

Yes, that one, thanks!

Skype for business makes me think of one of Guy Kawasaki’s 3 reasons for a business to exist: to right a wrong.

Skype for business is an abomination, it’s morally wrong, it’s an evil that must die.

I’m hoping Zoom can murder it viciously.

Enterprise software is a sub-class of business software. Enterprises often operate quite differently from SMBs. Public US companies will have things like SOX compliance. And, the enterprises offering up services, like email, may be competitors in another space. If you are competing with Google on phones do you want them to host your email? Likely not.

The business world is complex.

Some complex business software is fantastic. For example Excel. It's complex but you can do amazing things with data without learning to program (which is most people). You can use it while being on or off the Internet (this is great on a plane).

For UX many have given up security features. Many of us now have free credit monitoring because that lack of security has lead to leaks everywhere. I know people who have had their identity stolen and even attacks on retirement funds all due to companies lacking in security. Our drive for the new shiny has left many vulnerable.

> For UX many have given up security features. Many of us now have free credit monitoring because that lack of security has lead to leaks everywhere. I know people who have had their identity stolen and even attacks on retirement funds all due to companies lacking in security. Our drive for the new shiny has left many vulnerable.

I would lay money that far more security vulnerabilities are due to overcomplicated customizability features than are due to simplified UX.

I would argue it's more complicated than that. In my experience, especially I started working for some enterprises, the people who make the complex software are also the ones putting in the time and care into security. It's not a causation but there is something to be said about culture.

Excel is programming, it just doesn’t call itself that so people won’t get scared off.

I wanted to do everything in Excel lately, but it (at least 2013 that I'm stuck with) seems to be a horrible frankensteinian mishmash of features that don't work together. For instance, there almost seems to be the infrastructure for building a virtual database in a spreadsheet, but there are a million different things that trip you up, like the not-quite-integration of PowerPivot, the use of DAX instead of SQL, the missing VBA interface for crucial things. I still don't know why you can use OData from Excel, but then you add something to the data model and try to get to it from PowerPivot, and you don't have permissions for the exact same URL and then the whole thing gets corrupted.

Within Office, it seems more practical to do ambitious things with Access, although that has its issues too. I apparently completely corrupted a database I've been using just by pasting part of a SQL statement that was >= 1024 characters as part of a VBA script.

It doesnt have to be though, its also a great whiteboard for brainstorming and mindmapping. It works for things besides numbers and functions.

Sure people could use notepad, onenote, powerpoint, other proprietary software, but they are comfortable in the grid like ridgularity of excel.

Another big gotcha that hits large public organizations is that the software must be ADA compliant. This is extremely difficult and expensive to meet. Most small vendors do not meet the minimum requirements or even consider doing so.

I got to be a fly on the wall in an organization meeting where we realized our third-party UI vendor had no roadmap for internationalization.

That was an uncomfortable day. ;)

Heh, I know of a major health record software that can’t handle time zones. So the hospital system has its instances sharded that way.

Once you cross a time zone, your records are much harder to access.

Is this the same major EHR vendor that tells its customers to shut the system down and go to backups during the DST fallback hour?

There were many potential patient safety issues due to mishandling of times during that hour and the suggestion to just use the backup worked because it happens at 1 AM when little is going on other than emergencies which simply have to to manage with read-only access during that time.

No, but it is an interesting problem. If something is done every 4 hours at standard times, do you shift all standard times by an hour so it’s still every 4 hours or have a gap of 3 or 5 hours for that task.

I kinda like the idea of regular scheduled downtimes of stable systems, just for real experience on downtime procedures.

Interestingly it is rather straightforward to meet. It is very difficult to prove compliance. Most sites with web front ends should be ada/508 compliant, but documenting it is similar to other paperwork exercises (iso9000) that cost a lot but have little real impact.

As someone who is building a B2B SAAS company and made the decision to not focus on large-enterprise, I think you're both right.

At the end of the day, it's just plain hard to create a clean effective product that can be used by 5,000+ person organizations.

Regardless of use-case, boatloads of data will be collected in large-enterprise software and it has to be transferred and presented to many end-users in a clear way. And very rarely will it be one exclusive universal data-type. Usually it will contain varying types of information that will be needed by multiple teams and maybe across several different office locations. And that's just the product issues, let's not talk about sales or compliance.

It's just plain hard.

This gets closer to the underlying truth. Even if you had smart procurement people who understood the benefits of great UX, another issue would be that enterprise problems are typically sub-scale compared with today's consumer products. There is one or two orders of magnitude more complexity and one or two orders of magnitude less users than in the consumer space, or even less for niche industry needs.

Even if you make it up with additional willingness to pay per user, the market isn't always there for spending a lot to design, develop and iterate on the perfect UX.

I think a lot of SaaS companies end up failing fast when they focus on the enterprise. The sales cycle is longer, and having a massive client can end up putting their individual needs over features that would make the product more attractive to the market as a whole.

SaaS makes the most money when users can self-service in large numbers at relatively low transaction costs, which typically means SMB should be your first market. The enterprise channel is where you go only once you have a mature product and a healthy revenue base to do the enterprise payola scheme with consulting companies.

When you go over after whales, they can fund your business without having to go after VC funding and you can milk them to go after smaller clients.

In enterprise the incentives are all wrong - individuals who are decision makers for enterprise software/networking/security/etc have an incentive to make their job as complicated as possible so they can be promoted or build their empire through hiring new resource to keep on top of the complex web they've built

This is something I see all the time when a new developer comes on board with stars in their eyes. The first thing they try to do when they see a glaring inefficiency is fix it. Then they get burned at the stake because the inefficiency they are publicly denouncing is the reason a whole team of people exist. Large portions of every enterprise are essentially parasitic.

You're confusing "checklist-driven development" with developing needed features. I'm guessing because you assume that the features actually work. The problem of enterprise software is less that the features are unnecessary, and more that they work only on paper, but not in the real world. Since the software is sold to people who aren't using it, they can't evaluate the actual implementation and usability - so what gets sold is garbage that meets criteria.

Now what I see you arguing for is not "consumerization of IT", but infantilization of IT. Modern UX is oriented about dumbing down software, removing necessary features because they're "unused"[0], and about a myth that you can eliminate training time. Which is why people - again, not the users - buy into it. The sales strategy is: put it in the cloud, ask for subscription while screaming "it's OPEX and not CAPEX", and remove any and all features so everything looks slick on the demo, and the problem only becomes apparent when somebody tries to actually do something with it.

And then actual users have to suffer. For as much as software is eating the world, I wonder how much actual, hard productivity does the modern software of the web cost, compared to the software it displaced.


[0] - The way "data-driven" approach would tell you that there's no point adding airbags to cars, since almost nobody uses them ever.

> 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.

I think there's a different dynamic at play: the individual is making purchasing decisions based not on what they think the business needs but on what they personally want. E.g. JIRA has a huge number of micromanagement features that I doubt procurement departments are looking for; rather they appeal to managers in companies where they're the ones making purchasing decisions.

Related, my co-worker and I have evaluated a dozen different tools big and small, including Jira and that Jetbrains thing. And we still can't find a system that would meet our needs, which I think are simple:

- Model tasks as DAGs, not as lists. I.e. I want to work with a dependency graph (JetBrains thing sort of can do that with task relationships, but the UI isn't oriented towards exploiting it).

- If that's too much to ask, at least allow to nest arbitrary amount of subtasks, and not just one (like Jira and almost everyone else).

- Fast.

- Proper keyboard shortcuts (again, JetBrains is good at it, but it's missing some crucial shortcuts and UI concepts, like "add a subtask to current task" and "go back to parent task").

- Allow estimating how long the task will take, without having to specify when it'll start.

- Render a proper GAANT chart and do a critical path analysis.

I really think I'm not asking for much, and yet nothing I've seen can do it. Most Jira-like systems try hard to be "agile", which means sacrificing features and utility to chase misguided ideological purity (like the whole "no subtask" thing).

Seriously, if Emacs had a first-class support for real-time collaboration, Org Mode would be vastly better than all task management offerings on the market.

What's the point of nested subtasks? I hate creating subtasks as it is, but now I have to create this nasty tree of sub-subtasks?

Almost seems like "micro-tasks" at this point.

Breaking down work into steps. Not all top-level tasks are truly of equal size.

Micro tasks are good.

The compelling feature of gsuite for my employer was apparently the ability to turn off IMAP etc and therefore rule out emails being kept locally/beyond the retention period for better access control/cheaper legal compliance, not anything UX related.

That's... Kind of hilarious.

I'm assuming your employer has never heard of printers or copy-paste. ;)

You're thinking about this very much from a techy point of view.

We have a similar value prop with our platform (we store PII including actual identity documents).

It's not about making it impossible for users to download and store sensitive data. Everyone knows that that's impossible - yet somehow Snapchat and its disappearing messages is still a thing.

Instead, it is intended to be coupled with policies. As long as the company has a policy against downloading/storing confidential information, then the company is covered.

Then, when a case of e.g identity theft happens through a rogue employee, the company can demonstrate that it has taken all reasonable steps to avoid it.

That is a much better position than showing up in court and saying "yeah, we didn't try to prevent people from downloading PII, that's impossible anyway".

This is exactly right. It doesn't stop espionage or a rogue employee - it is not supposed to; but it does stop inadvertent duplication all over the place in ways the company could be liable for due to inaction or insufficient policy around PII, etc.

Not every employer hires folks like you who go out of their way to print confidential emails so they can violate customer privacy.

MANY employers have folks who unless you put a speed bump in their way would have employees inadvertently sync their entire email history onto their kids computer or a random computer while traveling.

The ENTIRE POINT of MANY of google's settings is to allow for those railings to be put in place. This is so employees who aren't out to abuse data can go about their day with reduced risk of inadvertently screwing up.

This is a big risk factor (I'd argue a much bigger risk factor than intentional employee misbehvior).

Additionally, once these controls are in place you can actually drive even better security where needed - it is possible to do a USB / printer / no phone lockout for high security ops - and is done when needed (very rarely). Thin clients are actually popular here - remote desktops another layer making it harder to dump the x million records out of system.

I don’t think it’s fair to jump to the conclusion that management at the GP’s see their employees as malicious. It’s far more plausible that they just don’t want emails automatically downloaded and stored on everyone’s computers.

Many companies have strict regulations on data retention and they’re regularly audited to ensure compliance. By keeping the data off employee computers, compliance is simplified.

Or forwarding, or clicking "archive" instead of "delete", or screenshots...

The iPhone, via the App Store, and Slack, via the extension marketplace and APIs, are _incredibly_ configurable. Mindboggling so.

(And many companies are using MDM along with the iPhone, so it's not like they don't think they need control there.)

It's worth noting that outlier in size or organization-count may not be outlier in money, and money talks when designing enterprise software.

There are a handful of banks, but they have all the money. The specialized features they care about speak very loudly at feature prioritization meetings.

> 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.

O365 far exceed Gsuites market share and is generally better for users because most companies users still use the Outlook desktop client.

MS Teams exceeds Slacks market share. Team instant communication is a minor blip in the overall market for Enterprise software.

> Notice how all of these are associated with crappier UX.

Having configuration that adopts to compliance and regulation is UX. The U in the UX is just not the end user but the admin user.

Consumerization of IT is absolutely a thing, but not for this is for productivity apps, not enterprise grade apps - you're conflating the two.

To pretend like all of the features demanded by enterprise middle and upper management is irrelevant and unthoughtful, as another comment said, is just "typical SV think". UX to the end user is certainly becoming much more relevant in the enterprise space, it's not as black and white as you think.

(note - i'm a former SAP employee and I've certainly seen my fair share of shit)

I think you and I are saying the same thing. I'm not saying Slack makes Msft irrelevant. Just that Slack makes better UX which is why they're managing to make sales outside of IT traditional channels - because once users have the power to do it, they choose something else than what IT gives them. Same with iPhone. It got so bad that in many companies, people started using them in breach of corporate preference for official systems.

Just today I met with someone who carries two laptops for work: one that is enterprise-IT sanctioned to access internal resources and is super restricted; the other one to do actual work. How does he work with two laptops? SDcards. In 2019.

The fact that all the craptastic enterprise UX is holding on so well in terms of the $ amount indeed is the observation: enterprise services for the most part do suck. I don't think, and I didn't say, that it's always a winning commercial strategy to focus on UX when it comes to enterprise. Based on available evidence, I too would conclude that focusing on giving middle managers a power trip of control options looks like the better strategy, UX be damned.

This, in my experience, is what seems like the most likely culprit. A CTO/CIO gets impressed by a fancy feature list when really, what would be the best fit is something simple, stable, and easy to use. We have more and more examples nowadays of ease of use beating out giant monoliths and it's only likely to continue except in a few fringe use cases.

There’s supposedly an axiom for salesforce that it’s easier to be successful with salesforce if you adapt your business practices to match salesforce instead of the other way around.

Same with SAP.

> But the average business does not really have such needs

Well the average business is by definition not an enterprise. Enterprises need things like a solid AD integration, self hosting, enough monitoring coverage to put things like DLP and anti virus controls in place (yeah I know anti virus sucks, but work in a company with 10,000+ people, and you’ll see it getting genuine hits every day).

The fact is a lot of the modern software with good UX that we all love doesn’t meet these basic requirements, or at least doesn’t meet them as well as the old enterprise stuff does.

Many “enterprises” are their own worst enemy in terms of UX, by simply not valuing it enough. But I’ve worked in some that have made incredibly well organized, well resourced, and well supported attempts to modernize their technology stacks, and the truth is that the best and most innovative software that’s produced today, often (and perhaps rightly) doesn’t have the basic needs of enterprise in mind. So even with the best intentions, you often end up stuck using apps with poor UX.

As a side note, you can do absolutely fantastic DevOps in enterprise these days (even if you’re on a VMware stack). But a lot of the user facing stuff still sucks. Especially IM, which is why I have little hope that the enterprise love of email will die anytime soon.

> There absolutely are outlier businesses like banking, government, healthcare and other highly regulated fields where they do have critical control needs.

Control needs, yes, but there’s still a massive amount of trust required.

If the software could always prevent you from doing the « wrong » thing, then that task would be automated. Logging every action isn’t the complicated part.

But the bit about workflows is 100% true. No two hospital systems are the same. You can’t buy your Diagnostic Imaging equipment from the same vendor as your registration system, each with their own workflow.

You could probably fingerprint every hospital system based on which different clinical vendors they’ve adopted for their various functions.

Exactly right, even to the point of bringing up a few specific industries that do in fact have specialized needs.

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.

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).

Despite what it seems, demand for features is really NOT why enterprise software is (so often) bad. The problem is how easy it is to SELL fundamentally bad software simply because you can tick a box saying it has the feature.

Yes, I too have seen the phenomenon of having too many people demanding features where the result turns out to be an incoherent mess. But I also know that if the massive amount of time and money that had been spent purchasing a box-ticking Enterprise Software Solution and subsequently hammering the awkward, unwieldy platform into some semblance of working order had been spent instead on direct improvements to the existing workflow software, then everyone would have been much more satisfied. And yeah I know I shouldn't speak hypothetically but you'll just have to decide to trust me on this or not.

I think you're absolutely right. One error some organizations make is trying to buy a COTS product they assume will be simpler and more robust (and have its bugs fixed "for free" by the developer of the product) over hiring a part-time or full-time staffer to maintain and improve their existing non-COTS workflow (including owning all the bugs).

Sometimes (I have no global numbers to even guess at how often), they end up discovering that the COTS product requires expert-level configuration and administration anyway and now they're footing the bill for someone else's licensed solution and a staffer to understand it and make it work.

They aren't, though. If the big "Enterprise Software" players like Salesforce and SAP sell to healthcare providers it's either not with their flagship products, or else it's with incidental business processes not related to their core and peculiar requirements.

I posit the BYO device went forward because enterprises realized they could make people pay for their own equipment.

Office 365 isn't even gdpr compliant.

the prospect of running an enterprise on gsuite is..amusing.

No serious enterprise uses gsuite , it's a small businesses tool.

iPhones and smartphones in general have greatly increased the risk of data theft or being spied.

Insurance companies are more than happy that others have switched to smartphones (I worked in insurance consulting for cyber risks)


I don't think your comment is accurate, based on my first-hand knowledge of large companies that use gsuite, as well as their customer list in the above link.

define small?

My partner worked here - https://en.wikipedia.org/wiki/LafargeHolcim

They used gsuite for email, o365 for other aspects. Required iPhones if you wanted a device - wouldnt allow android at the time... but that may have changed since

Does 200k headcount count as enterprise?

iirc Salesforce uses gsuite internally

BBVA is a bank with 140,000 employees, and they use G Suite. Office 365 and G Suite aren't small business tools anymore.

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.

A lot of SaaS businesses aren’t really SaaS, they’re glorified custom development shops with a few high paying customers.

That’s not a great business to run though as it’s very difficult to scale.

Far too many fall into the trap of saying yes to the first BigCo that comes by early on because they need the $$. While they neglect every other niche and business where it could fit like a glove.

Or more often doesn’t even bother legitimately testing it on the open market since their very limited programming time is spent serving BigCo and doing support.

A lot of companies using SaaS have a bunch of different systems interconnected with Zapier or their own systems. Which IMO is far more like Unix than x product that turns into a full blown CRM, CMS, ERP etc tacked on top a niche product.

Building highly customized software also generates tons of risk for smaller companies as it binds their entire revenue on the success of a small group of other companies who may die, switch core business, or get stolen away by a bigger enterprise software sales team.

I’d much rather build a niche software product and instead of building a CRM on top just add every sort of API, webhook, Zapier, or direct integration. Or isolate them into separate products with shared authentication and logging systems.

> they’re glorified custom development shops with a few high paying customers

That's true, but sort of necessarily so, though. How else do you build a product that meets such a broad set of needs? Someone's got to do the work. At some point, features are going to drop linearly.

A lot of the time the client would be better off buying actual custom software. It's very easy to end up with a SAP (say) "configuration" so complex that you'll spend more on maintenance than you would if it were a standalone program.

> A lot of the time the client would be better off buying actual custom software.

I agree in theory, but I thoroughly disagree in practice.

If a client could spec/develop good software and cost it realistically, then sure. But I have rarely had clients like that - instead they think the problem-space is simple and end up with a half-baked solution that can't be maintained.

Developing greenfield software is a high risk strategy. (Edit: with a high reward if core function, and not much reward if not core).

The pretence that there's cost savings, followed by the sunk cost fallacy.

This happens because management is doing cover-your-ass methodology of software procurement. If they backed a greenfield development and it failed, then get blamed. But if they choose SAP/salesforce/bigCo, the same failure can be blamed on the vendor, or if it ran over budget, they can claim the vendor is expensive.

That's very true but still, in my experience anyways, it's much easier (i.e. perceived as 'less risky') to buy SAP and attempt to roll it out than to convince others that custom software would be better.

'Custom' is scary in a way that 'customizable' isn't.

It's hard not to wonder what might happen if more managers and executives became aware of "The Inner Platform Effect" and that "customizable" often just means "custom, but a worse, more expensive programming language".

Are SaaS businesses really customizing for high paying customers? They may build new features which are then made available to other businesses but I would be surprised if there are separate source trees.

The other issue is that a "great business" and "scale" are not synonymous. In fact many of the current batch of companies of great scale, like Slack, have spent enormous amounts of money to get there, and still lose money after becoming public. Then you have a company like Atlassian, with a confounding mix of enterprise products that are hard to use: but a fantastic businesses that's been profitable since the very beginning.

I do agree with you that the APIs, webhooks, and Zapier integrations solve the problem of customization, although I'd still say it's less customization and more a bevy of options.

> Are SaaS businesses really customizing for high paying customers? They may build new features which are then made available to other businesses but I would be surprised if there are separate source trees.

They are often using the same source tree and instance, but are enabling feature flags for certain customers. This often extends beyond code to data and caching. These don't get maintained and are a pain for support, as well as developers/operations. Over time they are almost as bad as a separate source tree.

That’s why I said they aren’t true SaaS companies. There are thousands you’ve never heard of in every major city with a few super niche customers.

And scaling beyond 2-3 real customers does make a very big difference for any legitimately good company.

This has been my experience too, but with a slight difference - the new feature is very often an ask from sales, who are trying to close either a big new sale, or a big renewal. The prospect/customer demands some obscure feature that like 1% of our users will use (at most), but they’re a big prospect/customer. Product/UX/dev push back, say we should be working on features, performance and reliability that will benefit most customers, but it’s hard to come up with the precise revenue impact of this. Sales are better at convincing execs, and “this will help us close a $1 mil/year deal” is very tangible, so the new feature gets built.

This is kind of a symptom of “the buyer isn’t the user”, though. Often we build these features, then monitor usage, and the customer that demanded it doesn’t even use it! Or we build it, and it doesn’t matter, we still don’t close the sale.

I think the core issue is “building for users” and “building to close specific sales” are often strongly at odds with one another, and most of the time “building to close specific sales” wins.

"Theres no overrulin g UX voice that can say “no, dont build that feature because theres no way to maintain the delightful user experience”"

This was arguably Steve Jobs key role at Apple.

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.

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.

There's a similarly apocryphal story about cutting the ends of ham off.


the other half of this is Chesterton's fence; don't go removing policies solely because their history was forgotten

perhaps the ends were being cut off because they often rotted near-invisibly faster, and now you've gone and poisoned the whole family :-)

This story needs a write up! I'm fascinated!

Someday I’ll write a book or something. There’s a deep well of crazy stories like this that I’ve run into!

please do

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.

You actually do probably need your IT department to approve your use of Basecamp and Trello. It's very easy for project management and tracking tools to accommodate sensitive information like pending deals, new launches, or even PII. Your IT department probably isn't happy about rogue usage of external/third-party tools for storing data that they haven't properly tracked and can't wipeout or revoke if you quit.

Whether or not you choose to respect those needs, they very much still exist for all larger publicly traded companies.

Shadow IT will always be created when the existing system or IT group can't or won't support the users' needs (imagined or not).

A good rule of thumb is, if you think your <medium-to-large corporation> doesn't need Shadow IT, it means you're not already part of your company's Shadow IT circle.

that is a funny comment :) thank you.

I should say, those needs exist for all companies, it's just that the larger publicly traded ones have more to lose from e.g. a GDPR violation, data exfiltration/compromise or accidental leak of financially impactful data.

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.

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.

>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".

Lol, let's be realistic. If a PM is in the situation to decide that and does so, in a few days he'll find himself in a meeting with some higher ups to discuss how to find a way. (Unless of course 10k is insignificant for the company and there's already a hard roadmap for higher value projects.)

> It's also worth pointing out that the simpler the software, the more likely it is to fit in with more companies' workflows

The problem is that's not a continuous function. Leave out specific features and you lose entire industries.

Incentives are not aligned for enterprise software authors to lose entire industries.

>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.

I had the same reaction. I was wondering, "Since when are Word, Excel, and Photoshop enterprise software?" I've been using these as consumer desktop software for decades.

That said, I do agree with GP that enterprise software is complex because it's designed to be adaptable to existing processes, whereas simpler software seeks to adapt the user to its prescribed process. And even without being an enterprise, I often find myself drawn to software that adapts to my needs and preferences rather than the other way around.

Just because the advent of mobile-focused product sensibility has seen a (regrettable, in my opinion) general drift toward significantly reduced feature sets in software does not mean that existing software with broad feature sets is now "enterprise."

Anecdotally, 20 years ago, scores of programs allowed the user to easily and broadly customize the colors of their user interface. That sort of flexibility was among the first features on the mobile simplification chopping block. As a result, most software created within the past few years has a single "true and good" color scheme dictated by the designer. Today we see that evolving slightly with the popularity of "dark" schemes, giving the user a choice between two, but only two, designer-crafted themes.

> Since when are Word, Excel [...] enterprise software?

Since Word 1.0.

Why do you think it is called Microsoft Office? The 1989 edition of Microsoft Word cost $500, equivalent to over $1,000 today, for a single seat. That's not consumer software.

Microsoft Home didn't exist until 1993, a decade into Office's life, when it had achieved complete enterprise dominance -- thanks largely to its competitors' failure to release Windows version in a timely fashion in the late 1980s & early 1990s -- and Microsoft began pushing into consumer software.

>Why do you think it is called Microsoft Office?

Some friendly fyi of MS history...

Microsoft didn't use the "Office" branding until 1995. Before that, the computer industry called it "productivity software" instead of "enterprise software". In the 1990s, other software companies (like Borland and IBM) were bundling word processors + spreadsheets + presentations + databases into an "office suite" for a lower package price.

In the 1980s, Microsoft Word was competing with WordStar and WordPerfect and those were all consumer software for personal computers. Consumers could go into an office supply store and buy shrinkwrapped boxes of those software titles. They didn't need a purchase order from corporate accounting to buy an "enterprise volume license". And consumer magazines like PC Magazine and PC World would run articles comparing MS Word to WordPerfect, etc.

Yes, a Fortune 500 corporation today can buy a enterprise volume licenses of MS Office (or Office 365 cloud subscription) but MS Word's roots definitely included the consumer sector. I don't think the example of MS Word fits the author's idea of "enterprise" software.

There was also Microsoft Works, which was Microsoft's first integrated word processor, spreadsheet, and database. That was the low-cost consumer-level package for quite a while. It was often OEM-bundled, in hopes of eventually inducing users to buy into Office proper. Works was sold as late as 2007 before being retired in favor of Office instead.

Microsoft Office was first introduced for the Mac in 1989 and for Windows a year later.

A decent computer was $3,000, or 6x the price of MS Word: https://www.zdnet.com/article/1991s-pc-technology-was-unbeli... Today Office is $150, and decent computers are still in the 6x/$900 range.

The shift was in computers, from enterprise to consumer, and the software followed.

MS Office Pro is £420 [1].

A Dell all-in-one (not especially budget), is £580 [2]. A bulk buy for enterprise would be cheaper. This is inclusive of the cost of MS Windows OS.

In the UK a computer that can run MS Office decently costs around the price of the software.

You can see why MS create a new version every few years; but why do offices keep buying it.

[1] - https://products.office.com/en-gb/buy/office [2] - https://deals.dell.com/en-uk/productdetail/2sue

When people say "Enterprise Software" they are not talking about shrink-wrap single-user office productivity applications like word processors and spreadsheets.

Maybe there should be another term to help clarify for people who don't understand the difference, but the difference really should be obvious from context.

In the workplace, people like using MS Excel because the alternatives are ridiculously inferior

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.

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

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.

You actually need to understand the basics of relational databases in order to use Access effectively (unless you are only using a single table - in which case you might as well use excel).

Many people don't need complex features of Excel, LibreOffice is pretty good. Many people have Excel and don't even get to basic functions like vlookup, nevermind anything that is actually lacking from other applications.

Yes, I certainly wouldn't call Office enterprise software.

But there are enterprise versions of Word, Excel, and a few others. And it's worth taking a look at what those versions add. By and large, being able to centrally manage and update from the IT department, and even being able to deploy additional content (plug-ins, templates, etc).

So, they're not client-server, but they do add a server into the mix.

The other common set of features is related to distribution and access. Encryption, workflow management, integration into server-hosted software, etc.

At a certain point, I think that enterprise software development starts to look like enterprise IT consulting. The line between then is pretty blurry, and I think that the really successful enterprise software shops are the ones that don't have an allergic reaction to doing consultant-y things as part of the product/services they offer.

Regardless, the purpose and core features of Word and Excel have not changed in 20+ years. MS Word is a Word Processor. Its purpose is to input and format text. Excel is a spreadsheet. It's purpose is to be an interactive way to organize data in tables.

Mentioning them as an example of "Enterprise Software" without specifically clarifying the Enterprise-features you're talking about is a mistake at best and disingenuous at worst.

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.

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.

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.

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.

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.

> 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.

> 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.

> 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.

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).

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.

Half of the people I know who love Excel in that way would now be making significantly more money if they didn't. These people fall into two groups:

The spreadsheet jockey who just likes doing cool things with the data. Excel is just powerful enough to satiate this guy long enough for him to fall out of the habit of rethinking his workflow. If he had moved on earlier he'd be a DBA or a data scientist by now.

The other type is the small business owner who is pretty good at spreadsheets but whose business is outpacing his spreadsheets' ability to keep up.

On three separate occasions I've had this sort try to hire me to help find ways to make their workflow scalable, perhaps by helping them write a little custom software. The problem is usually that the time for finding an alternate method was years ago. The spreadsheets these people come up with are amazing, it's like they've tricked out their tricycle so much over the years that it can now fly, just not well.

They always want to pay for my spare time, but the complexity is always such that they need somebody full time.

> would now be making significantly more money if they didn't

Er, I think reality is closer to "they would be making significantly more money if they loved python more than Excel".

A wheelchair is a large clunky device that can't go up stairs or rocky hills. Legs are far more versatile. But it is incorrect to say that someone can go many more places if they didn't have the wheelchair.

You said "half of the people.. would be making significantly more" and then proceeded with further grouping. I assume the subgrouping applies to that same half?

The other half of folks are quite successful hedge fund, private equity and consultancy partner types, and I suspect those folks would not be making significantly more money if they had stopped using Excel and invested time in becoming DBAs, Data Scientists or accountants...

Yeah, perhaps I should have been explicit about the fact that for some people it's absolutely the right tool for the job. My mom loves it, it serves her well, and her use cases don't require her to go beyond its capabilities.

But if fully half (admittedly a subjective assessment on my part) of a tool's users would be better served by not using that tool for one reason or another--that's a pretty significant subset.

Don't forget, the spreadsheet jockey not only shoots himself in the foot, he can also saddle his whole team with a dependency on his undocumented, un-version-controlled spaghetti macros, which will become a maintenance nightmare for years and years!

Yes, Excel really is a good product. But there are a few things people do consistently complain about with it in my experience:

- lack of forwards compatibility. When someone sends you an Excel 2016 file and you’re stuck on Excel 2013 because your corporate hasn’t upgraded yet, it’s a total PITA.

- weird bugs. Sometimes spreadsheets can get corrupted in weird ways so that they crash Excel and there’s nothing you can do about it and no way to fix it. Sometimes these bugs only appear on certain versions of Excel

- lack of decent built in formula tracing (ie something which brings up a dialogue and you can click through each reference in a formula browsing back and forth and going up and down the dependency tree). There are a few third party add one that do this but it really should be built in.

- lack of a decent way to see what’s changed between two versions of a spreadsheet

I’d also say there’s an inordinate amount of abusing Excel to do database tasks out there. People have spreadsheets which take minutes to recalculate which could be done in less than a second even using Access, let alone a ‘proper’ DB.

You want an older version to support all new features. That's not possible unless you just change the ui on each version.

If you're going to break compatibility, at least fucking fix the dates.


It’s not new features. Sometimes for no particular reason, a sheet which uses no new features isn’t backwards compatible.

In any event, it should be able to fail gracefully ie still load the sheet but not be able to calculate cells using new features and show a warning.

The great thing about Excel is that it is easy and intuitive to use just the basics, and it is difficult to accidentally stumble onto its advanced and complicated features by accident.

With Word, on the other hand, it is easy to have created a large document and then just as easily screw the whole thing up from beginning to end by clicking the wrong button or key-combination.

Yeah that was a very bizarre grouping of software. I’ve never before heard Photoshop or Excel referred to as enterprise.

There is a lot of bad enterprise software out there, Salesforce, Oracle, and SAP are basically catalogs of it. The fundamental problem as I’ve seen it relates to contracts and integration. Good software, the user can bail at any time.

There is a very simple set of red flags: the company doesn’t list a price, you have to talk to a sales person, and you have to sign a long term contract. I’m not aware of any software that fits those three that is enjoyed by its users.

Regarding Excel, its Mac version is terrible. Our heavy users have to run the Windows version in a dedicated Parallels VM to get anything done once the sheet contains more than a few hundred rows.

i used to be a heavy excel user, when i worked on windows, it was great for eyeballing data quickly, now, in a different job, i use a mac, i would really do anything i can to avoid using excel - visidata FTW http://visidata.org/ . I really don't miss excel at all

I was a workshop at the google office in Toronto a while back, and people asked when Google sheets would be able to perform big data analysis.

The presenter looked confused, and then the group asking the question clarified that their big data workflow involves loading millions and millions of records into excel and they would have trouble migrating to google cloud until google sheets could match excel in performance.

Somewhat unrelated story, but it shows how well loved some software is, and how some users will take it to use cases you never imagined.

> big data workflow involves loading millions and millions of records

Dude, if it fits on your laptop disk, it's not big data. Here you're talking about “big data” that fits in RAM on my cellphone. Somebody needs to get over himself.

But if Google Sheets can't fit the data they are using, it is by definition "big data", even if it's not Big Data. I think this over-protectiveness of the definition doesn't really serve anyone.

It serves everyone to have relatively stable meanings for words and phrases. "Relatively" because of course there is natural drift over time. But if today I write "big data" and it means "millions of rows in Excel" to Bob but "hundreds or thousands of terrabytes" to Jane, it's effectively useless to use in communication.

Put another way, that Bob thinks he's dealing with "big data" doesn't mean he is in fact.

In four lines you manage to be arrogant, insulting, patronizing, and intellectually sloppy (“by definition”?) I'm disappointed. I'd like to invite you to produce a higher level of discourse.

...you can't be serious. This is an incredibly over the top reaction to a very mild reply. Not to mention that telling me you're disappointed in me and inviting me to "produce a higher level of discourse" is far more arrogant and patronising than anything in my original statement.

But anyway, this is very obviously off-topic. I don't think it serves the wider community to continue this conversation so I'll leave it here.

Well, I'm certainly guilty of the same offense!

There's a company in my building that outfitted their team with $30K+ HP Z series workstations with 256GB of RAM... to run Microsoft Excel 2016.

That's more RAM than my cellphone has, but less disk than my laptop. It's getting close to being “big data.”

Right, if it's only millions of records, why can't Google sheets accommodate it.

DHTML involves trading 99.9% or so of your computational power for greater convenience of programming.

That's really strange... I always found Excel to perform dreadfully on data sets with even just hundreds of thousands of rows - it was always easier to just load the data into a database, or manipulate it with a script.

That's because you don't know how to use Excel (this isn't a knock on you, no one ever tells people how to use Excel). Excel sheets have a hard row limit of around a million rows, but long before you approach that you will have moved your data into the "Data Model", which is a relational table engine stapled on to Excel, or to some other backend which you will query from Excel (often via the Data Model).

Yeah me too, I find MS Word very useful too tbh. Not sure why higher level comment thinks people hate them.

Try to use the French version of Excel, and you'll understand. They renamed function names. Everyting. Not a single word makes sense anymore.

Larger issue is that Excel formula language has different separator characters depending on the locale. This would not be that bad if this would be case only for presentation in UI (.xls contains parse tree and .xlsx AFAIK always contains en_US syntax), but this difference is even in the format of CSV files processed by excel (there is significant portion of the world, where the C in CSV stands for semiColon, as far as excel is concerned)

I switched the language of the OS on my computer for this very reason. This is idiotic.

Wait, really? As in '=somme(A1:A10)' to add a column?

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.

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.

The times when this was decided are remote in terms of computing. We're probably talking about mid-eighties. Excel is an office tool, and probably most of its users work in offices where not a single word of English is spoken, ever. So I don't think it was "asked by the users" but rather what's expected from a basic office tool, to be localised in your language.

That's expected of Excel, Excel is an office tool and not designed for software engineers, a lot of its users don't understand English.

Well there isn’t any better spreadsheet software in 2019. Like what even comes close in terms of features and fit?

Photoshop. I think it’s a tiny little more mixed opinion of the overall program in terms of UX, but again, the closest replacement might be Affinity. And that is too new.

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.

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.

> 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.

> That enterprise software may very well be the best software that includes all those needed features.

How come you can't have something nice & even decently working for: pay, HR, vacation, expenses tracking?

Or more, how is it possible that obviously unfit and malfunctioning solutions (for problems that have been known, solved and specified for years) are still on the market in 2019 in companies that pretend to be serious about software?

Pay, HR, and expense tracking are extremely complex areas due to federal / state / local labor laws, collective bargaining agreements, and individual organizational policies. Any application which deals with all those complexities will inevitably be full of defects and usability problems. There is no solution, it's simply reality.

Do the users of the software need to know about all that complexity?

If the answer is: "they definitely do", then you are right. There's no way around it.

If the answer is: "No, they only need to know about 4% of it. The rest can be automated and hidden away." then the problem is that people aren't incentivised to pay the cost of building that software.

There is a broad solution:

Hire engineers, UX designers, and product managers to spend time to solve those problems and to manage that complexity. The problem is that this requires the time and effort of skilled people and that requires a sustained commitment of money. So that requires someone with decision-making power to allocate money from a budget of limited resources.

If the additional UI improvement helps win sufficient revenue, then its worth it. But if the additional UI improvement doesn't persuade decision-makers or only helps 1 client account, then it is not.

In this area of enterprise software, the users absolutely need to know about the complexity for compliance reasons. Any errors can potentially result in criminal charges, civil liability, or at least bad PR and employee morale.

Payroll might seem simple but in reality it's full of complex edge cases. For example, employers sometimes receive court orders requiring them to periodically seize a certain amount from a particular employee's pay in order to satisfy a legal judgment. And in some cases there can actually be multiple such orders that would effectively reduce the employee's take home pay below zero. Now what do you do? Please explain how engineers, UX designers, and product managers can "manage" such complexity.

> Payroll might seem simple but in reality it's full of complex edge cases.

oh I would definitely have assumed so. My question is to what degree does the UI need to lay all that complexity right out for the user and to what degree can it hide it?

If humans inherently need to learn about all that complexity, then the best you can do is make it not-needlessly complicated.

> Please explain how engineers, UX designers, and product managers can "manage" such complexity.

I can't do so in the space of this text box. The answer is practically the field of software engineering.


I'm curious what your thoughts are on https://docs.gusto.com/ Is it another "yea, this covers 95% of my use cases, but I need that last 5%" Or is it good?

> Any application which deals

The problem here is putting the cart before the horse and expecting the software to implement policies for you. If you can't design a workflow to work and be compliant without new software, you probably do not know enough about your own workflow to purchase software that will actually improve it.

Those workflows are typically mandated and can't be significantly changed without incurring compliance problems.

Not as typically as you might think.

No matter where I worked they have the pay/vacation/taxes/expenses pretty much locked down and always working. It's usually everything else.

While enterprises businesses may not use every single feature, they typically end up using 90-95%. The problem is that the same tool is l used across multiple departments. Take Epic. The EMR is used by doctors, nurses, billing, operations, finance, executives, pharmacists. And keep in mind that the way doctors use it will carry depending on the department. That's a lot of use cases to support

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".

I hate Photoshop. ;)

It's a jumbled mess of features added over the years with no coherent UI workflow between them. It hides way too much of the complexity of image editing in one-click-effect solutions, that often don't compose well.

I don't know of any good competitors in its price range though. I would recommend Nuke if it wasn't that expensive.

ImageMagick is great, I use it all the time. Photoshop is superb for interactive image editing, but if you need to crop a thousand images, change brightness, add some text on top, and merge them one next to the other, for example, and you need to do this every day, a sciptable tool is essential, and I really appreciate having all the power of Unix instead of a limited environment that requires a huge platform.

Wouldn't it be nice to have a programming-by-demonstration system that lets you interactively develop a filter on one image, then apply it to many images?

Photoshop actually has that. They are called Actions (basically macros).

You can select a group of operations you did in your editing history and turn them into an Action, with parametrization support.

You can then batch apply an Action to a bunch of files.

Nice! I don't know if this is new since I last used it or if I just didn't know about it.

I imagine photoshop has had it for a long time. I do raw photography very sparingly and barely know photoshop. Literally one of the first thing I wanted to do was batch operations on a set of photos in which the lighting and camera setting were exactly the same. A quick Google revealed it is frequently used.

Photoshop hasn't even existed for a long time yet.

Well, not in geological terms, but I would say that 30 years for a piece of software is a quite long time.

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).

> Not so much in Venezuela right now.

Yeah but that's not because of the software itself.

It's definitely a consequence of the software's implementation.

That was exactly my point.

ImageMagick and Photoshop serve completely different needs. You can't replace one with the other.

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.

> I'm not saying you're lying but maybe they misspoke or you misremembered.

No, that dev never did any serious image editing. He was just full of himself and of the "superior UNIX philosophy", the thought that there might be domains where that doesn't apply just never crossed his mind (image/audio/video editing being a major one)

Vim does not use the Unix philosophy. It is an Amiga program ported to Unix, designed along the lines of Emacs, which also does not use the Unix philosophy. You would think he would have noticed that his text editor was a domain where he wasn't applying the superior Unix philosophy.

I'm not convinced that the Unix philosophy doesn't apply to image and video editing, but certainly we haven't seen an example (aside from filters, which work well in things like netpbm and Khoros, but I mean for actual interactive drawing and editing.) And certainly the performance cost of the Unix approach was infeasible in 1988, when Thomas Knoll wrote Photoshop. Still, the tree-structured pipeline structure of CAD models in FreeCAD, SolidWorks, and CATIA suggests that it might be a productive approach with enough work.

We have seen the Vim philosophy applied to video editing, with great success; that's Blender.

I was talking more about the GUI/command line divide.

SolidWorks/Blender are fundamentally GUI apps, even if they do contain some programmatic features (like parametric filters/models/...). Also, all media software have something like "Unix tools who do one thing well" - plugins, filters, ..., but you compose them using the GUI.

It sounds like you're being confused by the surface appearance of things, rather than paying attention to their fundamental nature. Maybe that's why you weren't able to understand the arrogant Vim guy's utterance and wrote him off as delusional instead of figuring out in what sense he might be saying something true. It's good that you did figure it out eventually even if you couldn't hear it from him.

Unix wasn't distinguished from other contemporary systems by not using a GUI. With a few visionary exceptions like NLS/Augment, SKETCHPAD, Spacewar!, and GENESYS, computers didn't have GUIs when Unix was born. The Unix philosophy wasn't about using textual commands. Every computer used textual commands except desk calculators. It was about a uniform interface that permits unrestricted composition of orthogonal software components, easy and expressive automation of routine tasks, and prioritizing usability over absolute computational efficiency. These are not, to put it mildly, Photoshop’s strong points.

I understand your point about Vim not following Unix philosophy, also the way Vim and Blender are similar.

I disagree that the GUI/command line divide is a "surface appearance". I'm not talking about Vim/VS Code kind of thing, where one is implemented in the command line, the other in the GUI, but are basically the same. I'm talking about apps which fundamentally require a pointing device. In Photoshop you point at a pixel and say "do something here", in command line ImageMagick you say "x=100 y=200". This is not a trivial difference to me, it changes everything and generates different usage scenarios.

Vim is not a command-line program. It's a screen editor. The command-line equivalents are Perl, ex, and sed.

I agree that writing +100+200x17x25 is a terrible UI design for drawing. But you’ll notice that Vim doesn't use such an interaction design for text; and typing the 100 and 200 into the properties box of a Quartz Composer processing node doesn't make it any better. So it sounds like you're attacking a straw man, maybe unintentionally.

I'm not sure what I'm attacking, certainly not Vim.

I'm just saying that you can perfectly use Vim without a mouse, in fact most guides recommend you to disable mouse (and cursor) support.

But you can't use Photoshop or Blender without a mouse. Sure, you technically can, in a limited way, you can for example crop images or apply global filters in PS with just the keyboard, the same in Blender, but certain core manipulations are impossible in both without a mouse.

I would argue that it's because of the much higher resolution of images/3d data. 80x50 with a 100 character alphabet versus 2000x2000 with a 16.7 mil alphabet. In Vim you say "move the cursor after 'func'". How would that work in Photoshop? "move the cursor after RGB(25, 15, 9) RGB(98, 126, 22)?" You can't even see the pixels in PS, let alone guess their values.

There are pixel art editors which are completely usable with just the keyboard, but they are used for images smaller than 256x256.

The best way to use Photoshop without a mouse is to use a Wacom tablet. My Fitts parameter estimates for mouse interaction are terrible, but much better than any keystroke interface I've seen, much less command-line interfaces.

You were attacking interactive image editing by typing strings of text:

> in command line ImageMagick you say "x=100 y=200". This is not a trivial difference

But I don't think anyone really thinks that's a good idea.

I agree that direct manipulation is a great benefit, and I don't think there is any plausible alternative for designating positions and especially paths in pixel images the way incremental search provides a better alternative for designating positions in text. Vim in particular is distinguished from vi by supporting more direct-manipulation and noun-verb interaction flows, and vi differed from command-line editors similarly by supporting more immediate feedback and pseudo-direct-manipulation interaction: you would change a word by typing fscwbad ^[ rather than s/strange/bad/^M, for example. I think this is an improvement.

I'm continuously kind of appalled that we're carrying around these high-bandwidth multitouch devices all day and apparently the best way we've figured out to take advantage of this situation is one-finger scrolling of lists of pre-existing options, tap-selecting, and a simulated onscreen keyboard, plus the occasional pinch-zoom. I feel like even pictures under glass is about 10 years overdue for some new UI paradigms to take advantage of the new possibilities of the medium.

I wonder if there's a way to describe and interactively refine descriptions of areas of interest in a symbolic way—as Lisp trees if not Unix strings—maybe using existing neural networks. Certainly a speculative idea, of course.

> I wonder if there's a way to describe and interactively refine descriptions of areas of interest in a symbolic way—as Lisp trees if not Unix strings—maybe using existing neural networks. Certainly a speculative idea, of course.

I think the future is more like saying to the computer what you actually want. Like "delete the apple from the picture".

Photoshop already has a primitive form of this particular action, called Content Aware Fill, where you draw a rough selection around an object you want to delete, and it will fill a plausible background in its place. Works pretty well.


In a sense these are different uses of a computer for graphics: one is a medium of human visual expression, which is Photoshop’s forte, while “delete the apple” is more like delegating a functional task to an independent contractor. I don't think one is likely to entirely replace the other, just as Photoshop hasn't replaced netpbm, photography hasn't replaced painting (even if we do more painting in PS than with paint nowadays), and the city bus hasn't replaced dancing or skateboarding, even though all of them are ways to move your body.

There are certainly some uses of PS that things like caption-to-image GANs will replace. Analogously, last night I spent quite a while with the expressive, high-bandwidth, direct-manipulation interface of a box cutter cutting cardboard, for something I'd much rather be doing with a laser cutter cutting shapes generated from a constrained-optimization algorithm. At least this time I managed to only cut the cardboard.

Texture synthesis is a really interesting tool for both purposes. There are a lot of amazing papers in recent SIGGRAPHs with new algorithms for this kind of thing.

How is vim significantly less unix like than vi? The user interfaces are near identical and vi is very unix in philosophy and originated on unix.

EMACS was the extensible, customizable, self-documenting display editor, that did hairy things like turn your compiler error messages into hypertext and syntax-highlight your code—a massive amount of functionality tied up in a single garbage-collected process with an embedded scripting language, with potentially hundreds of files open at once. It came from ITS and Multics, where it provided not only an IDE but windows, on text terminals. It inhabited Unix systems uneasily, like the giant flying saucer in Independence Day, provoking complaints from co-workers that you were hogging megabytes of memory and making the VAX slow.

vi, by contrast, was just a display editor. If you wanted to refill a paragraph in your email, you typed !}fmt to pipe it to fmt, an external process. To reformat a block of C, you could use !%indent. (And you could map a key to this as a keyboard macro.) If you wanted to script some editing, you might emit an ex or ed script, probably from a shell script. If you wanted to concurrently edit a second file, you would start a separate vi process. You could run it on a PDP-11, where no process could exceed 64K. Unix philosophy: tiny tools, loosely coupled—though vi was a bit on the fat side in order to get WYSIWYG instantly responsive editing like Bravo, Smalltalk, or EMACS.

Vim is an extensible, customizable, self-documenting display editor, that does hairy things like turning your compiler error messages into hypertext and syntax-highlighting your code—a massive amount of functionality tied up in a single garbage-collected process with many embedded scripting languages, with potentially hundreds of files open at once, using megabytes of memory. If you want to refill a paragraph in Vim, you probably type gq}, which invokes Vim’s internal paragraph-filling code, not an external process. It uses the vi command set, with enhancements, but not the vi design.

Not that that's a bad thing. I greatly prefer Vim to vi. I've been using EMACS since 1990 or so and vi and Vim since 1996—I couldn't afford to wait 30 seconds for EMACS to load over NFS on my SPARC 5 every time I wanted to reply to a mail.

Same, but for Illustrator.

I hate the price and subscription model, and the learning curve has some steep spots, but once you're up and running, it's fantastic. I want to like Inkscape, but I've hit too many weird bugs (text getting squashed, transparency disappearing randomly). I'm curious about Affinity Designer though.

I was a long time Illustrator user. I think before the subscription model, say around CS3, Illustrator was fantastic. Then they started changing things in the UI that didn't need to be changed. I'm not against adding features but unnecessary changes really annoy me. I've been using Affinity Designer for the last year and I think it's great. It doesn't have all of the features Illustrator has but you can do real, professional work with it. Inkscape doesn't even come close.

Personally, I yearn for a command line image editor. ImageMagick is nice, but it can't do everything. Once you've gone cli, it's hard to go back to gui applications, since they're so inefficient.

You can only say this if you have a very limited imagination of what "image editor" is.

Please explain to me how you imagine creating a mask around a human so that you can "extract" him from the background in the command line.

I don't really know what "mask" and "extract" mean in this context. If you mean arbitrary selection of shapes then I have a couple of ideas how it can be accomplished. For mouse use I know the theory of arbitrary shape selection, but I never can get it quite right, since moving the mouse around the shape is very difficult for me.

> 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)

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.

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.

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.

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).

> 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.

Turbo tax is a consumer product and is optimized for that. Selling Turbotax to an enterprise will yield very different results

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.

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.

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.

> 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.

This! Also the concept of Intents is pure genius.

Mmmmm. I used to think that. It sounded good but ended up being a pain in practice, and very confusing. The intent was right (ha ha) but the implementation was lacking in some ways.

As others have pointed out, what you're describing isn't a fundamentally new idea or even that revolutionary. You're basically describing a database filesystem. Onne Gortner attempted an implementation of this concept in 2004 as part of his/her master's thesis (see http://dbfs.sourceforge.net/). Systems like Spotlight are effectively a partial implementation of this concept- OS X essentially has a hybrid setup where there's both a database and conventional filesystem running in parallel. Going back further, locate (first implemented in 1982) could almost be viewed as a proto-Spotlight. Gmail's labels/tags are another example of a mainstream implementation of this.

the larger point is more interesting here. enterprise software sucks because it generally has to fit within the well-accepted boxes in order to meaningfully interface with all the other stuff. that implementation might be a little better than the last one...

but what if the overall model/structure is really what sucks?

Effectively "Enterprise" systems have this already, but the "OS" is called Oracle. Or SAP.

This sounds vaguely like OS/400/system i

Big blue made OS/2 for you.

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.

> 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).

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.

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

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.

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.

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?

> 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)

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.

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.

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

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-p...

> 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.

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. :)

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.

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?

> 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.

I have my doubts that "complex unique organizational workflows" automatically means "dysfunctional organization."

And it would be ludicrous to interpret me that way! The part that implies the dysfunctional organization is “enterprises”.

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.

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

[Shameless Plug]

We're working on a process to help the buyer make the best decision - Vetd

Marketing Site: https://vetd.com

Platform Signup: https://app.vetd.com/signup/buyer

That sounds like a Conway's Law, but of large purchasers, rather than of software developers.


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

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.

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.

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.

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)

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

> 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

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.

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.

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.

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.

SAP sucks companies dry.

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

> 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.

> 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.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact