5 ms·

This sounds so nice in theory. All those pesky developers refusing to fix their horrible code. While in reality at least in my experience the developer would b

by wink 8y ago

This sounds so nice in theory. All those pesky developers refusing to fix their horrible code. While in reality at least in my experience the developer would be very much happy to fix the code, it's just that you don't get any time to do that. It's only new features and new products.

WrtCdEvrydy 8y ago
Bug fixes don't sell your software unless it's a heavy customer product.
- stevoski 8y ago
  In a SaaS business, bug fixes can help reduce churn. A simplistic description is, "sales and marketing increase MRR, a quality product decreases churn". Often a company becomes financially viable by fixing churn.
- mamcx 8y ago
  Not..exactly. Maybe is only a local thing in my country, but you will surprise what is called "features" and "bugs" from non-developers. (features: Everything including bugs bugs: Everything that is annoy and not allow to continue... but sometimes also called features) I mean, are intermixed ALL the time. I literally this week was working in a feature (that was, in reality, a bug) meanwhile only talking to my partner that give support and see him ignoring a red modal windows with a error message (oh, that is not a bug, it allow to work(???)). You can turn the bugs and anti-features of the competence in your own selling points (our product sync the offline database without the need to have a operator that restart the service and click on "sync" in the dashboard!!!) and stuff like that...
Cthulhu_ 8y ago
That's exactly a reason why a company should consider having their engineers do support - by the sound of it, there's a support department who - MAYBE - accumulate common questions and send them to a product owner, but in practice they won't and in practice the PO ignores it because there's more important things - in his/her mind - that have precedence.
- dboreham 8y ago
  Pro tip: have your managers do customer support .
  - icedchai 8y ago
    That would be nice, except most are simply incapable. They forward the requests to the dev team, causing interruptions, distractions, and aggravating engineers.
    - bobwaycott 8y ago
      Sounds like those managers need to be replaced. A manager ought to foremost protect the dev team from interruption, distraction, and aggravating or time-wasting requests.
      - icedchai 8y ago
        I agree. That's why I moved on from that place.
btschaegg 8y ago
> This sounds so nice in theory. All those pesky developers refusing to fix their horrible code. This might be the niche I'm working in, but that does not sound all that unreasonable to me; I certainly know the type. At first, there is a debate whether there really is a bug (instead of giving a trained user and the according support staff the benefit of the doubt), then there is a debate whether the bug should really be fixed or the thing is delayed at nauseam ("need more information" without even having skimmed the damn code at least once). And when the business side finally puts their foot down, the defect is "fixed" with some minimalistic, ad-hoc duct-tape solution that guarantees that five other bugs will pop up in the future because of it. So while I agree with your second point, that doesn't invalidate the first. These kinds of devs actually do exist (with various degrees of intensity, of course). I'm not sure if the archetype is really fit support work, though.
tristor 8y ago
It's actually more complex than that, even. I'm speaking from being an engineer for some time (~13 years) and a product manager now. The issue is that Customer A, B, C, D, and E want Feature A to behave in one way, and Customer N, M, O, P, Q, R, S, T, U, V want Feature A to behave in another way, and those two ways are mutually exclusive insofar as it can't merely be configurable, since Features B-F rely on Feature A behaving in one way or another. So which set of customers do you please? How do you ensure that customer requests for behavior changes, or customers being surprised by application behavior doesn't result in a scope creep that expands the requirements of your application to an unsustainable level? How do you ensure that your business doesn't get coopted by BoM (Buckets of Money) to basically be a contract development house and eventual acquisition target by your largest enterprise customer while ignoring/harming all your other customers who were earlier adopters? There's a lot of jokes about bugs actually being features, but at some point if an application behaves in a certain way long enough and that behavior is relied on elsewhere, changing it is a new feature with all the consequences that come along with that, even if the new behavior is strictly more correct. All of these factors need to be balanced in determining what the best path is to tread in your software. At a certain scale, most of these questions can be addressed organically, maybe by the developers themselves, but at a certain scale it's just not feasible to interface customers directly with developers. You are working on "new features and new products", because customer issues get turned into identification of new markets to solve those issues, which are serviced by new features and new products rather than by "fixing" the old products and features, which would break it for other customers.
- stevoski 8y ago
  That's a great description of the subtleties of product development, especially within a small team. Many books and articles make it seem like a simple procedure, but actually you often face decisions which will leave some people unhappy, no matter what you decide.
  - Novashi 8y ago
    You basically have to get into supporting extensions or custom code and supporting an API if you run into enough of these customers and that’s when you declare that you only have so much responsibility for the customer’s code (and it quickly turns into another support revenue stream).
lbotos 8y ago
> While in reality at least in my experience the developer would be very much happy to fix the code, it's just that you don't get any time to do that. It's only new features and new products. I agree. At GitLab, I'm trying to build our "Support Engineering" group into people that have the time and mandate to fix the things that spring up leaving product devs to focus on new features. It's been working pretty well: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16511 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16511 (40% view speedup) https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name[]=support-fix https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope...
user68858788 8y ago
I've worked as a developer oncall, and as dedicated support engineer oncall. You're absolutely right - management will absolutely refuse to allot time to improvements and bug fixes when there are features to make. It's frustrating being a Dev and knowing how to fix an issue, but not given the time to fix it. It's equally frustrating to cut tickets and mail reports on issues to see them sit forever in the backlog.
rconti 8y ago
I bet the developer's a lot happier to fix the code when the impact is more severe than yet another ticket.

by wink 8y ago

WrtCdEvrydy 8y ago

Bug fixes don't sell your software unless it's a heavy customer product.

stevoski 8y ago
In a SaaS business, bug fixes can help reduce churn. A simplistic description is, "sales and marketing increase MRR, a quality product decreases churn". Often a company becomes financially viable by fixing churn.
mamcx 8y ago
Not..exactly. Maybe is only a local thing in my country, but you will surprise what is called "features" and "bugs" from non-developers. (features: Everything including bugs bugs: Everything that is annoy and not allow to continue... but sometimes also called features) I mean, are intermixed ALL the time. I literally this week was working in a feature (that was, in reality, a bug) meanwhile only talking to my partner that give support and see him ignoring a red modal windows with a error message (oh, that is not a bug, it allow to work(???)). You can turn the bugs and anti-features of the competence in your own selling points (our product sync the offline database without the need to have a operator that restart the service and click on "sync" in the dashboard!!!) and stuff like that...

Cthulhu_ 8y ago

That's exactly a reason why a company should consider having their engineers do support - by the sound of it, there's a support department who - MAYBE - accumulate common questions and send them to a product owner, but in practice they won't and in practice the PO ignores it because there's more important things - in his/her mind - that have precedence.

dboreham 8y ago
Pro tip: have your managers do customer support .
- icedchai 8y ago
  That would be nice, except most are simply incapable. They forward the requests to the dev team, causing interruptions, distractions, and aggravating engineers.
  - bobwaycott 8y ago
    Sounds like those managers need to be replaced. A manager ought to foremost protect the dev team from interruption, distraction, and aggravating or time-wasting requests.
    - icedchai 8y ago
      I agree. That's why I moved on from that place.

btschaegg 8y ago

> This sounds so nice in theory. All those pesky developers refusing to fix their horrible code. This might be the niche I'm working in, but that does not sound all that unreasonable to me; I certainly know the type. At first, there is a debate whether there really is a bug (instead of giving a trained user and the according support staff the benefit of the doubt), then there is a debate whether the bug should really be fixed or the thing is delayed at nauseam ("need more information" without even having skimmed the damn code at least once). And when the business side finally puts their foot down, the defect is "fixed" with some minimalistic, ad-hoc duct-tape solution that guarantees that five other bugs will pop up in the future because of it. So while I agree with your second point, that doesn't invalidate the first. These kinds of devs actually do exist (with various degrees of intensity, of course). I'm not sure if the archetype is really fit support work, though.

tristor 8y ago

It's actually more complex than that, even. I'm speaking from being an engineer for some time (~13 years) and a product manager now. The issue is that Customer A, B, C, D, and E want Feature A to behave in one way, and Customer N, M, O, P, Q, R, S, T, U, V want Feature A to behave in another way, and those two ways are mutually exclusive insofar as it can't merely be configurable, since Features B-F rely on Feature A behaving in one way or another. So which set of customers do you please? How do you ensure that customer requests for behavior changes, or customers being surprised by application behavior doesn't result in a scope creep that expands the requirements of your application to an unsustainable level? How do you ensure that your business doesn't get coopted by BoM (Buckets of Money) to basically be a contract development house and eventual acquisition target by your largest enterprise customer while ignoring/harming all your other customers who were earlier adopters? There's a lot of jokes about bugs actually being features, but at some point if an application behaves in a certain way long enough and that behavior is relied on elsewhere, changing it is a new feature with all the consequences that come along with that, even if the new behavior is strictly more correct. All of these factors need to be balanced in determining what the best path is to tread in your software. At a certain scale, most of these questions can be addressed organically, maybe by the developers themselves, but at a certain scale it's just not feasible to interface customers directly with developers. You are working on "new features and new products", because customer issues get turned into identification of new markets to solve those issues, which are serviced by new features and new products rather than by "fixing" the old products and features, which would break it for other customers.

stevoski 8y ago
That's a great description of the subtleties of product development, especially within a small team. Many books and articles make it seem like a simple procedure, but actually you often face decisions which will leave some people unhappy, no matter what you decide.
- Novashi 8y ago
  You basically have to get into supporting extensions or custom code and supporting an API if you run into enough of these customers and that’s when you declare that you only have so much responsibility for the customer’s code (and it quickly turns into another support revenue stream).

lbotos 8y ago

> While in reality at least in my experience the developer would be very much happy to fix the code, it's just that you don't get any time to do that. It's only new features and new products. I agree. At GitLab, I'm trying to build our "Support Engineering" group into people that have the time and mandate to fix the things that spring up leaving product devs to focus on new features. It's been working pretty well: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16511 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16511 (40% view speedup) https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name[]=support-fix https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope...

user68858788 8y ago

I've worked as a developer oncall, and as dedicated support engineer oncall. You're absolutely right - management will absolutely refuse to allot time to improvements and bug fixes when there are features to make. It's frustrating being a Dev and knowing how to fix an issue, but not given the time to fix it. It's equally frustrating to cut tickets and mail reports on issues to see them sit forever in the backlog.

rconti 8y ago

I bet the developer's a lot happier to fix the code when the impact is more severe than yet another ticket.