4 ms·

> What's frustrating is people who think that they can radically simplify something without knowing anything about it. I run into this problem with my manager

> What's frustrating is people who think that they can radically simplify something without knowing anything about it. I run into this problem with my manager a lot, who knows just enough to get himself in trouble. There's probably a term for it, but I call it the "complexity trap". He sees a problem, thinks he has an "aha!" moment, and tells me about a simple solution, and asks me to implement it. This solution, of course, disregards most of the complexity inherent in the problem. Complex problems require equally complex solutions, and if the solution is simple, it disregards the complexity of the problem, either shoveling down the ladder of abstraction, or hoping for some future state where it's not as complex.

hedora 5y ago
I’ve found that a small amount of mathematical rigor reduces the size of most complex code by a few orders of magnitude. It has the effect of short circuiting the complexity of the problem, because it defines all the corner cases in a compact form. Interface with sloppy spaghetti systems can usually be hidden away at the edges of the system. The main problem is that less experienced engineers invariably come in and say, “A ha! I have a special corner case that doesn’t fit the abstraction.” and then try to add copy paste methods, boundary violations, and so on. As long as there’s someone that diligently guards against such things, it works out OK. Results vary wildly after those people leave. HP printer drivers are a famous example of the sort of complexity reduction I’m talking about. They used to copy the entire source tree for each printer (font rasterizer, dithering algorithms, and all), then assign a full time team to maintain it. Eventually they had many thousands of full time engineers maintaining the result, and print quality was still terrible across the product line. The open source drivers reverse engineered the printers, and factored out as much common logic as possible. The printer specific code was then reduced to just implementing the wire protocol and device geometry stuff. At that point, they had better output than HP, with 1% the developer resources. Someone at HP did the same thing internally, reimplemented all the drivers in a unified way, and was promptly promoted to the executive team.
- craftinator 5y ago
  > I’ve found that a small amount of mathematical rigor reduces the size of most complex code by a few orders of magnitude. I agree, though this is generally limited to singular problems, and usually becomes harder to implement the higher up the abstraction train you go. I've found this especially true in business logic, where you don't know what the requirements or even end goal is; by the time you're ready to apply some nice mathematical based optimizations at a high abstraction level, doing so often requires a lot of work exposing all of the information you need from lower abstraction layers. All comes down to planning. > As long as there’s someone that diligently guards against such things, it works out OK. Results vary wildly after those people leave. This is specifically why I mentioned my manager haha, who will both come up with crazy edge cases that in many cases don't even apply, and will come up with "aha!" solutions to problems that ignore major edge cases. Perks of not working for a software company. Very interesting history on the HP printer drivers, thanks for sharing that. I do remember some of the evolution that they went through, from the Linux perspective, and it was amazing how that tangled mess just started to magically work, circa 2008 if I remember right.

hedora 5y ago

I’ve found that a small amount of mathematical rigor reduces the size of most complex code by a few orders of magnitude. It has the effect of short circuiting the complexity of the problem, because it defines all the corner cases in a compact form. Interface with sloppy spaghetti systems can usually be hidden away at the edges of the system. The main problem is that less experienced engineers invariably come in and say, “A ha! I have a special corner case that doesn’t fit the abstraction.” and then try to add copy paste methods, boundary violations, and so on. As long as there’s someone that diligently guards against such things, it works out OK. Results vary wildly after those people leave. HP printer drivers are a famous example of the sort of complexity reduction I’m talking about. They used to copy the entire source tree for each printer (font rasterizer, dithering algorithms, and all), then assign a full time team to maintain it. Eventually they had many thousands of full time engineers maintaining the result, and print quality was still terrible across the product line. The open source drivers reverse engineered the printers, and factored out as much common logic as possible. The printer specific code was then reduced to just implementing the wire protocol and device geometry stuff. At that point, they had better output than HP, with 1% the developer resources. Someone at HP did the same thing internally, reimplemented all the drivers in a unified way, and was promptly promoted to the executive team.

craftinator 5y ago
> I’ve found that a small amount of mathematical rigor reduces the size of most complex code by a few orders of magnitude. I agree, though this is generally limited to singular problems, and usually becomes harder to implement the higher up the abstraction train you go. I've found this especially true in business logic, where you don't know what the requirements or even end goal is; by the time you're ready to apply some nice mathematical based optimizations at a high abstraction level, doing so often requires a lot of work exposing all of the information you need from lower abstraction layers. All comes down to planning. > As long as there’s someone that diligently guards against such things, it works out OK. Results vary wildly after those people leave. This is specifically why I mentioned my manager haha, who will both come up with crazy edge cases that in many cases don't even apply, and will come up with "aha!" solutions to problems that ignore major edge cases. Perks of not working for a software company. Very interesting history on the HP printer drivers, thanks for sharing that. I do remember some of the evolution that they went through, from the Linux perspective, and it was amazing how that tangled mess just started to magically work, circa 2008 if I remember right.