5 ms·

I agree with you. Too many of us developers tend to forget that the customer only looks at the features. Clean code, unit tests, rigorous processes... they are

by pif 2y ago

I agree with you. Too many of us developers tend to forget that the customer only looks at the features. Clean code, unit tests, rigorous processes... they are only as valuable as the rate of features they make possible. Complexity and technical debt are our problem, and the customer could not care less about how we solve it, or even whether we solve it. As long as we are struggling with an old piece of sh*t, that's good for us: it means the product is selling and the effort to maintain it still makes sense! Selling without complexity and technical debt would be much better, I think we all agree on this, but it's a receipt whose success I have never personally witnessed.

kunley 2y ago
"customer could not care less". This perspective is too narrow, or even a fallacy, often repeated to justify abandoning some good practices. Oh yeah customer cares. If I leave my car in a workshop, I care whether mechanics have one big mess there or not, I am looking for signs of a good routine, clever process, some smart choices they made for themselves. If they did a fix for me but have a mess, I will never go back to them. Most of customers do such choices.
- jagged-chisel 2y ago
  In software, all that is hidden from the end customer. How do you look for the smart choices in code made by the team who implemented any of the software you download and install?
  - FroshKiller 2y ago
    Poor choices during development reveal themselves in many ways: poor performance, awkward workflows, mandatory upgrades, one-way data conversions, inaccurate documentation, and so on.
    - pif 2y ago
      > Poor choices during development reveal themselves in many ways: ... All the examples you provided miss the point. Revenues are the point; all the rest is ancillary at best.
      - FroshKiller 2y ago
        I'm not sure what you mean. jagged-chisel asked how we look for smart choices in the software we download and install. I gave examples of how poor choices manifest for end users, the idea being that a lack of those issues suggests smart choices. I don't see how revenue is relevant to the question. Revenue for whom? And how did my examples miss the point exactly?
    - lelanthran 2y ago
      > Poor choices during development reveal themselves in many ways: poor performance, awkward workflows, mandatory upgrades, one-way data conversions, inaccurate documentation, and so on. Not necessarily. Some otherwise good systems might have one bug in each of those categories. And, most other poorly designed and poorly executed systems just chug along fine without the customer realising anything.
      - stouset 2y ago
        Sure, fine, a well-designed system can have bugs and a giant ball of duct tape and twine can work great. That's not the norm though and I hope we can all acknowledge that.
  - kunley 2y ago
    Oh believe me, I use a lot of corporate software where the flaws in development are obvious, without knowing any of the people involved
    - karatinversion 2y ago
      Doesn’t the fact you do use it mean the customer (the one who chooses the vendor) did not care, though?
      - Supermancho 2y ago
        Choices of vendor are not binary. There are tradeoffs between available solutions in software. Software Quality is not a linear gradient. If your solution is the best compromise, it is more likely to be selected.
        kunley 2y ago
        Well at companies is much less compromise than politics. Over decaces I saw two main schemas: - product must be purchased because its vendor is somehow connected to the upper management or the investor - product must be purchased because the person who has chosen the product is at the moment perceived as having some kind of holy cow status and can't be criticized, so people around put that to the extreme Happening at most of companies everywhere.
      - kunley 2y ago
        That's obviously different because at the corp level there are politics involved in choosing one vendor over another, but at the same time wheverer I'm involved in the decision process I care to avoid these products as hell.
      - axus 2y ago
        If you're in one place for more than a few years, you become the person making these choices, and you don't forget.
- lelanthran 2y ago
  > Oh yeah customer cares. If I leave my car in a workshop, I care whether mechanics have one big mess there or not, I am looking for signs of a good routine, clever process, some smart choices they made for themselves. If they did a fix for me but have a mess, I will never go back to them. In your car, you can tell, in software you cannot. Add in the fact that most times even cowboy-coded systems are once off and will be replaced (and not maintained) down the line, and you really cannot tell if the system was written as a huge mess just waiting to be exploited, or as a well-crafted and resilient system, because the majority of systems are in-house only and face no adverserial threats other than the employees.
  - kunley 2y ago
    I respectfully disagree. I can tell about bad development habits from using the software it because code smell (and process smell) stinks. Besides, I was telling not about car repair per se, but about the process around car repairing, which is visible when you visit car workshop and talk to the guys, and is even more visible when you use the software. Concrete examples: - installation/upgrade process involving interactive scripts means that somebody thought dumbing down such process for a tiny percent of less-tech users is ok, disregarding the majority who automate everything (and interactive scripts are obviously harder to automate); it also can be a sign that vendor's decision maker (product owner) is disconnected from reality - poor documentation; a distinct case here is when part of the product is an API and of course "there is" documentation, generated by Swagger - but the crucial part of it are some subtleties of arguments passed which are themselves undocumented, making the whole API simply unusable. The vendor has an excuse "but we have documentation" - heck yes, it's because your employees hate their superiors so they gave them something to f*ck off; and this is given to the customer. Very common practice actually, I can give you a list of vendors who notoriously do that - painfully slow webapps are a sign of a process smell that no one thinks about the real world operations; sometimes it's not even about scalability, but bad choice/usage of libraries; i need to give here names, in rot13 so it's not googlable: Argfhvgr has a HR product for corporations where every single damn click on any active field in the browser - and you click it a lot because it is fscking calendar - triggers a series of round trips to the server, each taking over 2 seconds. The usability of this product is so braindead at so many levels that I can see a whole bunch of teams failing to stop this sh*t from being released & sold. Long story but a good example that just by using the product you can see how rotten the vendor must be
resonious 2y ago
Customers care a lot about defects, and I've seen defects increase dramatically due to complexity and technical debt.
pydry 2y ago
What gets forgotten is the thing you can't see. Persistent refactoring is one of those things where the cost is clear and well known (expensive developer time) while the payoff is big, but very diffuse, very hard to explain and often gets attributed to something else - sometimes even by the developers who did it. It's not the only thing like that. Plenty of companies skimp on cost centers and fail spectacularly as a result - sometimes without even ever realizing that skimping on the relevant cost centres was the reason why they failed.
- AndyMcConachie 2y ago
  Refactoring only matters if decision makers care about long term consequences and value. One thing that makes it difficult to make these kinds of decisions wisely is that no one knows how long a piece of software will live in production. If I could know for sure that a piece of software would exist for 50 years in production I could make a better case for refactoring. Likewise, if I knew for sure that a piece of software would get completely replaced in 1 year I would not bother with refactoring. Never in my career have I been able to accurately predict how long software would live in production. I have had throwaway code live for years and things I thought would last forever get replaced almost instantly.
  - pydry 2y ago
    Refactoring doesn't just benefit you in 50 years it can benefit within weeks. I agree that it's a waste on throwaway code, throwaway code is common and what ends up being throwaway code is hard to predict, but I don't think it's impossible to get a sense of the likelihood of the code being tossed, and that sense can be used to tweak your refactoring budget.
    - Supermancho 2y ago
      > Refactoring doesn't just benefit you in 50 years it can benefit within weeks. Proving the value is the hard problem. It's almost impossible to prove the value of small changes today. Product wants things to do X and they decided the value tradeoff was good, not the engineers who are tasked with making it so.
makingstuffs 2y ago
While it is hard to generalise to an absolute I do largely agree with this sentiment. The amount of times I have advised clients to not use something like Wordpress to just end up having to use a page builder like Divi hurts my soul. At the end of the day the majority don’t care about things like carrying bloat/legacy code, rigorous testing patterns, using modern tech stacks or typesafe codebases. They simply want you to “make thing go brr”. I can advise until I am blue in the face but the reality is that at least 90% of all my clients want the quickest and cheapest option, resulting in me barely even scratching the surface of my technical abilities. I guess the main thing from a business perspective is that I’m getting paid but, at the same time, ouch, my feels.
- abirch 2y ago
  I agree with you though I'd state the cheapest upfront option. They tend to cost more in the long run. See Terry Pratchett's boot theory: https://en.m.wikipedia.org/wiki/Boots_theory https://en.m.wikipedia.org/wiki/Boots_theory
  - datadrivenangel 2y ago
    The problem with this theory is that the $50 boot manufacturers sell out to private equity when the founder wants to retire and then the PE firm jacks up the price to $75 and drops the quality below the $10 cardboard boots... so you're out even more money to have wet feet.
- bluGill 2y ago
  > I can advise until I am blue in the face but the reality is that at least 90% of all my clients want the quickest and cheapest option, resulting in me barely even scratching the surface of my technical abilities. Until more client gets burned with a cheap option that becomes expensive to maintain they won't care. Many clients (across the whole industry, I don't know your clients which could be very different from average) will not get burned as most problems will never get that complex. However most clients have a lot of small problems that are quick to solve meaning that most developers spend their time on the small minority of clients that have complex problems where this matters.
sinaid 2y ago
The customer would also be elated if they paid you nothing and they were your only customer.

by pif 2y ago

kunley 2y ago

"customer could not care less". This perspective is too narrow, or even a fallacy, often repeated to justify abandoning some good practices. Oh yeah customer cares. If I leave my car in a workshop, I care whether mechanics have one big mess there or not, I am looking for signs of a good routine, clever process, some smart choices they made for themselves. If they did a fix for me but have a mess, I will never go back to them. Most of customers do such choices.

jagged-chisel 2y ago
In software, all that is hidden from the end customer. How do you look for the smart choices in code made by the team who implemented any of the software you download and install?
- FroshKiller 2y ago
  Poor choices during development reveal themselves in many ways: poor performance, awkward workflows, mandatory upgrades, one-way data conversions, inaccurate documentation, and so on.
  - pif 2y ago
    > Poor choices during development reveal themselves in many ways: ... All the examples you provided miss the point. Revenues are the point; all the rest is ancillary at best.
    - FroshKiller 2y ago
      I'm not sure what you mean. jagged-chisel asked how we look for smart choices in the software we download and install. I gave examples of how poor choices manifest for end users, the idea being that a lack of those issues suggests smart choices. I don't see how revenue is relevant to the question. Revenue for whom? And how did my examples miss the point exactly?
  - lelanthran 2y ago
    > Poor choices during development reveal themselves in many ways: poor performance, awkward workflows, mandatory upgrades, one-way data conversions, inaccurate documentation, and so on. Not necessarily. Some otherwise good systems might have one bug in each of those categories. And, most other poorly designed and poorly executed systems just chug along fine without the customer realising anything.
    - stouset 2y ago
      Sure, fine, a well-designed system can have bugs and a giant ball of duct tape and twine can work great. That's not the norm though and I hope we can all acknowledge that.
- kunley 2y ago
  Oh believe me, I use a lot of corporate software where the flaws in development are obvious, without knowing any of the people involved
  - karatinversion 2y ago
    Doesn’t the fact you do use it mean the customer (the one who chooses the vendor) did not care, though?
    - Supermancho 2y ago
      Choices of vendor are not binary. There are tradeoffs between available solutions in software. Software Quality is not a linear gradient. If your solution is the best compromise, it is more likely to be selected.
      - kunley 2y ago
        Well at companies is much less compromise than politics. Over decaces I saw two main schemas: - product must be purchased because its vendor is somehow connected to the upper management or the investor - product must be purchased because the person who has chosen the product is at the moment perceived as having some kind of holy cow status and can't be criticized, so people around put that to the extreme Happening at most of companies everywhere.
    - kunley 2y ago
      That's obviously different because at the corp level there are politics involved in choosing one vendor over another, but at the same time wheverer I'm involved in the decision process I care to avoid these products as hell.
    - axus 2y ago
      If you're in one place for more than a few years, you become the person making these choices, and you don't forget.
lelanthran 2y ago
> Oh yeah customer cares. If I leave my car in a workshop, I care whether mechanics have one big mess there or not, I am looking for signs of a good routine, clever process, some smart choices they made for themselves. If they did a fix for me but have a mess, I will never go back to them. In your car, you can tell, in software you cannot. Add in the fact that most times even cowboy-coded systems are once off and will be replaced (and not maintained) down the line, and you really cannot tell if the system was written as a huge mess just waiting to be exploited, or as a well-crafted and resilient system, because the majority of systems are in-house only and face no adverserial threats other than the employees.
- kunley 2y ago
  I respectfully disagree. I can tell about bad development habits from using the software it because code smell (and process smell) stinks. Besides, I was telling not about car repair per se, but about the process around car repairing, which is visible when you visit car workshop and talk to the guys, and is even more visible when you use the software. Concrete examples: - installation/upgrade process involving interactive scripts means that somebody thought dumbing down such process for a tiny percent of less-tech users is ok, disregarding the majority who automate everything (and interactive scripts are obviously harder to automate); it also can be a sign that vendor's decision maker (product owner) is disconnected from reality - poor documentation; a distinct case here is when part of the product is an API and of course "there is" documentation, generated by Swagger - but the crucial part of it are some subtleties of arguments passed which are themselves undocumented, making the whole API simply unusable. The vendor has an excuse "but we have documentation" - heck yes, it's because your employees hate their superiors so they gave them something to f*ck off; and this is given to the customer. Very common practice actually, I can give you a list of vendors who notoriously do that - painfully slow webapps are a sign of a process smell that no one thinks about the real world operations; sometimes it's not even about scalability, but bad choice/usage of libraries; i need to give here names, in rot13 so it's not googlable: Argfhvgr has a HR product for corporations where every single damn click on any active field in the browser - and you click it a lot because it is fscking calendar - triggers a series of round trips to the server, each taking over 2 seconds. The usability of this product is so braindead at so many levels that I can see a whole bunch of teams failing to stop this sh*t from being released & sold. Long story but a good example that just by using the product you can see how rotten the vendor must be

resonious 2y ago

Customers care a lot about defects, and I've seen defects increase dramatically due to complexity and technical debt.

pydry 2y ago

What gets forgotten is the thing you can't see. Persistent refactoring is one of those things where the cost is clear and well known (expensive developer time) while the payoff is big, but very diffuse, very hard to explain and often gets attributed to something else - sometimes even by the developers who did it. It's not the only thing like that. Plenty of companies skimp on cost centers and fail spectacularly as a result - sometimes without even ever realizing that skimping on the relevant cost centres was the reason why they failed.

AndyMcConachie 2y ago
Refactoring only matters if decision makers care about long term consequences and value. One thing that makes it difficult to make these kinds of decisions wisely is that no one knows how long a piece of software will live in production. If I could know for sure that a piece of software would exist for 50 years in production I could make a better case for refactoring. Likewise, if I knew for sure that a piece of software would get completely replaced in 1 year I would not bother with refactoring. Never in my career have I been able to accurately predict how long software would live in production. I have had throwaway code live for years and things I thought would last forever get replaced almost instantly.
- pydry 2y ago
  Refactoring doesn't just benefit you in 50 years it can benefit within weeks. I agree that it's a waste on throwaway code, throwaway code is common and what ends up being throwaway code is hard to predict, but I don't think it's impossible to get a sense of the likelihood of the code being tossed, and that sense can be used to tweak your refactoring budget.
  - Supermancho 2y ago
    > Refactoring doesn't just benefit you in 50 years it can benefit within weeks. Proving the value is the hard problem. It's almost impossible to prove the value of small changes today. Product wants things to do X and they decided the value tradeoff was good, not the engineers who are tasked with making it so.

makingstuffs 2y ago

While it is hard to generalise to an absolute I do largely agree with this sentiment. The amount of times I have advised clients to not use something like Wordpress to just end up having to use a page builder like Divi hurts my soul. At the end of the day the majority don’t care about things like carrying bloat/legacy code, rigorous testing patterns, using modern tech stacks or typesafe codebases. They simply want you to “make thing go brr”. I can advise until I am blue in the face but the reality is that at least 90% of all my clients want the quickest and cheapest option, resulting in me barely even scratching the surface of my technical abilities. I guess the main thing from a business perspective is that I’m getting paid but, at the same time, ouch, my feels.

abirch 2y ago
I agree with you though I'd state the cheapest upfront option. They tend to cost more in the long run. See Terry Pratchett's boot theory: https://en.m.wikipedia.org/wiki/Boots_theory https://en.m.wikipedia.org/wiki/Boots_theory
- datadrivenangel 2y ago
  The problem with this theory is that the $50 boot manufacturers sell out to private equity when the founder wants to retire and then the PE firm jacks up the price to $75 and drops the quality below the $10 cardboard boots... so you're out even more money to have wet feet.
bluGill 2y ago
> I can advise until I am blue in the face but the reality is that at least 90% of all my clients want the quickest and cheapest option, resulting in me barely even scratching the surface of my technical abilities. Until more client gets burned with a cheap option that becomes expensive to maintain they won't care. Many clients (across the whole industry, I don't know your clients which could be very different from average) will not get burned as most problems will never get that complex. However most clients have a lot of small problems that are quick to solve meaning that most developers spend their time on the small minority of clients that have complex problems where this matters.

sinaid 2y ago

The customer would also be elated if they paid you nothing and they were your only customer.