6 ms·

One thing I've learned is that what often looks like overengineering is actually underengineering -- it's much "easier" to throw together a complicated system t

One thing I've learned is that what often looks like overengineering is actually underengineering -- it's much "easier" to throw together a complicated system than really think things through and develop something that accomplishes the same objectives in a simpler (but possibly more complex) manner.

m463 6y ago
Sometimes it's hard to tell the difference. for instance one smart and experienced guy I knew said if there was an error, your program should just fail instead of giving a ton of messages and recovering. and if you're just throwing code together, that might be what you do. on the other end of the scale, a well written "second pass through everything with cleanup" might have tastefully written code, a few relevant comments and consistency. and then I've seen a lot of code that appears to look like that, but is copy/paste garbage. (sort of the coding equivalent of a wordpress theme)
- darkerside 6y ago
  > your program should just fail instead of giving a ton of messages and recovering I would bet that he was right in that situation, but that he was also making a nuanced statement. Not all code should fail loudly, but when it should, "recovering" can sometimes be a distraction from a very real problem that needs to be addressed by the right person.
- pjc50 6y ago
  I've come round to the "fail hard and early" view, provided you can be sure in your design that it doesn't leave junk lying around. Because otherwise contaminated data and invalid states start propagating everywhere..
  - quicklyfrozen 6y ago
    This can be fun if it's a particular client request that causes a hard failure, and the client retries several times before giving up. Before you know it, all your instances are restarting and no traffic is being handled... So fail early, but not too hard.
  - ziml77 6y ago
    Interestingly I prefer failing hard specifically for data consistency reasons. I've had to deal with systems that swallowed far too many errors and let themselves get into an inconsistent state which then caused other operations to not fail but instead persist invalid data. It's very hard to clean messes like that up (restoring a nightly backup is easy, but that's a last resort).
flyrain 6y ago
Totally agree. That complicated system is called a big ball of mud. Pretty easy to make.
coddle-hark 6y ago
I think poorly engineered is a better term than under engineered in this case, but I agree with you. Logging is my go-to example for this sort of behaviour. People write stupid amounts of log statements in their code, so much that it’s hard to even read the code to understand what it does, in the hopes that it’ll make debugging easier. Use a damned debugger! Take a traffic dump! Use strace! What’s more, it’s extremely rare that libraries provide logs themselves. So the actual complex parts of your application, like say the HTTP library or (God forbid) the TCP stack, can’t be debugged this way. If you find yourself writing a bunch of statements like “DEBUG: updating balance from 1 to 2”, stop and write some tests instead.
- jcelerier 6y ago
  > Use a damned debugger! Take a traffic dump! Use strace! I have encountered a fair amount of cases where that does not work. - debugging a super large program ? loading gdb may take two minutes while recompiling to add a printf only 3-4 seconds. - not an admin on the machine you are and the person with the admin account is not around ? sorry, you can't debug on macos (and likely in some linux distros) - likewise, no traffic dump (and I'd assume no strace) if you don't have root access
  - SCHiM 6y ago
    And how about highly congested multi threaded programs? I've got a program with log statements like that all over the place. Since stepping through it with a debugger would not even be possible. My IDE takes care of hiding the debug statements, since they're all encapsulated in different regions and if-def statements to log different types of things.
    - coddle-hark 6y ago
      Isn’t that what tracepoints are for though? Flipping your argument, you’re basically saying that you can’t debug multithreaded code if the program doesn’t log.
      - 6y ago
lt 6y ago
“I apologize for such a long letter - I didn't have time to write a short one.” ― Mark Twain
- mixmastamyk 6y ago
  I've seen that attributed first to Pascal: https://quoteinvestigator.com/2012/04/28/shorter-letter/ https://quoteinvestigator.com/2012/04/28/shorter-letter/ There may be better information.
hinkley 6y ago
A blogger I read when people still did such things asserted that this sort of overengineering is fear. It's really dreadfully obvious once you know to look for it. People are so afraid of making a bad decision that they refuse to make any decision at all, and then make a giant mess in the process. What you should do is spend your energy on finding reversible decisions, and then not spend a lot of effort on actually making them. We know where the paint store is, we know they can make up paint in 15 minutes, fuck it, paint it blue, we can always paint over it later. Hard no to black, though, since you can't paint over that shit. People are so used to avoiding decisions that on a few occasions I've entirely flustered someone who wanted to tear into me (sometimes with an audience) but cutting them off and saying, "Yeah that was a mistake, and here's how we're going to fix it." None of them had any idea how to recover from someone saying "I was wrong" and going on to try to fix the problem. I still have a little video in my head of one guy's eyes bugging out when he realized what I just said.

m463 6y ago

Sometimes it's hard to tell the difference. for instance one smart and experienced guy I knew said if there was an error, your program should just fail instead of giving a ton of messages and recovering. and if you're just throwing code together, that might be what you do. on the other end of the scale, a well written "second pass through everything with cleanup" might have tastefully written code, a few relevant comments and consistency. and then I've seen a lot of code that appears to look like that, but is copy/paste garbage. (sort of the coding equivalent of a wordpress theme)

darkerside 6y ago
> your program should just fail instead of giving a ton of messages and recovering I would bet that he was right in that situation, but that he was also making a nuanced statement. Not all code should fail loudly, but when it should, "recovering" can sometimes be a distraction from a very real problem that needs to be addressed by the right person.
pjc50 6y ago
I've come round to the "fail hard and early" view, provided you can be sure in your design that it doesn't leave junk lying around. Because otherwise contaminated data and invalid states start propagating everywhere..
- quicklyfrozen 6y ago
  This can be fun if it's a particular client request that causes a hard failure, and the client retries several times before giving up. Before you know it, all your instances are restarting and no traffic is being handled... So fail early, but not too hard.
- ziml77 6y ago
  Interestingly I prefer failing hard specifically for data consistency reasons. I've had to deal with systems that swallowed far too many errors and let themselves get into an inconsistent state which then caused other operations to not fail but instead persist invalid data. It's very hard to clean messes like that up (restoring a nightly backup is easy, but that's a last resort).

flyrain 6y ago

Totally agree. That complicated system is called a big ball of mud. Pretty easy to make.

coddle-hark 6y ago

I think poorly engineered is a better term than under engineered in this case, but I agree with you. Logging is my go-to example for this sort of behaviour. People write stupid amounts of log statements in their code, so much that it’s hard to even read the code to understand what it does, in the hopes that it’ll make debugging easier. Use a damned debugger! Take a traffic dump! Use strace! What’s more, it’s extremely rare that libraries provide logs themselves. So the actual complex parts of your application, like say the HTTP library or (God forbid) the TCP stack, can’t be debugged this way. If you find yourself writing a bunch of statements like “DEBUG: updating balance from 1 to 2”, stop and write some tests instead.

jcelerier 6y ago
> Use a damned debugger! Take a traffic dump! Use strace! I have encountered a fair amount of cases where that does not work. - debugging a super large program ? loading gdb may take two minutes while recompiling to add a printf only 3-4 seconds. - not an admin on the machine you are and the person with the admin account is not around ? sorry, you can't debug on macos (and likely in some linux distros) - likewise, no traffic dump (and I'd assume no strace) if you don't have root access
- SCHiM 6y ago
  And how about highly congested multi threaded programs? I've got a program with log statements like that all over the place. Since stepping through it with a debugger would not even be possible. My IDE takes care of hiding the debug statements, since they're all encapsulated in different regions and if-def statements to log different types of things.
  - coddle-hark 6y ago
    Isn’t that what tracepoints are for though? Flipping your argument, you’re basically saying that you can’t debug multithreaded code if the program doesn’t log.
    - 6y ago

lt 6y ago

“I apologize for such a long letter - I didn't have time to write a short one.” ― Mark Twain

mixmastamyk 6y ago
I've seen that attributed first to Pascal: https://quoteinvestigator.com/2012/04/28/shorter-letter/ https://quoteinvestigator.com/2012/04/28/shorter-letter/ There may be better information.

hinkley 6y ago

A blogger I read when people still did such things asserted that this sort of overengineering is fear. It's really dreadfully obvious once you know to look for it. People are so afraid of making a bad decision that they refuse to make any decision at all, and then make a giant mess in the process. What you should do is spend your energy on finding reversible decisions, and then not spend a lot of effort on actually making them. We know where the paint store is, we know they can make up paint in 15 minutes, fuck it, paint it blue, we can always paint over it later. Hard no to black, though, since you can't paint over that shit. People are so used to avoiding decisions that on a few occasions I've entirely flustered someone who wanted to tear into me (sometimes with an audience) but cutting them off and saying, "Yeah that was a mistake, and here's how we're going to fix it." None of them had any idea how to recover from someone saying "I was wrong" and going on to try to fix the problem. I still have a little video in my head of one guy's eyes bugging out when he realized what I just said.