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

Logging as a code smell

dave.autonoma.ca

Post reply on HN
Print view View original

41–50 of 54 posts

Re: Logging as a code smell

#41

Post by xwolfi »

sorokod wrote: post #39
908B64B197 wrote: post #24

Earlier quoted context omitted.

That's an organizational problem, not a technical one.

That developers don't have live access is dictated by industry rules in some cases. Not a problem but rather a fact of life.

So who has access, if at all ? If nobody has access, how is deployment done or setup ? Can you imagine the "deployer" person ... learning or being replaced by a developer ?

This is an organisational weakness not to have figured out a way to make the people responsible for production, also responsible for reproduction and bug fixing.

I've seen companies with a full team of developers who never add new features but only reproduce and fix the errors of the other feature teams, companies with read-only access to obfuscated informations good enough to reproduce without any client reference, companies who localize enough people in each jurisdiction the production is regulated in rather than have everyone out and unable to reach it.

It's an organisational problem, fix it instead of saying it's impossible to be creative with it. And if my experience if anything to go by, regulators and auditors are either misunderstood in wayyy too conservative ways or are themselves misunderstanding in conservative ways their own rules: there always are ways to explain that it's more risky not to maintain production rather than let if rot slowly because "I can't ssh to the box".

While it's always easier to be conservative with vague rules, it's also always possible to be clear faced with absurdity and it's rare people embrace the absurdity: usually they tell you: "I'll lose my job if I don't follow the rule X put in place 20 years ago" and not "I want the production to be offline the entire day during heavy traffic because I think clients prefer when they can't use our software". So, easy: "20 years ago, X. made a mistake - let's show him", and the answer from X is almost always "Why the fuck are you even asking me, ofc exceptions are possible, fix now we do the process after". And "doing the process" is often to can the old rule, or make it change so much it loses all fear factor and start being actually useful.

Give up and rot, give feedback and soar :)

Re: Logging as a code smell

#42

Post by ghotli »

908B64B197 wrote: post #24
rad_gruchalski wrote: post #23

Earlier quoted context omitted.

What if you don’t have physical access to a production system?

That's an organizational problem, not a technical one.

Just a bit of color to other replies here. Financial industries of course have audits and those audits require controls to be written. Controls can have human / organizational solutions as well as technical solutions and they'll ask for proof that these controls are followed.

Figure out how to write a control and prove it to the auditors that it's followed and adheres to both of these, then I guess you're golden. Probably easier said than done.

FFIEC audit handbook excerpts for "Segregation of Duties" [1] and "Principle of least privilege" [2]

[1] https://ithandbook.ffiec.gov/it-booklets/information-securit...

[2] https://ithandbook.ffiec.gov/it-booklets/information-securit...

Re: Logging as a code smell

#43

Post by jpgvm »

zepolen wrote: post #36
jpgvm wrote: post #14

Earlier quoted context omitted.

You my friend need to experience an interactive debugger.

You my friend need to experience a production heisenbug.

I think you are taking the comment rather out of context and just took the chance to be snarky. The gentleman I was replying to is clearly new to the gig and he should try out a debugger, it will change his workflow immensely and likely make him a much better developer.

Yes, you still want logs (or events or traces, etc) in production to identify when edge cases or heisenbugs have occurred. A debugger doesn't replace those but it does replace 'println` style debugging when developing new code.

Re: Logging as a code smell

#44

Post by kevin_thibedeau »

SV_BubbleTime wrote: post #6

I love the idea of an event bus, but all I use is C and embedded. The last time I considered it I backed away from it. Wish there was effort to establish a pattern for this in C.

You can do this in C without all the enterprisey ceremony. All you need is a way to send messages to a queue and have them dispatched to registered listeners. The "message" can be nothing more than an encoded integer or something more complex. This lets you have a decoupled interface between interacting subsystems.

Re: Logging as a code smell

#46

Post by zepolen »

jpgvm wrote: post #43
zepolen wrote: post #36

Earlier quoted context omitted.

You my friend need to experience a production heisenbug.

I think you are taking the comment rather out of context and just took the chance to be snarky. The gentleman I was replying to is clearly new to the gig and he should try out a debugger, it will change his workflow immensely and likely make him a much better developer. Yes, you still want logs (or events or traces, etc) in production to identify when edge cases or heisenbugs have occurred. A debugger doesn't replace…

> it will change his workflow immensely and likely make him a much better developer

Frankly the best developers I have met did not rely on debuggers, or logs for that matter. Using neither forces them to keep the program flow in their head and completely understand the code and system before pressing run.

For debugging production systems of course logs are useful.

Re: Logging as a code smell

#47

Post by theshrike79 »

gregoryl wrote: post #8
dimgl wrote: post #4

I'm not sure this article does a good enough job of explaining why it's a code smell. Aside from the event bus code looking slightly better, I don't see any big advantages. One disadvantage is that if you have a big class with lots of different events, you now have to import all of your events rather than just importing the singular logger. Typically I only resort to logging in situations where I don't want to propag…

Awful hard to attach a debugger to a production system?

Usually impossible.

It's easier to tell the customers to send the logs from the relevant timeframe and narrow down the problem. Maybe instruct them to up the log level a bit and see if the problem surfaces again.

Always log enough to see where the bug is just by looking at the logs. Getting permission to deploy a new version with additional logging might be a bit of a pain.

Re: Logging as a code smell

#48

Post by theshrike79 »

xwolfi wrote: post #41
sorokod wrote: post #39

Earlier quoted context omitted.

That developers don't have live access is dictated by industry rules in some cases. Not a problem but rather a fact of life.

So who has access, if at all ? If nobody has access, how is deployment done or setup ? Can you imagine the "deployer" person ... learning or being replaced by a developer ? This is an organisational weakness not to have figured out a way to make the people responsible for production, also responsible for reproduction and bug fixing. I've seen companies with a full team of developers who never add new features but onl…

Lets's say you run a company and buy a piece of software. The business you're in is regulated and deals with people's personal information.

Would you let a random coder come in an attach their laptop to your network and start digging around for a problem in their software? Especially if it's your ass on the line if any regulated data is seen by the wrong pair of eyes?

Or would you just ship them the logs from their own software and tell them to figure it out.

Re: Logging as a code smell

#49

Post by BerislavLopac »

edsrzf wrote: post #37

I agree logging is a bit of a code smell, but I prefer Mark Seemann's take: https://blog.ploeh.dk/2020/03/23/repeatable-execution/ TL;DR: Log impure actions. If you minimize and group side effects, you don't need to log as much. Pure functions can be recomputed any time if you know their inputs. Event buses can be useful, but it's hard to look at an event being published and know what it does and whether it's importa…

One big argument in favour of that approach is the oft-forgotten (or at least ignored) fact that logging is, pretty much by definition, a side effect itself.

Re: Logging as a code smell

#50

Post by sorokod »

xwolfi wrote: post #41
sorokod wrote: post #39

Earlier quoted context omitted.

That developers don't have live access is dictated by industry rules in some cases. Not a problem but rather a fact of life.

So who has access, if at all ? If nobody has access, how is deployment done or setup ? Can you imagine the "deployer" person ... learning or being replaced by a developer ? This is an organisational weakness not to have figured out a way to make the people responsible for production, also responsible for reproduction and bug fixing. I've seen companies with a full team of developers who never add new features but onl…

Didn't say that "nobody has access" - only explicitly authorised people do. In addition log data is often stored and indexed in a central location. Access to that data also requires authorization.

Does this clarifies things?

Post reply on HN