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!
-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.
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.
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.
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.
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.
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.
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!
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 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.
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 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).
