6 ms·

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 lit

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.

lbriner 5y ago
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.
andy_ppp 5y ago
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...
- davidivadavid 5y ago
  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.
  - andy_ppp 5y ago
    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.
    - wheelinsupial 5y ago
      > 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-requirements-9780735679665 https://www.microsoftpressstore.com/store/software-requireme...
mamcx 5y ago
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.

lbriner 5y ago

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.

andy_ppp 5y ago

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

davidivadavid 5y ago
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.
- andy_ppp 5y ago
  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.
  - wheelinsupial 5y ago
    > 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-requirements-9780735679665 https://www.microsoftpressstore.com/store/software-requireme...

mamcx 5y ago

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.