Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When deployments are easy, code becomes simpler

bitbytebit.substack.com

Post reply on HN
Print view View original

11–20 of 124 posts

Re: When deployments are easy, code becomes simpler

#11

Post by catchnear4321 »

digging wrote: post #9
smokel wrote: post #8

I have recently seen someone wrap a single function in about 10 classes of Java to turn it into a standalone application, slap on some Docker Compose magic, add some build scripts, and then continue to look proud at the feature being wholly configurable at deployment time. Of course, the deployment team would have to be informed about this change, so some documentation was required as well, but that was exactly the p…

> My cynicism is probably not the best approach to change the world for the better, so any hint on how to teach younger colleagues to stop snacking micro service candy is much appreciated. I could be way off base here, but I'd bet a lot of junior devs are just trying to stand out. They want respect, raises, promotions, and new job offers. Invisible good solutions don't bring those.

junior devs are junior devs in part because they do not yet know that there is no guarantee that anyone else has been keeping track of their victories come review time.

solutions are only invisible due to a lack of sufficient documentation and communication.

boring solutions are part of the job. they can be fun if the goal is shifted from implementing to automating.

none of this to say you are wrong, but a junior dev that succeeds at such peacocking efforts is signaling the poor health of their surrounding team as much as their eagerness to impress. where was the manager or senior dev to say “great! have you considered a boolean?”

Re: When deployments are easy, code becomes simpler

#12

Post by GrinningFool »

teeray wrote: post #3

Anyone have advice for teams without control over when their software is deployed by the people actually running it? Say you have a product released to a third party and they may or may not take releases and may be arbitrarily delayed in deploying those they choose to take.

You're in a for a long tail of pain if you have significant uptake.

To avoid this, you will need have a clear policy on what you're willing to support (eg versions up to 1 year old, or "major version - 1", etc.), and stick to it. Otherwise, people will expect you to support all of it, forever.

Re: When deployments are easy, code becomes simpler

#14

Post by kdmccormick »

digging wrote: post #9
smokel wrote: post #8

I have recently seen someone wrap a single function in about 10 classes of Java to turn it into a standalone application, slap on some Docker Compose magic, add some build scripts, and then continue to look proud at the feature being wholly configurable at deployment time. Of course, the deployment team would have to be informed about this change, so some documentation was required as well, but that was exactly the p…

> My cynicism is probably not the best approach to change the world for the better, so any hint on how to teach younger colleagues to stop snacking micro service candy is much appreciated. I could be way off base here, but I'd bet a lot of junior devs are just trying to stand out. They want respect, raises, promotions, and new job offers. Invisible good solutions don't bring those.

Seems cynical. In my experience, junior devs are just more susceptible to cargo-culting and getting excited about cool ways to apply the things they learned in undergrad. I haven't actually seen a lot of "resume-driven development" in my (relatively limited) time in the industry... just well-intentioned eager people with more knowledge than wisdom.

Re: When deployments are easy, code becomes simpler

#15

Post by chiefalchemist »

kdmccormick wrote: post #14
digging wrote: post #9

Earlier quoted context omitted.

> My cynicism is probably not the best approach to change the world for the better, so any hint on how to teach younger colleagues to stop snacking micro service candy is much appreciated. I could be way off base here, but I'd bet a lot of junior devs are just trying to stand out. They want respect, raises, promotions, and new job offers. Invisible good solutions don't bring those.

Seems cynical. In my experience, junior devs are just more susceptible to cargo-culting and getting excited about cool ways to apply the things they learned in undergrad. I haven't actually seen a lot of "resume-driven development" in my (relatively limited) time in the industry... just well-intentioned eager people with more knowledge than wisdom.

> just well-intentioned eager people with more knowledge than wisdom.

Yup. And that by definition is a junior colleague ;)

Re: When deployments are easy, code becomes simpler

#16

Post by GauntletWizard »

teeray wrote: post #3

Anyone have advice for teams without control over when their software is deployed by the people actually running it? Say you have a product released to a third party and they may or may not take releases and may be arbitrarily delayed in deploying those they choose to take.

Give yourself as much leverage as you can get over their deployment cycles. Use both carrot and stick - Include features they can't live without with the hardest of deployment maintenance burdens, and make sure you have tight adherence to your software lifecycle - Every question about 1.0 should be answered with "We don't know, 1.0 is out of support" from the second that it's EOL date passes.

Include the currently running version in every logfile, if not every log statement. Make it clear to you where they are and run your own run-behind that upgrades only after they do. This will be painful, but it will save you overall time.

Re: When deployments are easy, code becomes simpler

#17

Post by mvdtnz »

bsima wrote: post #4

> I did an inventory of my recent feature flags and realized that about 80% of them aren’t there to roll things out to specific populations, or do any sort of A/B testing, but to hide unfinished code. Maybe it’s just me but having unfinished, dead, or scratch code in a production codebase really annoys me. Either finish your work or delete the unneeded code. More than a few times I’ve sunk time out of my day into inv…

I'd rather have unfinished feature flagged code in master (and therefore production) than have the same unfinished code withering in a long running branch, diverging from master and causing integration problems later.

> Either finish your work or delete the unneeded code.

It's work in progress. We're working on getting it finished.

Re: When deployments are easy, code becomes simpler

#18

Post by rvrs »

mvdtnz wrote: post #17
bsima wrote: post #4

> I did an inventory of my recent feature flags and realized that about 80% of them aren’t there to roll things out to specific populations, or do any sort of A/B testing, but to hide unfinished code. Maybe it’s just me but having unfinished, dead, or scratch code in a production codebase really annoys me. Either finish your work or delete the unneeded code. More than a few times I’ve sunk time out of my day into inv…

I'd rather have unfinished feature flagged code in master (and therefore production) than have the same unfinished code withering in a long running branch, diverging from master and causing integration problems later. > Either finish your work or delete the unneeded code. It's work in progress. We're working on getting it finished.

>It's work in progress. We're working on getting it finished.

So finish it and then I will merge your PR ;) What's the use of putting it in master if it's not finished?

It's the author's responsibility to get it merged successfully. If they're taking too long and have to rebase and re-work their code to integrate, that's on them. Pushing it into master is either wasting a reader's time (per the original comment) or, worse, inviting an uninitiated collaborator to use it and cause an incident.

Re: When deployments are easy, code becomes simpler

#19

Post by hinkley »

perlgeek wrote: post #7

Feature flags give you orthogonality. When you have an `if False:` or equivalent in code, you have to deploy to enable a new feature, so if the current state in the test environment isn't good, you either have to wait for it to be fixed, or to roll back all possibly bad new commits before you can enable the feature. Another feature of feature flags is that a non-coder can toggle them. If you need neither of these, su…

When you're trying to triage a production problem or explain what happened between Saturday and today, orthogonality isn't a feature, it's a challenge to be overcome.

Re: When deployments are easy, code becomes simpler

#20

Post by hinkley »

GrinningFool wrote: post #12
teeray wrote: post #3

Anyone have advice for teams without control over when their software is deployed by the people actually running it? Say you have a product released to a third party and they may or may not take releases and may be arbitrarily delayed in deploying those they choose to take.

You're in a for a long tail of pain if you have significant uptake. To avoid this, you will need have a clear policy on what you're willing to support (eg versions up to 1 year old, or "major version - 1", etc.), and stick to it. Otherwise, people will expect you to support all of it, forever.

Bug fix releases never get deployed.

If you want people to keep up to date with your releases, you either have to provide an automatic update facility that they have to manually turn off (ugh, too hard), or you have to dangle desirable features as carrots in front of them, so that upgrading is exciting instead of a social obligation.

Post reply on HN