Hacker News Reader

I've had similar experience working on a B2B product that we sell to financial institutions.

As the end users got a taste for our UX, they began to threaten resignation if they had to go back to the old system.

Word of mouth and human competition are a hell of a thing. Once a branch manager sees how efficiently someone across the street is running their business (which is effectively identical due to mountainous regulations), they will start doing our marketing for us.

I feel like tuning software for the human factor is something that almost every MBA still misses to this day. Making "this software feels good to use" an explicit objective is clearly impossible. You have to want the experience to be good at a fundamental level. Its an ambient part of every item that merges. You have to care about the product and customer very deeply to achieve this.

You have to care about the product and customer very deeply to achieve this.

So many miss this, and the big boys don't only miss the forest for the trees, they can't see the leaves either.

Total, narrow, limited scope.

Then big boys win by Hulk Smash. Startups win by leaves and forest.

I think this is ultimately what won over our users and why they championed our product so hard. A manager at a factory would use their budget to buy our software off their approved vendors list, get it going in a couple of weeks, and within months they were among the top performing factories. As word spread and other sites adopted our product the same trend happened.

And we cared deeply about the end users. One of the best things I did was get our development teams on-site with users. We had lunch with them, saw how they used our software, and took back tons of ideas for improvements and features that we released frequently and often. I got to know a number of our users on a first name basis and would use some of them to try out new features before we released them to the rest of our customers. It was awesome.

SAP is still the 800lb gorilla and probably always will be. It was neat to work in an environment where we cared this deeply about our users that they fought to be able to use our software.

Software developers miss it too. Most libraries are pushed for how efficient they are, how few allocations they have, which algorithms they use, etc. regardless of in what circumstances they're being used, and easy to use libraries are assumed to be making a significant tradeoff.

Ease of use isn't something that can be measured though, and most people don't have the framework for arguing UX decisions so debates come down to "well I think this is easier to use than that". Maybe not SAP, but no matter how terrible a system is there's someone who's used to it and will argue that it's easier to use than the alternative, and that proponents of the alternative just need to get used to it.

I kind of feel like this is something a leader with a feel for it needs to dictate. Torvalds made a similar comment about good sense with Julian Hamano, which I don't feel effectively supports this, but I do agree with at some level.

My first software job was doing custom lotus notes database applications. One of the ones I was working on was going to be overlapped by future SAP implementation..

my boss said do it, because it was so much cheaper and no one could say when or if the SAP would be installed. They had to map the business to SAP, instead of having the software be flexible.

But it turns out when you build something that fulfills a business need and makes employees life’s easier they like it.. a lot. Even if it’s just a Lotus Notes database application. I even won a very minor award for that one.

> They had to map the business to SAP, instead of having the software be flexible.

this is both an advantage of SAP (and realistically, the ERP industry), and a curse.

As a fellow dev who got their start doing Lotus Notes work, I feel this comment on a deep level.

> The IT folks at said multinationals hated our software

why?

I'm sure they had lots of reasons.

I got to ghost on a sales call once with one of our customers (I was a lead developer at the time).

From what I could tell their IT people didn't like our software because:

- They were already in the middle of a multi-year roll-out of SAP, integrating our software was a wrinkle in a plan they'd been working on for a long time

- Nobody got fired for choosing SAP, some saw choosing software from a small shop they'd never heard of was risky

- Annoyance: they were in charge of acquiring and rolling out the software the factories used! Why were the floor managers demanding that they integrate our software? What do they know about software, enterprise contract negotiation, etc!? How dare they!

- Support: they knew how to handle issues with SAP, user accounts, authentication, authorization, etc; integrating another piece in the mix across the entire company would be a whole project

It was a fun call to sit in on.

> Annoyance: they were in charge of acquiring and rolling out the software the factories used! Why were the floor managers demanding that they integrate our software? What do they know about software, enterprise contract negotiation, etc!? How dare they!

Ok, so this one I actually kind of agree with. Too many times I was in a position where a bunch of decisions were made about software or hardware, and then IT was brought in at the last minute to try and get it all to work in an unreasonable time frame. And then IT was asked it integrate it in impossible ways.

If another department brings IT in early, different story. I got in to IT to use technology to make people's lives easier, not to play with whatever the latest fad bullshit is or develop an inflated sense of self-worth. If some random nobody's software is going to do that at the cost of a minor annoyance to me, that's fine.

Having worked both sides of this, it's generally the case that IT is absolutely terrible at their job that ends up with them getting called in late.

That's fair, 90% of people are shit at their jobs. I'm just saying, if it is me, I'm definitely upset you did that and I think I'm justified in that.

Company: "IT is terrible at their jobs, what are we going to do about this!"

IT director: "Give me a budget to hire competent IT people"

Company: "On the other hand, we're ok with this IT incompetence"

Interesting, in my experience generally it's business types that don't know shit from their elbow and don't include IT early enough due to negligence.

I would guess that completely incompetent IT departments that only degrades everybody's work are very highly correlated to workplaces that use those huge, all in 1, hired consultants based software packages.

Sounds like a good reason to bring them in even earlier

My experience is admittedly limited but every case I've seen of IT being called in late was that IT would have reasons for no. The VP didn't even learn their lesson when circumventing IT ended up with all corporate e-mail down for nearly a week. (As predicted, although it ended up taking longer to fix because I was on the other side of the world, internet access but unreachable by phone.)

A low-trust environment is exhausting for everyone, and a difficult pit to climb out of.

Another reason that people often overlook is security. Even if each individual software product has a good security model, differences in the way they interact can lead to security vulnerabilities and opportunities for attackers to move laterally through a network. In the case above, it may be that IT knows how to integrate SAP with their Active Directory system in a manner that ensures that users have access to the data that they need, without giving everyone write access to everything. A brand new product from some small startup, even if it's competently engineered, won't have the same pre-set integration playbooks as SAP. The in-house IT will have to figure it out themselves, which adds time and overhead for every operation. New hire? Before, you'd give them a SAP account, and you'd have a playbook that would automatically or semi-automatically provision everything for them. Now, you have to provision accounts in two systems. Compliance? IT already knows how to validate an SAP install for compliance and generate a report for the appropriate regulators. Now they're going to have to learn to do that with your new system. And so on.

I listen to several infosec podcasts, and one recurring theme in those podcasts is managing users who do "shadow IT", i.e. by buying and integrating new products or software that make their day-to-day jobs easier, but do so in a manner that opens up huge gaping security holes that IT doesn't even know about… until the breach happens and the company is all over the news for leaking customer data.

Security is important. What makes SAP secure? I personally found errors in customer systems. And at the time even Microsoft couldn’t implement OAuth2 correctly with regards to the specifications… which is no surprise given how often it had to be amended.

A good deal of “security,” even in the enterprise, is a lot of theatre and show boating. Write a formal specification and throw it at a model checker and you’ll probably start finding holes in most software stacks. But hardly any software developers do that let alone IT managers.

The later generation of the stuff I was working on at that company had to also be certified under certain important regulations. The system had to be able to be auditable in the sense that application logs couldn’t be repudiated in court and users couldn’t tamper with data. That was some pretty serious work.

But yeah.. there’s a lot of “lol security” out there and as an IT person trying to manage ISV solutions it can be a huge pain trying to sort the wheat from the chaff.

But just buying MS or SAP and thinking you’re done with security is also as bad. Don’t overlook security.

    What makes SAP secure?

Nothing, inherently. What makes SAP secure is that a lot of IT organizations have experience with setting it up, and know enough about its pitfalls to avoid them. With a new product, IT is going to have figure out the security pitfalls (hopefully by reading documentation, but more likely through testing, hopefully not through breaches). If, as the grandparent post indicates, the product was set up by someone outside of IT, it's quite likely that that person doesn't actually know about security, and may well have inadvertently opened a security hole by, for example, creating an insecure proxy account.

To re-emphasize my point from my original post: far more security problems result from the interaction of systems than result from systems themselves. SAP may be set up in a perfectly secure manner. The new product may be set up in a secure manner. However, their interaction may still result in data leakage or denial of service.

Even if your product is perfectly secure (which it isn't), the mere fact that it's one more component, interacting with all the other components of the company's IT infrastructure, is reason enough for broader corporate IT to be cautious.

Furthermore, it's often the case that when there is a problem, security or otherwise, it's not going to be your customer that's on the hook. It's going to be the company's IT department. Would you like to suddenly support a piece of software that, a week prior, you didn't even know existed, much less deployed at your company?

To your point: I remember going to our IT security people asking for them to allow us to add Python to our computers. We said, "there's nothing in Python that Excel can't do" (not 100% true). Their response was, "If we could prohibit everyone from using Excel, that would be our preference too."

Given how many times they must've been burned by end users opening infected Microsoft Office documents, can you really blame them?

This was a lesson I learned very recently.

As a dev, I think about security in terms of exploits and making sure software doesn't have them (as well as having features required to implement user/data policies).

An IT person thinks about policies too but for them security is primarily about tools. If a piece of software will work behind their firewall and IDS, integrate with their monitoring software and Active Directory, export reports in the format this or that other tool needs, then it's secure from their perspective.

It makes sense when you think about it, and actually allows for a fair bit of freedom once you understand the boundaries. What is unfortunate is all the time I wasted gathering pen-test reports and all kinds of other junk when that wasn't the real problem at all.

Exactly. A lot of developers focus on lack-of-vulnerabilities as the essential aspect of security, when, in reality, for corporate IT, the essential aspect is visibility. It doesn't matter how secure a black-box app purports to be, the mere fact that it's a black box that IT has no visibility into it will (justifiably, IMO) lead IT to treat it as insecure.

And that's all fine, but when the IT Department turns itself into a black box and doesn't tell anyone what bar software needs to clear to be used that's when shadow IT happens.

At one point I wore a hat in a IT leadership role for factories. We hated third party software because it created silo's where our data became un-usable. There is no point in an MRP/ERP factory system if all the bits aren't talking/working together. People fight and fight you as you try to get there, but once you get there and it all starts to work together and you no longer have jobs travelers looking like daisies with escalations all over they get it and their life gets significantly better.

Was that last sentence autocorrected maybe? I'm struggling to parse the last bit about travellers and daisies.

Not the OP, but just trying to be helpful.

"Travelers" are paper packets that move through a manufacturing process with whatever material is being improved. Lots of machine shops have these printed out packets of specs, communications and notes that accompany a given order as it makes it's way through the process.

I'm pretty sure the "daisies" comment was related to how many shops escalate a given order by adding bright stickers or other obvious, visual indicators to the traveler, and shops can sometime become so overwhelmed that everything is escalated and all the bright travelers start looking like a field of flowers.

Ah cool, that makes a lot of sense. Interesting peek into the process.

This seems…tangent with…my experience at another small company doing integrations with enterprise software like Sage. The various enterprise systems of course had their own reporting solutions, but customers preferred how ours let them build their own or request designs that they could modify using skills they already had: Excel and Windows.

Was it the German company SAP?

How did the end-users even find your software especially when the IT folks hated it?

Our sales people had connections in the industry that led us into various "approved vendor" lists. This eventually allowed us to worm our way into getting demos with floor managers who could use some of their budget to buy our software. Word of mouth spread from there and within a couple of years we were driving their IT department up the wall. It was grass-roots and the end-users, the people on the floor doing the work, loved it so much that it spread.

And probably broke their MRP/ERP systems. But the IT departments probably came up with workaround to get data out of the system and feed the ERP/MRP system just enough to keep things going but probably way less efficiently than they would have ultimately been if pain points would have been addressed in the existing system instead of the virus of your software injected inappropriately. And then you probably badmouthed the MRP/ERP system for it's failings (that were partly related to the damage done from using your system). Weak sauce man. In a different life I wrote best of breed department level software too but at least I very much understood why enterprise systems were preferred outside the department so that I COULD ADDRESS THAT CORE ISSUE THAT NEEDED TO BE ADDRESSED AS PART OF MY SOFTWARE. But yea, IT department bad, me good.

Haha, yeah I get that. That's why I sat in on calls with their IT folks. We made it as easy as we could to get data back out of our system. We exported in a bunch of different formats and could integrate with several ERP/MRP/BI systems directly.

No need for such a ridiculously aggressive response.

IT folks hated it? Or maybe just the bigwigs? You don’t say why but guessing because you innovated away their headcount.

I assume that they were having to do end-user support. I was working in IT at that time and recognise that reaction from IT.

Oh you just need to support this XYZ new database, our app doesn't have a way deploy with your deploy tools, doesn't have granular permissions levels (in a factory environment), etc. Why do you not want our tool? Also, we will silo away a bunch of data needed for an MRP/ERP system to be effective to our system outside the MRP/ERP system. Silly IT people, not understanding our work environment (even though you support every person on the factory floor and have to understand their job and workflow to do that, to the point your techs are better manufacturing engineers than our actual MEs).

You sound like you're exhausted from dealing with people who are constantly doing end runs around your software. I can understand that.

On the other hand, if everyone in your org outside of IT execs despise SAP -- and make no mistake, they do, every last one of them -- then maybe it would be productive to wonder why that is rather than blaming your idiot users.

Off topic: I’ve been a DH customer since 2004 and love it because to me it’s the perfect PaaS. DH is way under appreciated by HN crowd.

If you have any influence though, can you ask for the dedicated & vps offerings to get more love. Hardware is terribly out of date now (lack of nvme & modern proc).

I realize DH needs to hit a price point & margin, so I’m not asking for latest gen hardware. Just hardware that isn’t a decade old :)