4 ms·
I work in a publicly traded company. I do everything from requirements elicitation, implementation, unit testing and end-to-end testing, own the deployment proc
by JMTQp8lwXL 7y ago
I work in a publicly traded company. I do everything from requirements elicitation, implementation, unit testing and end-to-end testing, own the deployment process, as well configure logging and monitoring to ensure deployments continue to stay healthy. Our software's reliability is as strong or as brittle as each individual engineer deciding to implement or skip these processes, since most micro-services are made by groups of 2-5 people (and I'm currently a team of 2, and for a few months was a team of 1).
- jungturk 7y agoWould defining a (required) key set of observables not help to reduce the variability across teams? Or perhaps the issue you're describing is that teams aren't required to demonstrate any? In my experience (as a chief architect and engineering VP), laying out some baseline metrics closes much of the reliability variance across teams. As the teams get more competent at baking in the basics (overall load, latency, resource utilization, error rates, error events posted to chat) you can ratchet up the competency to include higher order observables (scaling events, business transactions, circuit statuses, traces, anomalies). Which is to say its been straightforward (in my experience) for most teams to raise the bar once they know there _is_ a bar and once they can see the bar.
- JMTQp8lwXL 7y agoTeams aren't required to demonstrate any. Engineers who understand the importance of quality bake in time, and management is supportive of self-imposed controls. Our NPS numbers are trash, though. But it's a different kind of quality issue: we aren't fighting fires every week. The problem is our API response codes are often wrong or unpredictable. The original engineers clearly did not understand the HTTP protocol.