Hacker News Reader

Comment by mnm1 | Hacker News Reader

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?

View on HN

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.

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.

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.

It's not, and it cannot ben deployed in increments.

What OP and many people are missing is that a lot of us don't work on cool and hip new apps. Some people aren't in a osition to push incremental changes to a payroll system.

So release for release sake. Push it to production to make the release quota but hide it because it's incomplete and doesn't work. What's the point of that theater?

Reduce the scope of each deployment which results in deployments being predictable and safe.

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.

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.

Reply on news.ycombinator.com