5 ms·

So true. I commented earlier on another thread about enterprises being intent on very specific implementations and premature optimisation, which leads to very b

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 5y ago
>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.
- atatatat 5y ago
  Right. That requires a slight increase in cost. One time very large, or ongoing.
- orev 5y ago
  > 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.
  - knightofmars 5y ago
    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.
acwan93 5y ago
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.
- MattGaiser 5y ago
  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 5y ago
    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 5y ago
      My god, the staleness and overwhelming apathy of all people involved is just something else..
      - 5y ago
jfengel 5y ago
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.

kspacewalk2 5y ago

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

atatatat 5y ago
Right. That requires a slight increase in cost. One time very large, or ongoing.
orev 5y ago
> 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.
- knightofmars 5y ago
  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.

acwan93 5y ago

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.

MattGaiser 5y ago
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 5y ago
  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 5y ago
    My god, the staleness and overwhelming apathy of all people involved is just something else..
    - 5y ago

jfengel 5y ago

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.