4 ms·

Now imagine being on call for someone else's code! That's ops. Unless your company has a very strong relationship between ops and devs, the ops side gets stuck

by nijave 5y ago

Now imagine being on call for someone else's code! That's ops. Unless your company has a very strong relationship between ops and devs, the ops side gets stuck supporting whatever the developer side creates and the developer side is incentivized to jam as many features into code as quickly as possible. It's very expensive and customer impactful when you find issues in production versus prevent them in the first place with code that's a little more "runnable" (like testable code, I'm also convinced there's "runnable" or "operable" code)

sdevonoes 5y ago
"Move fast and break things" is the mantra of many of the startups out there. If only companies realise that pushing features to production like there is no tomorrow is NOT the way to go.
- Lutger 5y ago
  That's just the ops side of the fence being talked about here. The other side is having endless gating, change advisory boards, batching up work, gruesome change approval processes etc. that the ops protect themselves with against development, which now grinds to a halt. This will not only make the business slow to a halt, ironically it will also produce more errors. The really productive companies that deliver fast, are also way more robust.
fatnoah 5y ago
>Unless your company has a very strong relationship between ops and devs, the ops side gets stuck supporting whatever the developer side creates and the developer side is incentivized to jam as many features into code as quickly as possible. >like testable code, I'm also convinced there's "runnable" or "operable" code 1000% this. For me, this has been a huge focus in my past startup lives. Software and infrastructure are very related. Infra design impacts software design and vice versa. By working closely together, it's possible to try to get the best of both worlds. As a VP Eng, I expended a lot of political capital with my "why aren't you building more features" CEO boss so that my dev team could focus on significantly enhancing the stability and observability of our platform, including ensuring our log messages were informative and at the appropriate level. i.e. CRITICAL = Fix Now, ERROR = someone should check into this at earliest convenience, INFO = here's how things are generally running. Stability saved everyone time and effort, and observability allowed (and empowered) the ops team to efficiently triage, and let Engineers quickly understand what's going on and how to fix it when things went wrong. The net result was multiple nightly on-call alerts for Engineers dwindling to "I can't remember the last one" and ops folks were able to focus far more on infra than triaging software alerts. It was a battle and I had to fight to make it happen, and even have my teams "ninja" a bunch of the work via an 18 month inside-out refactor of the codebase, but the result was 200% worth it. The cherry on top was the two full-day grilling by tech leaders during due-diligence during our acquisition. They dug deep into the operational aspects of the business and came away very impressed, and that operational maturity (this was a company that highly valued such things) was highlighted as one of two key factors that swayed the decision to acquire.
deleted 5y ago
[deleted]

by nijave 5y ago

sdevonoes 5y ago

"Move fast and break things" is the mantra of many of the startups out there. If only companies realise that pushing features to production like there is no tomorrow is NOT the way to go.

Lutger 5y ago
That's just the ops side of the fence being talked about here. The other side is having endless gating, change advisory boards, batching up work, gruesome change approval processes etc. that the ops protect themselves with against development, which now grinds to a halt. This will not only make the business slow to a halt, ironically it will also produce more errors. The really productive companies that deliver fast, are also way more robust.

fatnoah 5y ago

>Unless your company has a very strong relationship between ops and devs, the ops side gets stuck supporting whatever the developer side creates and the developer side is incentivized to jam as many features into code as quickly as possible. >like testable code, I'm also convinced there's "runnable" or "operable" code 1000% this. For me, this has been a huge focus in my past startup lives. Software and infrastructure are very related. Infra design impacts software design and vice versa. By working closely together, it's possible to try to get the best of both worlds. As a VP Eng, I expended a lot of political capital with my "why aren't you building more features" CEO boss so that my dev team could focus on significantly enhancing the stability and observability of our platform, including ensuring our log messages were informative and at the appropriate level. i.e. CRITICAL = Fix Now, ERROR = someone should check into this at earliest convenience, INFO = here's how things are generally running. Stability saved everyone time and effort, and observability allowed (and empowered) the ops team to efficiently triage, and let Engineers quickly understand what's going on and how to fix it when things went wrong. The net result was multiple nightly on-call alerts for Engineers dwindling to "I can't remember the last one" and ops folks were able to focus far more on infra than triaging software alerts. It was a battle and I had to fight to make it happen, and even have my teams "ninja" a bunch of the work via an 18 month inside-out refactor of the codebase, but the result was 200% worth it. The cherry on top was the two full-day grilling by tech leaders during due-diligence during our acquisition. They dug deep into the operational aspects of the business and came away very impressed, and that operational maturity (this was a company that highly valued such things) was highlighted as one of two key factors that swayed the decision to acquire.

deleted 5y ago

[deleted]