Overengineering can kill a product

Re:Overengineering can kill a product by noisy_boy on Wednesday November 24, 2021 @09:16AM (#29330148)

My new colleague used to wonder about certain things i.e. why is this is done this way, it doesn't make any sense. As I had been there a lot longer, I would share the technical and non-technical background/restrictions we operated with. Eventually when another new colleague joined, he told the guy, "I used to wonder why some parts of the code are setup that way; now that I have the background I can say that if you are wondering about those same things, trust me, there is a reason/background - its not because the people who did it that way were stupid".

[ Parent | on HN ]

Re:Overengineering can kill a product by mgkimsal on Wednesday November 24, 2021 @09:42AM (#29330392)

Occasionally, it is because of that though. If not 'stupid', at least inexperienced. I've had plenty of things I've done that worked, but were, in hindsight, 'stupid' (and have been called out on that). Sometimes, people try to make a lot of post-hoc justifications for a block of code or a data/tech decision that really is, just... 'stupid'. Again, that's more likely down to inexperience than anything else, but not every decision is a 'good' one just because people 'had their reasons'.

Examples

Having a 'user info' table with 190+ boolean columns for 'country' ('US','CA','DE','IT', etc) in case someone wants to indicate they're 'from' two countries.

Joining views on views of joined views which are themselves built on joins of other views is, likely, not a terribly sound data decision. (X: "It worked fine last year - you must have broken something." Me: "well... last year you had 450 users, and now there are 37000 users - this isn't a performant way of doing this". X: "Can't be true - the person who wrote it is a DBA")

[ Parent | on HN ]

Re:Overengineering can kill a product by noisy_boy on Wednesday November 24, 2021 @12:32PM (#29332612)

> Occasionally, it is because of that though. If not 'stupid', at least inexperienced. I've had plenty of things I've done that worked, but were, in hindsight, 'stupid' (and have been called out on that). Sometimes, people try to make a lot of post-hoc justifications for a block of code or a data/tech decision that really is, just... 'stupid'. Again, that's more likely down to inexperience than anything else, but not every decision is a 'good' one just because people 'had their reasons'.

I agree on the point regarding the decision being 'stupid' but in this case it was not because of inexperience. On the contrary, it was because an overruling decision by an experienced manager. So the point is that it is not always technical or due to inexperience (though that does happen) - from what I've seen, it is quite common for such things to happen due to hierarchical/ego/political issues as well.

[ Parent | on HN ]

Re:Overengineering can kill a product by mgkimsal on Wednesday November 24, 2021 @12:52PM (#29332848)

you're not wrong, but there's a whole class of problems that occur outside 'enterprise' structures. Often it's just a lone cowboy building something for a small business, and the business owner have absolutely no way to determine if what's being delivered is 'good' in any meaningful sense.

[ Parent | on HN ]

Re:Overengineering can kill a product by hinkley on Wednesday November 24, 2021 @10:59AM (#29331290)

> Can't be true - the person who wrote it is a DBA

Not for long…

[ Parent | on HN ]

Re:Overengineering can kill a product by mgkimsal on Wednesday November 24, 2021 @11:06AM (#29331370)

heh... well... he was a DBA, and wrote all the application code as well. testing on localhost with 20 sample users, what could possibly go wrong? :)

[ Parent | on HN ]

Re:Overengineering can kill a product by redler on Wednesday November 24, 2021 @11:44AM (#29331933)

The ever-relevant Chesterton’s Fence.

https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence

[ Parent | on HN ]