3 ms·

Woah my experience is completely different. I've never seen a product fail because of poor engineering practices. And I've seen plenty fail because of busines

Woah my experience is completely different. I've never seen a product fail because of poor engineering practices. And I've seen plenty fail because of business issues. I've worked mostly on enterprise software, many of which had awful code bases but we're wildly profitable.

hinkley 7y ago
My best bosses and I think every mentor I've ever had (some were both) talked about what they value, where they want us to be, instead of micromanaging us on how to get there. Some business strategies are antagonistic to this sort of work, others are in effect the inverse (as in, doing the exact opposite). I think the saddest 'joke' I tell is that I watched our industry, during the XP era, look at the numbers and decide that most of our problems come in during the requirements phase, and then instead of tackling that problem, we spent the next twenty years making sure our side of the house was in order (didn't work out that great, did it?). Why did we do that? Did we think we were going to shame our business complements into doing better? Some of these positions actively seek out people who don't experience shame the way the rest of us do. In theory, XP's theory in particular, fast iterations split up the business decisions over a long time, so the wreck happens in slow motion and more intervention, talking, and concrete examples are available to improve the quality of dialog. Then Scrum gets co-opted by the business people, and now the business side does, indeed, have more time to think, and what have they done with that time? Found ways to give the developers less time to think. Oops.
muse900 7y ago
I'll agree with you on that. Take PHP as an example. I'd say from a technical perspective not many people would go with it from a technical standpoint but we can't ignore that massive companies like FB for example were build on that (no matter if they grew out of it at a later date).
deleted 7y ago
[deleted]
username90 7y ago
> I've never seen a product fail because of poor engineering practices. I've seen plenty of things fail due to extremely high costs to develop basic features with few enough bugs to satisfy customers. That is mostly the result of bad engineering practices, like choosing C++ instead of PHP for your web servers, or just plainly having bad engineers who don't know how to build a big project.
ivanhoe 7y ago
What kills those products is not the bad code itself, it's the side-effects piling up: added dev expanses, lagging behind the competition in adding new features, performance problems as app grows, etc. Badly written code is simply more expensive to maintain and improve. I guess it's less of an issue if you have a very profitable product and/or enterprise clients who are much more tolerable to things like the simplest customization taking weeks to finish, integrations that are complicated and cost thousands and thousands of dollars, etc. For startups and smaller businesses that are tight on dev budgets it's much bigger of an issue.

hinkley 7y ago

My best bosses and I think every mentor I've ever had (some were both) talked about what they value, where they want us to be, instead of micromanaging us on how to get there. Some business strategies are antagonistic to this sort of work, others are in effect the inverse (as in, doing the exact opposite). I think the saddest 'joke' I tell is that I watched our industry, during the XP era, look at the numbers and decide that most of our problems come in during the requirements phase, and then instead of tackling that problem, we spent the next twenty years making sure our side of the house was in order (didn't work out that great, did it?). Why did we do that? Did we think we were going to shame our business complements into doing better? Some of these positions actively seek out people who don't experience shame the way the rest of us do. In theory, XP's theory in particular, fast iterations split up the business decisions over a long time, so the wreck happens in slow motion and more intervention, talking, and concrete examples are available to improve the quality of dialog. Then Scrum gets co-opted by the business people, and now the business side does, indeed, have more time to think, and what have they done with that time? Found ways to give the developers less time to think. Oops.

muse900 7y ago

I'll agree with you on that. Take PHP as an example. I'd say from a technical perspective not many people would go with it from a technical standpoint but we can't ignore that massive companies like FB for example were build on that (no matter if they grew out of it at a later date).

deleted 7y ago

[deleted]

username90 7y ago

> I've never seen a product fail because of poor engineering practices. I've seen plenty of things fail due to extremely high costs to develop basic features with few enough bugs to satisfy customers. That is mostly the result of bad engineering practices, like choosing C++ instead of PHP for your web servers, or just plainly having bad engineers who don't know how to build a big project.

ivanhoe 7y ago

What kills those products is not the bad code itself, it's the side-effects piling up: added dev expanses, lagging behind the competition in adding new features, performance problems as app grows, etc. Badly written code is simply more expensive to maintain and improve. I guess it's less of an issue if you have a very profitable product and/or enterprise clients who are much more tolerable to things like the simplest customization taking weeks to finish, integrations that are complicated and cost thousands and thousands of dollars, etc. For startups and smaller businesses that are tight on dev budgets it's much bigger of an issue.