Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Code quality only matters in context (2019)

adamtornhill.com

Post reply on HN
Print view View original

41–50 of 78 posts

Re: Code quality only matters in context (2019)

#41

Post by WesolyKubeczek »

There are five questions I like to ask about any codebase I’m given to work with:

1) suppose I have a bug to fix, how deep should I, on average, go to get to the cause? How many files do I need to jump through to determine a trivial flow of data from a to b?

2) there’s a straightforward feature or edge case, how easy is it to add it?

3) (for dynamic languages) is it possible to get the full list of usages for a particular function/method I’m changing?

4) is it possible to correctly identify and eliminate a portion of code that has been unused for a while?

5) are there areas no one knows how they work and everybody is afraid of touching because nobody is sure what would break and how?

I use these things to determine the code quality. Perceived cleanliness doesn’t affect the quality.

Re: Code quality only matters in context (2019)

#42

Post by salawat »

xupybd wrote: post #22
karatinversion wrote: post #17

Earlier quoted context omitted.

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.

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.

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.

Re: Code quality only matters in context (2019)

#43

Post by shkkmo »

xupybd wrote: post #21
laserlight wrote: post #11

> Or maybe I decide to squeeze in an extra if-statement in already tricky code. And that's how the long tail becomes long tail. Nobody touches that part of the repo, because you have made it untouchable. People find working around easier than understanding and modifying existing code. Mess becomes messier. Writing clean code is not about introducing big abstractions, large refactors. It's about leaving the place bett…

Sometimes you have a root cause deep in the architecture. As long as that cause exists you will have to work around it. Each work around will have to be removed if you ever fix the root cause. I saw this as a developer and had thought it was better to just leave the architecture alone and keep the work arounds as tidy as possible. Then I started working in manufacturing, a production line has many similarities to a r…

If you are implementing a workaround, then that is a potential opportunity to solve a root problem deep in the architecture.

The point being made is that going in to fix that root cause because you think that there will be a need for workarounds in the future is premature and can cause problems and unnecessarily break working code.

Re: Code quality only matters in context (2019)

#44

Post by thaumasiotes »

xupybd wrote: post #21
laserlight wrote: post #11

> Or maybe I decide to squeeze in an extra if-statement in already tricky code. And that's how the long tail becomes long tail. Nobody touches that part of the repo, because you have made it untouchable. People find working around easier than understanding and modifying existing code. Mess becomes messier. Writing clean code is not about introducing big abstractions, large refactors. It's about leaving the place bett…

Sometimes you have a root cause deep in the architecture. As long as that cause exists you will have to work around it. Each work around will have to be removed if you ever fix the root cause. I saw this as a developer and had thought it was better to just leave the architecture alone and keep the work arounds as tidy as possible. Then I started working in manufacturing, a production line has many similarities to a r…

> Each work around will have to be removed if you ever fix the root cause.

Do they? I feel like many workarounds will just hang around, checking for situations like inconsistent state that no longer arise. You might be better off removing checks for conditions that no longer occur (or not...), but it's not exactly urgent.

Re: Code quality only matters in context (2019)

#45

Post by arinlen »

salawat wrote: post #42
xupybd wrote: post #22

Earlier quoted context omitted.

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.

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…

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

Re: Code quality only matters in context (2019)

#46

Post by Anderkent »

arinlen wrote: post #39
laserlight wrote: post #11

> Or maybe I decide to squeeze in an extra if-statement in already tricky code. And that's how the long tail becomes long tail. Nobody touches that part of the repo, because you have made it untouchable. People find working around easier than understanding and modifying existing code. Mess becomes messier. Writing clean code is not about introducing big abstractions, large refactors. It's about leaving the place bett…

> And that's how the long tail becomes long tail. Not really. Developers should only touch production code if there is a good business reason to touch it, whether fixing a bug or adding a feature. If there is no good reason to touch a bit of code, you should not be touching it. Otherwise you're just adding noise to the audit trail, perhaps along with bugs in otherwise perfectly fine code, without any justification. T…

> If you have to implement a feature or fix a bug, complaining that it's old code won't make things go away.

sure, but you might decide to work on a different feature/bug because this part of the code is too arcane to touch

Re: Code quality only matters in context (2019)

#47

Post by davnicwil »

An especially important piece of context is the stage the company is at. At the early stage, pre product market fit, bad code quality can actually be a good signal -- ie not merely not bad, but actively better than good code.

Why? It's evidence that the team is moving quickly and is not afraid to change things in the code in less than ideal ways, because they are focused more on just making stuff work on the business end. This is exactly where you want to be at the early stage of a company, you do not want to be precious about doing things that scale - including writing good code and keeping data models clean and fully coherent.

Re: Code quality only matters in context (2019)

#48

Post by Tade0 »

At some point I started referring to code as expensive/inexpensive instead of good/bad, the metric being "how much money did it cost to first implement and then maintain this feature?". It makes business people pay attention.

I've found that it takes roughly the same time to write expensive and inexpensive code - additional expenses in the former case pile up later on in the form of time spent debugging and/or infrastructure working way too hard for the desired effect.

Unfortunately it takes knowledge and experience to write inexpensive code and it's not rewarded proportionally, so while you might cut expenses with your code by e.g. four, you're likely to be paid at most twice that of a regular developer, provided you get recognition.

Conversely, you can write expensive code and have an average salary - many people go this route, because pretty often it's hard to assign blame should something become expensive a few months later.

Re: Code quality only matters in context (2019)

#49

Post by aardvarkr »

Tade0 wrote: post #48

At some point I started referring to code as expensive/inexpensive instead of good/bad, the metric being "how much money did it cost to first implement and then maintain this feature?". It makes business people pay attention. I've found that it takes roughly the same time to write expensive and inexpensive code - additional expenses in the former case pile up later on in the form of time spent debugging and/or infras…

I think this is a great way to summarize how it works out in the real world. I think I’ll adopt that mindset too.
Post reply on HN