[HN Gopher] I deploy, therefore I am
___________________________________________________________________
I deploy, therefore I am
Author : mrdonbrown
Score : 29 points
Date : 2020-05-14 05:56 UTC (17 hours ago)
(HTM) web link (www.sleuth.io)
(TXT) w3m dump (www.sleuth.io)
| grensley wrote:
| That scoreboard sounds particularly toxic.
| 0xCMP wrote:
| Focusing efforts on smaller+faster deploys (along with some
| measure of deploy quality to weigh those deploys) seems like a
| far better indicator of a team's velocity than simply tickets
| closed.
| mrdonbrown wrote:
| Exactly. Agreed to all the comments that trying to find a
| simple metric for developer productivity is futile, but there
| is value in encouraging people to ship more often, and in doing
| so, ship smaller things that generally have less risk. Also,
| ownership is key here as the person writing the code should be
| the one that pushes it to production and owns its impacts, as
| I've found this results in higher quality, more sense of
| ownership, and quicker incident response and frequency
| reduction.
| derptron wrote:
| I hope this stack ranking tool dies a miserable death.
| mnm1 wrote:
| So if I deploy one critical, long-term project this month and my
| coworkers deploy around ten each say, how does this system know
| that the one thing I deployed was actually more valuable and
| impactful than all those little deploys? Or do I need to deploy
| the unfinished work in progress constantly to keep up the metrics
| because this is just another useless measure like lines of code
| or commits?
| urbleflan wrote:
| This is why cycle time is a much more useful metric. The book
| "Accelerate" shows what a mature conversation around software
| metrics should look like.
|
| EDIT: To be fair, my point may not directly address yours.
| "Value" is still a tough thing to determine.
| asdf21 wrote:
| Exactly. ^
|
| Personally, I like to try to track how many times functions
| have been called (if possible), where bottlenecks are and if
| they make sense (is there some trade-off that necessitated
| them), and overall module usage.
|
| That gives a more generally clear picture of performance.
| mrdonbrown wrote:
| Assuming your project supported continuous development, I'd
| probably say you should break that project up into multiple
| deployments, ideally hidden behind a flag and each easily
| revertable. This would reduce the risk of each step and
| hopefully eliminate a whole host of potential incidents.
| inertiatic wrote:
| How does code hidden behind a flag become less risky if it's
| deployed in increments?
|
| You will only find out when you allow it to run.
| mrdonbrown wrote:
| Well, for example, say you were adding a new preference
| page. First, I'd do a deploy of the new database table(s),
| even though they aren't used. Then, I'd add a link to the
| page in the UI and put that behind a flag, maybe with a
| small non-functional UI so that the designer could play
| with it. Then, I'd implement the basic functionality and
| open it up to my team to start playing with it. Then, I'd
| ship other deploys for things like tests, more edge cases,
| UI tweaks, etc.
|
| At some point in there, I'd open that page up to my beta
| customers, trial customers, or whoever is less risk-
| adverse. Once I'm happy with it, I'd do a percentage
| rollout to ensure any issues don't affect all customers at
| once. Just an example, but the idea is to reduce risk of
| each step and make each step easily reversable/hidden if
| something comes up.
| Ididntdothis wrote:
| I really wish people would stop trying to reduce software
| development to simple metrics. Number of deploys is as
| meaningless as lines of code or number of story points as a
| metric for judging people's performance.
| CameronNemo wrote:
| Management is always looking for shortcuts and ways too avoid
| the difficult job of evaluating people's performance in an
| objective manner. They see scoreboards, and due dates, and
| activity streams as important tools for observability. But what
| they miss out on is the end performance of the actual product,
| and how individuals played a role in improving or worsening
| that performance.
| Ididntdothis wrote:
| It seems all these short term metrics lead to people picking
| the simplest tasks and processing them at high volume. I
| could easily up my story point output by 10x if I picked the
| simplest bugs and stories from the backlog. Instead I take
| the most difficult ones where there often is no output for
| several weeks or longer. Thank god my manger sees the value
| in that. I would hate an environment where my output is
| measured in day or hour increments.
| not_a_moth wrote:
| It does indicate a culture where there aren't massive barriers
| to getting changes in.
|
| I worked at one startup on the AI team, and we were allowed to
| deploy at will, we iterated constantly, pushed multi times a
| day, and had a flat hierarchy. We weren't under the political
| umbrella of the engineering and product groups. It was
| definitely risky but no major issues ever came from it and we
| gained the trust of DevOps team and our CTO.
|
| The back end team, different managers, was very hierarchical,
| had to schedule deploys well in advance and inside certain time
| windows, and non technical engineering managers would monitor
| and send summary emails to everyone after each deploy.
|
| Guess what, that back end team sucked. Their timelines for
| features were embarrassingly long, they watched the clock,
| their managers loved to booze, they overcomplicated the
| architecture and never produced anything innovative for the
| company.
|
| Deploys can signal culture.
| Ididntdothis wrote:
| "Deploys can signal culture."
|
| They can signal culture maybe. But if you tell your back end
| team that you think their culture is bad because of not
| enough deploys they will crank up the number of deploys
| without fixing any of the deeper issues. All metrics like
| number of deploys , tickets closed , story points, number of
| commits are interesting data points but you should never try
| to optimize for them. Doing so signals lazy management that
| likes to beat around the bushes.
| rcfox wrote:
| Deploys is perhaps a good metric for engineers looking at
| managers, but not managers looking at engineers. (And
| definitely not managers looking at managers!)
| majormajor wrote:
| Numbers tell you what is happening, not why it is happening.
|
| If you see interesting numbers, you need to figure out the
| why, before just trying to move the numbers.
| mcny wrote:
| > I really wish people would stop trying to reduce software
| development to simple metrics. Number of deploys is as
| meaningless as lines of code or number of story points as a
| metric for judging people's performance.
|
| I mostly agree. I for one am a big fan of "painless" deploys.
| To me it means we should be able to deploy pretty much when we
| want to...
|
| My manager (also a programmer in previous life) once explained
| to me (privately) is we are neither waterfall nor agile or
| anything like that. We need to first have a repeatable process
| before we can even think about those things. (Officially, we
| were "agile" but that's beyond our pay grade.)
| Ididntdothis wrote:
| "I mostly agree. I for one am a big fan of "painless"
| deploys. To me it means we should be able to deploy pretty
| much when we want to..."
|
| That's a good goal.
| mpoteat wrote:
| As other people have specified in this thread, the underlying
| problem is Goodhart's Law, i.e. these performance tracking
| systems break down when pressure is applied to them.
| jacques_chester wrote:
| There's a difference between "measurement will fail when there
| is poor management" and "measurement will always fail".
|
| But having said that, a _leaderboard_ seems like a handing out
| poor management tokens.
| bluehatbrit wrote:
| There's a reason the execs thinks in terms of revenue, cost, and
| profit. Why would you want your engineers, designers, or anyone
| abstracted away from that? From my experience, every time you try
| to do that you end up with the business and the workforce
| misaligned.
|
| It's not always easy to quantify value, and sometimes the return
| on an investment is slow and that can be unattractive. However,
| that doesn't mean we should try and hide away from figuring out
| the true value of work in business terms.
|
| In my opinion, we should judge the impact and effectiveness on
| the base line metrics as the rest of the org. In a for profit
| company that's measures such as increasing customer spend,
| increasing conversion rates, reducing churn, reducing operational
| costs. All of those measures can be directly tied to revenue,
| costs, and profit. It's the language the business speaks, why
| would you want to speak a different language to the rest of the
| business? More than that, why would you want to start measuring
| performance in a different way to the rest of the business?
___________________________________________________________________
(page generated 2020-05-14 23:00 UTC)