paint-brush
Could YOLO Driven Development be a thing?by@corrodedlotus
2,570 reads
2,570 reads

Could YOLO Driven Development be a thing?

by Eumir GasparMarch 21st, 2018
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

I am a very impressionable person. I get LSS (or <a href="https://www.internetslang.com/LSS-meaning-definition.asp" target="_blank">Last Song Syndrome</a>) a LOT. I usually also get to copy a lot of my colleagues’ catch-phrases especially when they say it every day. It might just be me, or it might be a common occurrence in teams, but so far, I have only see it manifest in myself — but I digress.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail

Coin Mentioned

Mention Thumbnail
featured image - Could YOLO Driven Development be a thing?
Eumir Gaspar HackerNoon profile picture

I am a very impressionable person. I get LSS (or Last Song Syndrome) a LOT. I usually also get to copy a lot of my colleagues’ catch-phrases especially when they say it every day. It might just be me, or it might be a common occurrence in teams, but so far, I have only see it manifest in myself — but I digress.

My former colleague, Terence, used the word YOLO in almost all his sentences before. It was a no-brainer that I eventually assimilated it and now I am still saying it. For the sane and uninitiated, it was an overused meme before for things like this:

This is my favorite YOLO gif. It’s just perfect.

Okay. So what does YOLO have to do with anything serious like development or deployment?

It started out as a joke in our team: we were in the verge of releasing something and the tests for master were failing. This was back when we had a twenty minute test suite which had a LOT of acceptance tests that were flaky. And flaky they were: it would sometimes fail thrice in a row with different unrelated errors and then pass the next run. This led to frustration and obviously, less deployments per day.

It was one Friday afternoon and we all wanted to go home but we needed to deploy a feature. We were using the Gitflow Workflow which was basically:

  1. Create feature branch from develop
  2. Work on feature and finish it
  3. Merge into develop
  4. Test in staging
  5. Merge develop into master
  6. Deploy to production
  7. ???
  8. PROFIT!

So, back to the future, I mean feature. We wanted to deploy it, but master kept failing with flaky tests. I suggested that we just ‘YOLO’ it and deploy. It was already merged into master anyway and develop had already passed, which was basically the same code anyway. We all laughed, but we all knew it was true. So we deployed it. Nothing bad happened that day.

Fast forward to recent times. We now have five minute builds, still using Gitflow in our main app, but a simplified Github Flow in our other minor projects: basically skip develop and just merge straight to master once a feature is done.

One morning, we were just randomly talking when someone mentioned we should do a gem or something that was named ‘YOLO’ because I kept saying it too often. Again, I am very impressionable and the YOLO term hasn’t left my body yet. It just rolls in the tongue so nicely!

I then just blurted out: “What about YOLO Driven Development?”. And off we went into just thinking about how it works.

YOLO Driven Development

So sticking to the YOLO principle, it should be based on something reckless but (probably) has great rewards. I mean, it would be bad if you just YOLO’d and you didn’t have any sort of reward, right?

So here are our thoughts on it:

Setup all environments so when someone makes a COMMIT, it will automatically push to master and deploy it to production. No running tests. No staging. Everyone just works on master.

WHAT? Okay that’s just dumb. I’m out.

Wait! Hear us out! Okay. Are you still there? Hope so. Hear us out. Good. Relax.

It DOES sound like a stupid idea, but it just might work. Think about it. It forces everyone in the team to do a lot of checks before committing:

  1. Triple check your code.
  2. Make sure you are not committing anything unrelated (console logs, debuggers, etc.)
  3. REALLY, REALLY think about what you are going to commit (no, please don’t use git add . or worse, git -am "Did something cool". Please)
  4. Run ALL the tests.
  5. Smoke test everything.

It closely resembles currently existing CI/CD workflows, albeit on a riskier and more destructive scale.

Still with me? Now this can REALLY smash something so I don’t suggest just going out there and letting your boss know about the newest fad of deploying stuff. I do think it might be useful in small projects or maybe a modified version can be, instead of auto deploying to production, it should auto-deploy to staging for testing.

Rather tempting isn’t it?

What say you?

Disclaimer: We have not used this in any production workflow and this post has been intended to talk about a joke which could potentially be a good thing. You know, like DOGECoin.