Hacker News Reader

Comment by wvenable | Hacker News Reader

I've had the opposite experience. Any attempt to adapt processes to an off-the-shell tool have always been a subpar experience for everyone. I've brought a few of these in house as fully custom software and the end result has been a better user experience and faster changes. If we can buy something that fits the need, we will. But if we can't, we build. And we build a fair bit.

I disagree with "the organization is likely less unique than you think". If you're big enough you will have unique requirements that nobody else has. I'm in the middle of that now in a project to install some industry standard software that runs the whole business and we have to customize and add custom integration into it. I wouldn't want to build software this complex in house but if I was given the resources and tasked to do it, I could, and it would be better.

View on HN

There are two different scenarios.

Scenario 1: You're doing something that every other business is doing. E.g. ERP/accounting, sales, contact center, etc.

Scenario 2: You're doing something few other businesses are doing. E.g. your actual customer business, creative, etc.

(1) is amenable to making your process fit software, to good results. (2) is usually a train wreck.

Unfortunately, figuring out if your thing is scenario 1 or 2 is non-trivial.

Canonical example: EMR/EHR systems in healthcare. You think they'd be the same... but actually there are so many integrations with other systems and/or different sorts of specialists, that a real world implementation has substantial functionality gaps (papered over with custom work).

My impression is that most people don't understand just how awful most commercial business software actually is.

One thing our business does that every other business does is vacation and overtime tracking. We have a custom in house application for that and we've yet to find a commercial replacement that is, in anyway, half decent. For most Payroll/HR systems, this is merely an add-on feature and doesn't get much attention.

For overtime, integration with our financial system allows overtime to be charged to the correct files and this is something that nobody does (or does well). Probably doing just this little bit makes this project pay for itself.

Beside the lack of attention, you also have gargantuan legal requirements you need to integrate. Which change all the time. Sometimes a few per country.

This is for everything: pay, vacation, etc.

It is really complicated.

One advantage of building in house is that you're only building for your own company. This is significantly less work than building commercial software for multiple clients (which I have also done). I can't overstate how much less work this is and how much of a better experience it can be for users.

As an example, for calculating annual vacation entitlement, we have some pretty complicated rules. But every company in every country has their own set of rules so most HR software doesn't bother calculating it -- you just figure it out manually and input it every year for every employee. But because we just have one "client" our rules are just code that we can change as needed and can arbitrarily use whatever information we have. This saves HR a ton of manual work all the time. But this only works because it only needs to be one set of hard-coded rules.

The problem when building it yourself is that this is usually done by "generic" developers who discover edge cases (often together with the requester) that threaten the whole model.

A company doing payroll for us ("us" being a multinational company) asked for a "typical payroll" to start with. Fortunately we had experienced people on the pay side who discarded the company because of this question (for one they should know, and for two they should know that "typical" will cover maybe 60% of the cases -- I thought that this was an exaggeration until I discovered the reality of calculating pay in France)

A good company specializing in "pay" or "vacation" (which are very regulated over here) will know the "typical" case and the edge cases.

> has their own set of rules so most HR software doesn't bother calculating it -- you just figure it out manually and input it every year for every employee

Beg to disagree. This is the complexity that large ERP firms handle and why Oracle, SalesForce, etc are expensive to implement. They figure out the commonality (if any) and build for it. Then they add on features specific to countries they target and then they add the ability to configure for your own situation (to a certain level).

PeopleSoft did this for Payroll and workforce administration which is part of how they cornered the market for HCM.

Commercial business software manufacturers are isolated from the users and in a way isolated from consequences as long as they fulfil the contractual obligations (which practically never has a 'make the users happy' stipulation).

I think this is why you only see innovation via alternatives vs within a product.

E.g. Salesforce, Workday rising up to replace incumbents, but then themselves becoming stale.

I think most moves to EMRs were insufficiently disruptive, e.g., electronic orders recapitulate the old paper orders without using the opportunity to reduce ambiguity and insert constraints to prevent common errors.

The problem is that the paper form is the interface, because the ecosystem was designed around it.

10 years ago or so, I asked a health insurance company why a specific digital form could only list up to 16 diagnostic codes (otherwise a duplicate with the additional needed to be created).

They thought about the question for a second, then said that's how many were on the paper form the digital system had been created from (35+ years ago).

> If you're big enough you will have unique requirements that nobody else has.

Definitely agree, and that is very interesting to hear. I only mean to speak to my experience, and what I saw in a lot of cases was unique requirements that were due to the organizational equivalent of tech debt (ie things like "our books are organized in this unique way because we acquired this other company a many years back but kept their stuff separate because it was the path of least resistance at the time").

That’s a legit issue. What’s the value of changing a deep seated process?

I have definitely seen examples on both sides of that question. Especially in a place like a public university with multiple collective bargaining agreements. The unions aren’t going to accept significant change without some sort of cost.

Typically, since processes are built around the system, nobody understands the actual business needs.

Nearly all our long-term tech debt come from having to work around limitations in the commercial software we use.

> If you're big enough you will have unique requirements that nobody else has.

the problem is when EVERY process is that way.

yes, each business has unique aspect to their processes, but when every process is heavily customized by people who have no business designing processes & applications, organizations start to hamstring their flexibility and scalability.

Its like hand-making a Ferrari with completely custom parts when what you need is a Toyota Camry. If you aren't gonna race with it, its a waste of money.

I have been working in the ERP space for over a decade. and almost ALL customers have no criteria for when to customize or keep a customization. They don't do any cost benefit analysis or any strategic planning beyond building a customized tool for the thing immediately in front of their nose.

Personally I hate software customizations. I prefer to build from scratch using proper software development tools than use whatever piss-poor customization system commercial software typically provides.

I recently sold my director on building some software from scratch rather than try to combine two commercial products together for some Frankenstiened solution. The motivation for Frankenstiening it is that we are paying for both services so we should use them (and at least one is very customizable). Only after 6 months of failing to get these systems to play together in an acceptable way, I finally asked a team member to spend 3 days building a mock up of a new app. From there it was quickly approved and we hope to roll out next month. I only wish I had done that sooner; we would have had way more time for development.

Reply on news.ycombinator.com