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.
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.
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.
They do lots of other things a lot better, but email? Nope.
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.
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.
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.
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.
Other than that, what specifically did it enable that the other phones didn't?
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.
But, that's just me speculating...
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
With ActiveSync, my email will usually reach my phone/cellular watch/iPad before it reaches my computer.
https://www.schneier.com/blog/archives/2008/05/blackberry_gi...
https://www.engadget.com/2016/04/18/blackberry-ceo-wont-say-...
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.
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.
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.
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.
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.
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.
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.
I would lay money that far more security vulnerabilities are due to overcomplicated customizability features than are due to simplified UX.
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.
Sure people could use notepad, onenote, powerpoint, other proprietary software, but they are comfortable in the grid like ridgularity of excel.
That was an uncomfortable day. ;)
Once you cross a time zone, your records are much harder to access.
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.
I kinda like the idea of regular scheduled downtimes of stable systems, just for real experience on downtime procedures.
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.
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.
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.
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.
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.
- 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.
Almost seems like "micro-tasks" at this point.
Micro tasks are good.
I'm assuming your employer has never heard of printers or copy-paste. ;)
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".
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.
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.
(And many companies are using MDM along with the iPhone, so it's not like they don't think they need control there.)
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.
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)
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.
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.
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.
... which adds features to the product as a whole, which other customers will need to be aware of and might take advantage of.
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.
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.
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.
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
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.
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.
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.
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).
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.
'Custom' is scary in a way that 'customizable' isn't.
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.
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.
And scaling beyond 2-3 real customers does make a very big difference for any legitimately good company.
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.
This was arguably Steve Jobs key role at Apple.
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.
https://sixsigmadsi.com/grandmas-ham-a-story-of-cultural-tra...
perhaps the ends were being cut off because they often rotted near-invisibly faster, and now you've gone and poisoned the whole family :-)
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.
Whether or not you choose to respect those needs, they very much still exist for all larger publicly traded companies.
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.
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.
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.)
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.
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.
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 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.
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.
The shift was in computers, from enterprise to consumer, and the software followed.
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
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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...
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.
- 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.
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.
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.
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.
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.
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.
Put another way, that Bob thinks he's dealing with "big data" doesn't mean he is in fact.
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.
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.
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.
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.
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
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?
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.
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.
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?
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.
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".
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.
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.
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).
Yeah but that's not because of the software itself.
ImageMagick and Photoshop serve completely different needs. You can't replace one with the other.
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.
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)
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.
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.
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 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.
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 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.
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 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.
https://helpx.adobe.com/content/dam/help/en/photoshop/using/...
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.
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.
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.
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.
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)
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.
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.
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.
For instance Slack is great IMO, but they only introduced bring-your-own-key earlier this year (a requirement for security-serious companies).
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.
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.
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.
This sounds a lot like Android's "activities" concept which doesn't get enough love, in my opinion.
but what if the overall model/structure is really what sucks?
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).
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.
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.
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?
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)
OP conflating them with enterprise software is not the best premise.
I strongly doubt that support for complex and unique workflows is why Blackboard is so bad at entirely conventional workflows.
Melissa Perri calls it the Build Trap: https://www.mindtheproduct.com/escaping-build-trap-melissa-p...
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.
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. :)
- 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 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?
Bingo—the dysfunction of the software reflects the dysfunction of the organization.
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
(with the separation of concerns not really mattering in the usage of the tools)
If enterprises were selecting for this then you would expect emacs to be the most used enterprise software of all time. :-P
Companies only use 5% of the features the more sophisticated enterprise software is offering but it's a different 5% each of them use.
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.
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.
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.