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.
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.
Also there is only one John Doe in the world, and he sometimes goes by Jeffries or Jane.
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.
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.
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.
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...