[HN Gopher] The hard part of Enterprise Software is the Enterpri...
___________________________________________________________________
The hard part of Enterprise Software is the Enterprise, not the
Software
Author : mokarma
Score : 101 points
Date : 2021-05-20 13:31 UTC (9 hours ago)
(HTM) web link (medium.com)
(TXT) w3m dump (medium.com)
| gcanyon wrote:
| As a friend once said, "You can't software your way out of a
| process problem."
| davidivadavid wrote:
| Pretty much. I'd attribute that common oversight to how natural
| it is to the average software developer to even _think in
| terms_ of process vs. the average client they serve.
| slver wrote:
| False dichotomy.
| GuB-42 wrote:
| I have always wondered why reporting was always so complicated
| and broken in every company I worked with. By reporting I mean "I
| spent two days on this project, five on that one and took a day
| off, I also had to drive 50 km to the the customer's site so
| that's an expense.". Then I realized a _lot_ was happening behind
| the scene, some of them being legal requirements with hefty fines
| if not done right. And all companies are different.
|
| And even though we have all these tools, I am impressed by how
| much tedious manual work is still done. For example, our poor
| assistant manager has to check that every expense is tied to the
| correct project, and the tools does nothing to help her (or us
| for that matter).
| burntoutfire wrote:
| Didn't read the article, but totally agree with the title. Having
| seen the level of complexity the business-side people (analysts,
| managers, product owners) have to deal with on a daily basis,
| I'll gladly work on our ridiculously overengineered k8s-based web
| app. It still seemed rather sane compared to the business side of
| bank.
| jarym wrote:
| But the business side is where the big $$ is at.
| raverbashing wrote:
| Yes but work-life balance and mental health are priceless.
| Guest42 wrote:
| I think for me that sometimes the large companies get over-
| siloed and that the small companies get over-scattered and
| under-funded. My best experiences have been at fairly large
| companies that are able to combine the better aspects of both
| and have enough flexibility within a defined set of processes,
| and the budget to support what's going on.
| lbriner wrote:
| I wonder whether there is a curve of profitability that peaks
| in the middle and then goes down in both directions. We all
| know that most startups struggle to make a profit because
| they might not command premium rates and are growing. On the
| other hand, I can't imagine the crazy overheads of large
| corporates who can only make so much money because their
| prices are high.
|
| I once heard (a long time ago) about a company who had paid
| $15K for a custom _carpet_ that was used for one trade show
| over a week and then thrown away.
| christkv wrote:
| Sometimes the demands feel like they are just bulletpoints added
| to make sure the specification document was long enough so it
| looks like they did some work.
| mamcx wrote:
| Is like the old proverb about software: Is far easier to build an
| OS than an ERP system.
|
| I do this for life, and kind of _like it_. I like working on data
| manipulation and enjoy using relational databases and the others
| too.
|
| Business app allow you to face EVERYTHING that make you giggle as
| a developer.
|
| Is Monday doing stuff, nice web app, At 1:00Ppm the sky is
| falling and suddenly you need to port it to iOS/Android.
|
| Also the app was invoicing and now is half-debt collector with
| Uber-like geo support.
|
| FUUUUUUNNNNNN!
| lbriner wrote:
| I'm not sure if anyone has ever written about the problem with
| the staff being less committed than the software.
|
| It is easy for me to make some big long-lasting decision about
| something that gets encoded in software and then I can leave next
| year and everyone else has to live with that decision.
|
| I don't know how to solve that unless you write software to be
| hyper-modular and able to be modified without a complete rewrite
| of everything. Either that or keep it simple, build it quickly
| and throw it away after 2 years when everything needs to change.
| jrodthree24 wrote:
| Some of this comes down to poor management as well. Sometimes
| it can be so stressful to convince them to do things the proper
| way, that it's a lot easier to just give them what they want in
| the short term and then ditching a year later before the bill
| comes due.
| dharmab wrote:
| > I don't know how to solve that unless you write software to
| be hyper-modular and able to be modified without a complete
| rewrite of everything.
|
| Isn't this how Salesforce ate the universe?
| 0xbadcafebee wrote:
| Fast cycles are a good solution for a lot of those problems,
| but they can also be highly wasteful. There's this tendency to
| think that "building things" is always a good idea in The Era
| Of Software, but to me that's like a disposable house or
| disposable car. It's better to build it to last.
|
| I think the solution is Shift Left, but with really good
| experienced leads at every level that have a mandate to reject
| any shit from being merged that will be a maintenance nightmare
| down the road. That's the only way to be remotely sure that the
| launch date you've committed to is reasonable, and that you
| aren't signing yourself up for years of pain trying to claw
| back all the terrible crap that got merged just to meet the
| deadline.
| neon_electro wrote:
| What is "Shift Left"?
| BitwiseFool wrote:
| I would say 75-85% of all client Jira tickets my team receives
| are actually errors in processing client business logic, not
| programming bugs. Sadly, all the little edge cases and special
| processing rules are the hardest to document and capture properly
| in the code itself because the rationale is paragraphs long and
| often only makes sense when the product manager explains it.
| lbriner wrote:
| So true. I commented earlier on another thread about
| enterprises being intent on very specific implementations and
| premature optimisation, which leads to very bespoke and
| therefore expensive software.
|
| We have a customer who "needs" to see their branches "scores"
| on the main dashboard regardless of the fact they could get
| that data somewhere else. We had to build a feature to win this
| customer that is only used by them and now have to maintain it
| forever.
|
| The small ongoing cost of maintenance never appears to be
| enough to say that we're not going to support it anymore and
| instead concentrating on the wider market and telling this
| customer to click another button!
| kspacewalk2 wrote:
| >I commented earlier on another thread about enterprises
| being intent on very specific implementations and premature
| optimisation, which leads to very bespoke and therefore
| expensive software.
|
| This is often because enterprises look at total cost, whereas
| you're focused on software cost.
|
| >We have a customer who "needs" to see their branches
| "scores" on the main dashboard regardless of the fact they
| could get that data somewhere else. We had to build a feature
| to win this customer that is only used by them and now have
| to maintain it forever.
|
| Depending on the size of this customer, the frequency of an
| employee needing this stat, and the amount of seconds/minutes
| saved per lookup, productivity/salary costs of not
| implementing this feature might easily dwarf paying someone
| to maintain it.
| orev wrote:
| > the amount of seconds/minutes saved per lookup,
| productivity/salary costs
|
| Let's not kid ourselves into thinking that decisions like
| this are made using an objective cost/benefit comparison
| with all data fully and accurately collected. The fact is
| that things like this happen because a decision-maker just
| demands it. It doesn't mean it makes logical sense, other
| than the salesperson needed to agree to it in order to
| close the deal.
| atatatat wrote:
| Right. That requires a slight increase in cost. One time
| very large, or ongoing.
| acwan93 wrote:
| The crazy thing is when customers demand something that
| inevitably breaks no matter how much we push back, like:
|
| -Years must be in two digits since apparently nothing is
| built before 2000
|
| -Not require postal codes or the city field for non-USA
| addresses since "we don't ship there anyway"
|
| -Require names be in the format of first initial, last name
| since "everyone has a first and last name and that's how we
| keep track of purchases"
|
| Things like this is what drives the cost of software up,
| since eventually we have to rollback changes.
| anoncake wrote:
| > -Require names be in the format of first initial, last
| name since "everyone has a first and last name and that's
| how we keep track of purchases"
|
| Also there is only one John Doe in the world, and he
| sometimes goes by Jeffries or Jane.
| MattGaiser wrote:
| So many of the problems in enterprise software are grafting
| tech onto a haphazardly developed manual process in this
| way.
|
| They didn't bother collect more than two digits when
| starting out, so just carry that error forward forever.
| briffle wrote:
| I wish I could remember where I read it, many, many years
| ago, but a blog was talking about automating systems in a
| government entity.
|
| They spent much work customizing a workflow, where all
| requests would go to Judy, and she would decide who to
| route it to. They spent weeks trying to map it all out,
| and the logic used, etc. They eventually found out the
| reason this was hard-coded into their proceses, was 15
| years earlier, in the days of paper based forms, Judy had
| the first laser printer in the building, and it was cheap
| to print compared to the other printers. It had nothing
| to do with her main job. So the printer next to her desk
| would hum, and then Judy would walk it to the person that
| needed it. Over the years, this just became accepted, and
| then later, incorporated into workflows/policies, and
| became Judy's full time job.
| dmingod666 wrote:
| My god, the staleness and overwhelming apathy of all
| people involved is just something else..
| [deleted]
| PascLeRasc wrote:
| Well the issue is that at this time we aren't in a
| position to accept new business logic change request
| proposals. You're welcome to bring your issue up at the
| bi-quarterly documentation stakeholders meeting, oh but
| I'm seeing here that you actually haven't been trained to
| attend that meeting. I've CC'd your manager to ask why
| they assigned this work to you, since as we know the
| human capital utilization policy is to only work on
| assigned projects.
| acwan93 wrote:
| I don't know if it's apathy or rather just an inability
| to fight the system. The DMV is what immediately comes to
| mind.
| pixl97 wrote:
| Heh, sounds like this list (not sure if this is the
| orginial)
|
| https://www.kalzumeus.com/2010/06/17/falsehoods-
| programmers-...
|
| People have exactly one canonical full name.
|
| People have exactly one full name which they go by.
|
| People have, at this point in time, exactly one canonical
| full name.
|
| People have, at this point in time, one full name which
| they go by.
|
| People have exactly N names, for any value of N.
|
| People's names fit within a certain defined amount of
| space.
|
| People's names do not change.
|
| People's names change, but only at a certain enumerated set
| of events.
|
| People's names are written in ASCII.
|
| People's names are written in any single character set.
|
| People's names are all mapped in Unicode code points.
|
| People's names are case sensitive.
|
| People's names are case insensitive.
|
| People's names sometimes have prefixes or suffixes, but you
| can safely ignore those.
|
| People's names do not contain numbers.
|
| People's names are not written in ALL CAPS.
|
| People's names are not written in all lower case letters.
|
| People's names have an order to them. Picking any ordering
| scheme will automatically result in consistent ordering
| among all systems, as long as both use the same ordering
| scheme for the same name.
|
| People's first names and last names are, by necessity,
| different.
|
| People have last names, family names, or anything else
| which is shared by folks recognized as their relatives.
| People's names are globally unique.
|
| People's names are almost globally unique.
|
| Alright alright but surely people's names are diverse
| enough such that no million people share the same name. My
| system will never have to deal with names from China.
|
| Or Japan.
|
| Or Korea.
|
| Or Ireland, the United Kingdom, the United States, Spain,
| Mexico, Brazil, Peru, Russia, Sweden, Botswana, South
| Africa, Trinidad, Haiti, France, or the Klingon Empire, all
| of which have "weird" naming schemes in common use.
|
| That Klingon Empire thing was a joke, right?
|
| Confound your cultural relativism! People in my society, at
| least, agree on one commonly accepted standard for names.
|
| There exists an algorithm which transforms names and can be
| reversed losslessly. (Yes, yes, you can do it if your
| algorithm returns the input. You get a gold star.)
|
| I can safely assume that this dictionary of bad words
| contains no people's names in it.
|
| People's names are assigned at birth.
|
| OK, maybe not at birth, but at least pretty close to birth.
|
| Alright, alright, within a year or so of birth.
|
| Five years?
|
| You're kidding me, right?
|
| Two different systems containing data about the same person
| will use the same name for that person.
|
| Two different data entry operators, given a person's name,
| will by necessity enter bitwise equivalent strings on any
| single system, if the system is well-designed.
|
| People whose names break my system are weird outliers .
| They should have had solid, acceptable names, like Tian
| Zhong Tai Lang .
|
| People have names.
| dmingod666 wrote:
| This was the list Elon Musk used to name his kid.
| andy_ppp wrote:
| Really understand why the business want something rather than
| what the business say they want _might_ lead to better
| solutions. Easy to say of course difficult in reality...
| davidivadavid wrote:
| You can get away with some push back and influence business
| process changes, but even with that, and even with solid
| change management, the OP seems roughly right IME.
| andy_ppp wrote:
| I am not convinced that the description of business
| processes into code is doomed to always be completely
| intractable. It is possible to understand the business well
| enough to solve its problems in a clear way it's just often
| extremely difficult.
|
| I have to say though, for an industry that claims to love
| science we have a dearth of tools that can help us learn
| how to do the more qualitative sides of coding better.
| mamcx wrote:
| Only 85%? And are "processing client business logic"?
|
| Amazing, mine are not logical and conflating a lot of stuff
| that can't be solved by programming:
|
| "Dude, pls add this amazing "security" concept I develop in my
| mind to catch salesmans defrauding the company! IS URGENT!
|
| Me: Like 1 or 2 days considering seriously the idea, like a
| idiot, then I ask:
|
| How you know the salesman is defrauding the company?
|
| I see how it buy $$$$ and fancy it in front of others!
|
| Me: ???? And why you still PAY THEM!"
|
| ----
|
| The major improvement I get doing this is _force the use_ of
| pivotal tracker ie: You MUST report tickets, not more doing
| stuff because somebody say so, and you MUST prioritize stuff,
| so 90% of my phone class are: "And then that means I must stop
| doing X? That 90% become "Oh, not, lets do that one first".
|
| I even delay some task on purpose, because you can't imagine
| how much times some "sky is falling" feature change or is nixed
| when the user cool down.
| avgDev wrote:
| I came in to rewrite software that runs a warehouse. The old
| software, was half working but used for 10+ years, the source
| code provided was different than what was in production(original
| dev lost it LOL).
|
| As I decompiled the production version and met with managers to
| learn/document the process. I quickly learned that nobody knew
| the process. There were pieces of information in people's head,
| and in several old apps. However, nobody clearly understood the
| process, where the data is exactly stored or how the data flows.
|
| The app took more than a year to write but could have been
| written in 2-3 months if previous projects had decent
| documentation.
|
| To develop an app for an enterprise you really need managers to
| be on board, otherwise, the new app will suck just a bit less
| than the one it is replacing. There are politics involved and
| petty arguments. Many people are just unhappy at their jobs and
| it leaks into their work.
| atonse wrote:
| Is this why Salesforce is so successful? It gives you a million
| enterprisey features (ad hoc reporting, role based access
| control, single sign on, user management, field level compliance)
| out of the box even if you're managing a glorified spreadsheet?
| hboon wrote:
| Many people might have forgotten or not know that when
| Salesforce started out, they were the lean software [1] that
| was so much better than the competition. I was using
| ChangePoint -- it sometimes took a few minutes to login (don't
| ask why, I don't know; But I suppose it's for the same reasons
| that Jira is horribly slow for some people). The UI was clunky
| and it was horribly slow.
|
| Salesforce was a breath of fresh air.
|
| PS: I think they were also one of the few cloud-based (rather
| than on-premise) enterprise offerings in the earlier days which
| helped got them some customers.
|
| [1] relatively any way.
| lbriner wrote:
| I think there is a bit of snobbery about those that "use
| Salesforce" vs the underclasses who don't.
|
| Of course, once you start using it and wire in all of the
| integations to everything else in your company, it would be so
| difficult to transfer to another product so it is as sticky as
| **. Starts getting a lot more expensive too!
| fredland wrote:
| the internet _is_ a glorified spreadsheet.
| zaphar wrote:
| Salesforce is successful because it tells a story around how
| easy it it is to just get started. Startup cost in a frequently
| underrated datapoint in tool selection.
| thrower123 wrote:
| Then there reaches a point where extracting the data and
| moving it to some other system becomes such an implacable
| task that it is cheaper to just keep paying the renewal POs.
| rsj_hn wrote:
| Is it really hard to extract data? That would appear to be
| an unnecessary friction and not in the interest of any
| serious vendor.
|
| I imagine the lockin is all the custom code you wrote for
| the platform. The data is portable, even the schema can be
| reproduced in a fairly straightforward way. But all your
| bespoke automation code is not portable.
| bob33212 wrote:
| Yes, Either you go the Salesforce route and make your software
| configurable to support any companies processes and people, or
| you go the Expensify route and make your software so simple to
| understand and so useful that the "process people" have no
| choice but to accept it, and everyone else likes it.
|
| Trying to do something in the middle that simplifies processes
| across groups will result in a veto from the process people.
| They are very well aware that their job is tied to making
| processes important and following those processes. They can't
| code, or even manage things well. But they can follow processes
| and advocate for how important all of their processes are
| within the org.
___________________________________________________________________
(page generated 2021-05-20 23:03 UTC)