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.
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.
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.
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?
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.
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.
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.
It shouldn't be, but there's always been very healthy industry niches around pulling data from one system and putting it into another one. Nothing ever lines up exactly, and there's always some idiosyncratic remapping or futzing that has to be done manually or with some one-off custom code, so it remains an expensive contract business.
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.
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!
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.
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.
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!
>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.
> 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.
Yes, 100%. A salesperson on commission does not care about the long-term maintenance costs of a decision of this nature. And I don't blame them, it's not something they should care about. A product owner? They may care if they're actually invested (stock options, co-ownership, etc) but they also may just leave after a few years after a better offer comes along or a buyout happens. A software engineer? It's the same as the product owner, they may care for some period but why not just leave when a better offer comes along.
I've pondered this issue as the "Peter Gibbons" problem. Why would anyone in the chain of software development care about the software itself? There's no incentive to consider the long-term cost impact of implementing a custom feature because you can always just find a new job if the product gets unwieldy.
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.
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.
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 田中太郎.
The aggravating thing is that often, having demanded the feature, they discover that they didn't really want it in the first place.
I try not to argue with a customer, because they do know their business better than I do. But I know the software better than they do, including its intended use model. The former usually takes precedence over the latter, if for no other reason than that they have the money and I don't. But if they're not paying for it directly, and want me to do it on spec... hard decisions get made.
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...
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.
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.
> we have a dearth of tools that can help us learn how to do the more qualitative sides of coding better
Does dearth mean something different than “lack” here?
I come from a manufacturing and mechanical design background. We learned a design process including tools to deal with the qualitative aspect of requirements elicitation in each project.
A book I found helpful while transitioning to a business analyst position involved with software projects is [1].
There is also the social sciences and maybe the humanities that use qualitative research methods. An example is enthographic research.
I think there is plenty out there to use as a starting point.
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.
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).
1. HR/Finance/etc buys and runs a package from 3rd party to meet their desires. This is fine.
2. Their desires include all employees enter in details and navigate forms for themselves, but they have to be approved by their manager. Top level management decision that this is fine.
3. The group specifying requirements is now divorced from the users.
leading to :
4. very little thought given to user experience for vast majority of users.
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.
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.
You should google it, there is a lot of writing on the subject. Suffice to say it is about doing something now once rather than doing it later at twice the cost and time.
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.
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.
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.
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.
I think it’s because enterprise architecture is taught and practiced as “architecture of software in a complex environment” rather than “architecture of a complex organization containing people and software “. A complex system with no architecture governance and rampant complexity cannot function sensibly and mr. Conway tells us there is a homomorphism between software and organization. I have been earnestly trying to fix this with an EA course I teach but the going is slow.
It's three good years now that I am consulting at a firm as a link between the company and ERP provider. At the time the presented problem was 'the ERP doesn't work'.
Today the majority of the issues are resolved and it's pretty clear that the problem was the process, not the ERP (which, btw is far from perfect).
My job is something between understanding and fixing the process plus reducing the software customisation requests.
On top of that, just add your typical ERP with totally counter intuitive UIs and a bunch of users with an overall general aversion to changes.
I love my job btw.
(I've not read the article, but I like the topic and felt like to drop this comment).
56 comments
[ 3.2 ms ] story [ 110 ms ] threadI 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.
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.
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.
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!
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.
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!
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.
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.
I've pondered this issue as the "Peter Gibbons" problem. Why would anyone in the chain of software development care about the software itself? There's no incentive to consider the long-term cost impact of implementing a custom feature because you can always just find a new job if the product gets unwieldy.
-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.
They didn't bother collect more than two digits when starting out, so just carry that error forward forever.
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.
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 田中太郎.
People have names.
Also there is only one John Doe in the world, and he sometimes goes by Jeffries or Jane.
I try not to argue with a customer, because they do know their business better than I do. But I know the software better than they do, including its intended use model. The former usually takes precedence over the latter, if for no other reason than that they have the money and I don't. But if they're not paying for it directly, and want me to do it on spec... hard decisions get made.
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.
Does dearth mean something different than “lack” here?
I come from a manufacturing and mechanical design background. We learned a design process including tools to deal with the qualitative aspect of requirements elicitation in each project.
A book I found helpful while transitioning to a business analyst position involved with software projects is [1].
There is also the social sciences and maybe the humanities that use qualitative research methods. An example is enthographic research.
I think there is plenty out there to use as a starting point.
[1]https://www.microsoftpressstore.com/store/software-requireme...
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.
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).
1. HR/Finance/etc buys and runs a package from 3rd party to meet their desires. This is fine.
2. Their desires include all employees enter in details and navigate forms for themselves, but they have to be approved by their manager. Top level management decision that this is fine.
3. The group specifying requirements is now divorced from the users.
leading to :
4. very little thought given to user experience for vast majority of users.
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.
Isn't this how Salesforce ate the universe?
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.
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!
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.
I love my job btw.
(I've not read the article, but I like the topic and felt like to drop this comment).