4 ms·

Would you say that these over-engineered solutions actually grasped the problems, and over-engineered the solutions? Or did they not grasp the original problems

Would you say that these over-engineered solutions actually grasped the problems, and over-engineered the solutions? Or did they not grasp the original problems to begin with, and solved tangential problems instead? In my experience it's often the latter that leads to accrued accidental complexity and technical debt. Edit: grammar.

dahart 8y ago
I’ve seen both of those and more. Actually I’d say that from my point of view, there is no such thing as fully grasping the problem while over-engineering it. I’d categorize that as slightly not grasping the whole problem. The complexity of the solution and the budget for solving the problem are part of the problem, not something separate and distinct. I think I’ve more often seen tangential and imagined problems than people doing the right thing the wrong way. To be fair, it can actually be very hard to know whether a problem is really truly a problem that needs to be solved. Some tangential and imagined problems seem important and real, and you don’t discover until later you needed to solve something else and not the thing you did. Some examples: At a games company, the two mathiest programmers decided we needed to be using geometric algebra instead of matrices. They spent years working on it, and the code infected the rigging and animation and rendering systems, all kinds of things. Most of the programmers had to interface with it, but didn’t know geometric algebra, so it slowed development. It only solved minor issues. One of the claims was we’d have no gimbal lock, but people already solve that with matrices in one or two functions, it’s a non issue. To top it off, the math all got a bit slower, and we had to maintain the matrix math anyway to interface with the hardware and external libraries. At a film company all the programmers decided they were tired of the renderer and they needed to start from scratch because making updates was getting slow and difficult. They scrapped the renderer, started over, and it took many multiples longer than they estimated. When they were done, they had roughly the same complexity and ugliness as before, and making updates didn’t get significantly easier. Some mistakes were made in the rush to rewrite everything. Personally, I built a multi-user whiteboard website, and I over-engineered the rendering and the multi-user undo system, convinced they both needed to be perfect. In the mean time, discovered that very few people care about those things or ever hit corner cases, and I missed the opportunity to write proper integrations with other tools and import/export tools — the things the customers needed in order to adopt my software for their workflows.

dahart 8y ago

I’ve seen both of those and more. Actually I’d say that from my point of view, there is no such thing as fully grasping the problem while over-engineering it. I’d categorize that as slightly not grasping the whole problem. The complexity of the solution and the budget for solving the problem are part of the problem, not something separate and distinct. I think I’ve more often seen tangential and imagined problems than people doing the right thing the wrong way. To be fair, it can actually be very hard to know whether a problem is really truly a problem that needs to be solved. Some tangential and imagined problems seem important and real, and you don’t discover until later you needed to solve something else and not the thing you did. Some examples: At a games company, the two mathiest programmers decided we needed to be using geometric algebra instead of matrices. They spent years working on it, and the code infected the rigging and animation and rendering systems, all kinds of things. Most of the programmers had to interface with it, but didn’t know geometric algebra, so it slowed development. It only solved minor issues. One of the claims was we’d have no gimbal lock, but people already solve that with matrices in one or two functions, it’s a non issue. To top it off, the math all got a bit slower, and we had to maintain the matrix math anyway to interface with the hardware and external libraries. At a film company all the programmers decided they were tired of the renderer and they needed to start from scratch because making updates was getting slow and difficult. They scrapped the renderer, started over, and it took many multiples longer than they estimated. When they were done, they had roughly the same complexity and ugliness as before, and making updates didn’t get significantly easier. Some mistakes were made in the rush to rewrite everything. Personally, I built a multi-user whiteboard website, and I over-engineered the rendering and the multi-user undo system, convinced they both needed to be perfect. In the mean time, discovered that very few people care about those things or ever hit corner cases, and I missed the opportunity to write proper integrations with other tools and import/export tools — the things the customers needed in order to adopt my software for their workflows.