The hard part of Enterprise Software is the Enterprise, not the Software
medium.com
medium.com
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.
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 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.
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 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 love my job btw.
(I've not read the article, but I like the topic and felt like to drop this comment).