3 ms·

This seems a very short sighted attitude to me, like saying that there is no time for testing, there are too many bugs to fix.

xupybd 4y ago
If the business fails because it couldn't get to market in time who cares if the code quality was good? Context is critical to knowing when to invest in quality.
- liotier 4y ago
  At an ISP, when I was much younger, at the coffee machine I asked the Technical Director why we didn't invest in some technical cleanup. He replied that any available finances are much more profitably spent in advertising, which was directly correlated to sales, which were critical to survival. I guess that's why there are two sorts of companies: those that survived, and those with great code quality !
- salawat 4y ago
  There are two types of programmer. There is a programmer that reads, absorbs the system as a whole and deals with it as it is. Then there is the programmer who just wants shit written that can get them most of the way there and he'll fix the other shit to do as he wants eventually. The software industry is generally run by the latter. The former are those that see the most value in high quality code, because quality only matters when you can't reerite the thing without applying a cost function. Context is not critical to knowing when to invest in quality. That is paying lip service to the fundamental nature of what business programming is. Running a business staffed with programmers is all about balancing onboarding, spin up, time to contribute, etc, etc. With high quality architecture that business loop is far more efficient. Costwise, time or money, all of that meta-businessy crap dwarfs the actual implementation of new features. ...And you can never rely on the person you need to be there when the chips are down to stay there when it happens, because Murphy finds a way, no exceptions. You do it right from the beginning, or you write shitty software. There is no middle.
  - arinlen 4y ago
    > The software industry is generally run by the latter. Obviously. The latter adds value way faster, instead of wasting time "absorbing" stuff he will never need to touch. Also, the latter understands code is ephemeral and the stuff you're wasting your time trying to "absorb" might not even be around once the next ticket is worked on. Even if it is, it will only need to be worked on if it ever gets in the way of a business requirement. There are plenty of reasons why "goldplating" is a highly pejorative concept in software development.
  - xupybd 4y ago
    So you've introduced the context of large scale mission critical software. Not all software is large scale and not all software is mission critical. Sometimes a crappy script that saves an administrator 2 hours a day can be a Huge win. Sometimes lives are on the line and bugs are not acceptable. Other times the cost of a bug is some internal user has to deal with a little frustration. All investments are about weighing the cost with the potential benefits. Developing software is an investment.
ramesh31 4y ago
>This seems a very short sighted attitude to me, like saying that there is no time for testing, there are too many bugs to fix. It is. The priority for a programmer goes: make it work -> make it fast -> make it clean. And you either have time for all three of those, or you don't. Generally in reality though, when dealing with business needs and product managers, the pipeline becomes: make it work -> alright now make this work -> alright now also make this work.
- epgui 4y ago
  I would argue that for most code, making it clean should be a priority over making it fast (optimizing for simplicity and readability over algorithmic performance). It obviously depends on the application.
arinlen 4y ago
> This seems a very short sighted attitude to me, like saying that there is no time for testing, there are too many bugs to fix. This is not true at all. The definition of "clean code" is highly subjective and context- and experience-dependent. Your personal opinion and feelings towards a code style are not the same as bugs, nor is a lack of compliancd with your personal taste a potential liability similar to not adding a test.

xupybd 4y ago

If the business fails because it couldn't get to market in time who cares if the code quality was good? Context is critical to knowing when to invest in quality.

liotier 4y ago
At an ISP, when I was much younger, at the coffee machine I asked the Technical Director why we didn't invest in some technical cleanup. He replied that any available finances are much more profitably spent in advertising, which was directly correlated to sales, which were critical to survival. I guess that's why there are two sorts of companies: those that survived, and those with great code quality !
salawat 4y ago
There are two types of programmer. There is a programmer that reads, absorbs the system as a whole and deals with it as it is. Then there is the programmer who just wants shit written that can get them most of the way there and he'll fix the other shit to do as he wants eventually. The software industry is generally run by the latter. The former are those that see the most value in high quality code, because quality only matters when you can't reerite the thing without applying a cost function. Context is not critical to knowing when to invest in quality. That is paying lip service to the fundamental nature of what business programming is. Running a business staffed with programmers is all about balancing onboarding, spin up, time to contribute, etc, etc. With high quality architecture that business loop is far more efficient. Costwise, time or money, all of that meta-businessy crap dwarfs the actual implementation of new features. ...And you can never rely on the person you need to be there when the chips are down to stay there when it happens, because Murphy finds a way, no exceptions. You do it right from the beginning, or you write shitty software. There is no middle.
- arinlen 4y ago
  > The software industry is generally run by the latter. Obviously. The latter adds value way faster, instead of wasting time "absorbing" stuff he will never need to touch. Also, the latter understands code is ephemeral and the stuff you're wasting your time trying to "absorb" might not even be around once the next ticket is worked on. Even if it is, it will only need to be worked on if it ever gets in the way of a business requirement. There are plenty of reasons why "goldplating" is a highly pejorative concept in software development.
- xupybd 4y ago
  So you've introduced the context of large scale mission critical software. Not all software is large scale and not all software is mission critical. Sometimes a crappy script that saves an administrator 2 hours a day can be a Huge win. Sometimes lives are on the line and bugs are not acceptable. Other times the cost of a bug is some internal user has to deal with a little frustration. All investments are about weighing the cost with the potential benefits. Developing software is an investment.

ramesh31 4y ago

>This seems a very short sighted attitude to me, like saying that there is no time for testing, there are too many bugs to fix. It is. The priority for a programmer goes: make it work -> make it fast -> make it clean. And you either have time for all three of those, or you don't. Generally in reality though, when dealing with business needs and product managers, the pipeline becomes: make it work -> alright now make this work -> alright now also make this work.

epgui 4y ago
I would argue that for most code, making it clean should be a priority over making it fast (optimizing for simplicity and readability over algorithmic performance). It obviously depends on the application.

arinlen 4y ago

> This seems a very short sighted attitude to me, like saying that there is no time for testing, there are too many bugs to fix. This is not true at all. The definition of "clean code" is highly subjective and context- and experience-dependent. Your personal opinion and feelings towards a code style are not the same as bugs, nor is a lack of compliancd with your personal taste a potential liability similar to not adding a test.