3 ms·

There seems to be a bit of a false dichotomy underpinning this article that companies value feature growth above all else and this directly results in poor oper

There seems to be a bit of a false dichotomy underpinning this article that companies value feature growth above all else and this directly results in poor operational performance. However, you can get terrible availability without delivering any features whatsoever for months and months. Two 9s of availability? Half the customers I've had would be ecstatic to have even ONE 9 of availability. And those guys hardly ever ship any code due to how encumbered developers typically are in those places and release maybe once every 6 months to a year perhaps. In fact, this is basically my typical experience with most enterprise customers I've worked with as a consultant - they're unable to execute almost anything materially important and customers put up with them because nobody else is in that niche enterprise market that's keeping people employed by lack of choice / market consolidation (healthcare.gov is just a visible example - plenty more projects are even worse with perhaps even larger budgets with zero media attention).

antrix 11y ago
> And those guys hardly ever ship any code due to how encumbered developers typically are in those places and release maybe once every 6 months to a year perhaps. I've worked in places where some teams ship with this three or six month frequency. They consider it completely normal and find ideas like continuously delivery or even weekly deployments as not just abnormal but risky and irresponsible! This is the very point OP is trying to make, the _normalization of deviance_.
- devonkim 11y ago
  I agree with you plenty that this shouldn't be acceptable, but most of the people I've seen that are against modern practices of decent software teams are not so much examples of the points in this article as much as stereotypical examples of one's grandparents or parents trying to tell you how your job doesn't matter because software isn't "real work" and that their principles work just fine today as it did in the 70s. Or they expect that continuous delivery / CI is a product or feature of something else they bought for 9+ figures and that it's something that you bundle in with services and a license cost because that's literally all they know as how to make anything happen. Doing software projects with people that have more experience in medieval architecture would be probably more pleasant and productive than dealing with leadership that have decades of experience doing nothing but big company projects with more resources spent on planning software than on engineering talent. If a company is hell-bent on focusing for development and new features over stability / security, that's something that can be fixed by leadership - I've worked with plenty of companies that turned themselves around and have wise leaders that know that it's time to spend the resources to do spring cleaning while trying to keep existing employees excited by feature development happy.

antrix 11y ago

> And those guys hardly ever ship any code due to how encumbered developers typically are in those places and release maybe once every 6 months to a year perhaps. I've worked in places where some teams ship with this three or six month frequency. They consider it completely normal and find ideas like continuously delivery or even weekly deployments as not just abnormal but risky and irresponsible! This is the very point OP is trying to make, the _normalization of deviance_.

devonkim 11y ago
I agree with you plenty that this shouldn't be acceptable, but most of the people I've seen that are against modern practices of decent software teams are not so much examples of the points in this article as much as stereotypical examples of one's grandparents or parents trying to tell you how your job doesn't matter because software isn't "real work" and that their principles work just fine today as it did in the 70s. Or they expect that continuous delivery / CI is a product or feature of something else they bought for 9+ figures and that it's something that you bundle in with services and a license cost because that's literally all they know as how to make anything happen. Doing software projects with people that have more experience in medieval architecture would be probably more pleasant and productive than dealing with leadership that have decades of experience doing nothing but big company projects with more resources spent on planning software than on engineering talent. If a company is hell-bent on focusing for development and new features over stability / security, that's something that can be fixed by leadership - I've worked with plenty of companies that turned themselves around and have wise leaders that know that it's time to spend the resources to do spring cleaning while trying to keep existing employees excited by feature development happy.