3 ms·

> I don't find that writing short, single responsibility code that is well labelled takes any time at all. Writing it takes no time; designing it does. > That

by pif 3y ago

> I don't find that writing short, single responsibility code that is well labelled takes any time at all. Writing it takes no time; designing it does. > That initial "bottom up" process is the "getting it to work" part of the process, which is fun for most devs. It's not about having fun: it's about getting the functionality to the first users, and then, finally, you can get some slack and have fun and refactor your code for future changes. But functionality is what sells: clean code is invisible to the users and thus to the business. Clean code is for us developers, and only for us. We have the right to be egoist and work for our own sake from time to time, and a working functionality is what will let the business close an eye over it for some time.

gspencley 3y ago
> It's not about having fun: it's about getting the functionality to the first users, and then, finally, you can get some slack and have fun and refactor your code for future changes. You're speaking to business motivation, which I intentionally did not touch upon. Everything you said is valid. What I'm speaking about is developer push-back against "clean code." And when a developer is advocating for the business, then it is business push-back. Business push-back is valid because a) their business needs are valid and b) it is very difficult to correlate code quality with business value. There is a correlation, because developer velocity and ability to grow the feature-set and fix defects quickly and efficiently benefits the business as it reduces cost over time and benefits users. But that benefit is long-term and not immediately visible by end users. The business doesn't always want to pay for this up front which is their prerogative, and then we circle back to what you said about developers doing it in order to make our own lives easier because we know the day is going to come when the business gets frustrated that velocity was extremely high at the beginning of the project life-cycle but has ground to a halt. In any event, developer push back is real, and is not tied to business values but to personal developer values. I see code comments (which IMO are smells and point to smells) that say things like "// no point in extracting this anonymous function as it is only a few lines long" ... meanwhile doing so would have taken no extra time at all and it is buried in the middle of a 300 line Promise chain or rjxs stream etc.
Mawr 3y ago
To see how clean code affects users you need to look beyond its direct, first order effects. Clean code is less likely to be buggy, is more malleable and performs better. That's how clean code benefits users, they get to enjoy faster software with fewer bugs and more features.
- pif 3y ago
  > you need to look beyond its direct, first order effects. Sure, I agree! But too many developers, in order to look beyond the first order effects, have a tragic tendency to forget about looking at the first order effects. And that is a big problem!

by pif 3y ago

gspencley 3y ago

> It's not about having fun: it's about getting the functionality to the first users, and then, finally, you can get some slack and have fun and refactor your code for future changes. You're speaking to business motivation, which I intentionally did not touch upon. Everything you said is valid. What I'm speaking about is developer push-back against "clean code." And when a developer is advocating for the business, then it is business push-back. Business push-back is valid because a) their business needs are valid and b) it is very difficult to correlate code quality with business value. There is a correlation, because developer velocity and ability to grow the feature-set and fix defects quickly and efficiently benefits the business as it reduces cost over time and benefits users. But that benefit is long-term and not immediately visible by end users. The business doesn't always want to pay for this up front which is their prerogative, and then we circle back to what you said about developers doing it in order to make our own lives easier because we know the day is going to come when the business gets frustrated that velocity was extremely high at the beginning of the project life-cycle but has ground to a halt. In any event, developer push back is real, and is not tied to business values but to personal developer values. I see code comments (which IMO are smells and point to smells) that say things like "// no point in extracting this anonymous function as it is only a few lines long" ... meanwhile doing so would have taken no extra time at all and it is buried in the middle of a 300 line Promise chain or rjxs stream etc.

Mawr 3y ago

To see how clean code affects users you need to look beyond its direct, first order effects. Clean code is less likely to be buggy, is more malleable and performs better. That's how clean code benefits users, they get to enjoy faster software with fewer bugs and more features.

pif 3y ago
> you need to look beyond its direct, first order effects. Sure, I agree! But too many developers, in order to look beyond the first order effects, have a tragic tendency to forget about looking at the first order effects. And that is a big problem!