jasoncwarner / ama

Ask Jason Anything
80 stars 2 forks source link

Test Driven Development #21

Open alexander-beaver opened 4 years ago

alexander-beaver commented 4 years ago

Thank you so much for doing this! I am a high school student who has been struggling to lead a small robotics programming team, and I have learned loads through your responses.

I read through some of your Medium posts (stumbled across it on a Google search), and realized that you answered some of my questions. I think that it answered many of my questions that I originally had.

I do have another question about procedures and test-driven development. Obviously in a production system, having rigid standards and tests to base the projects on is important. However, in my experience, it is difficult to get people to follow programming, write standards, and "code right," especially in the middle of long debugging sprints. How do you create a culture that ensures that all code that is written is not only functional but also viable for long-term use?

jasoncwarner commented 4 years ago

The quickest answer to this question is to make the absolute gold standard process or procedures automatic.

I don't know the original source for all things around the following topic, so forgive me for referencing commercial material, though take a look at the Checklist Manifesto and the principles behind a simple checklist

The gist is, we as humans really want some structure. Maybe not a ton, but more than none.

In software development, I think of the loop. My dev machine all the way to running and operating on code/product/project in production, back to the issue tracker and back to my machine. Abstractly this is obviously the software development lifecycle.

The tighter the loop, the better a process you have. The more automated the loop, the more likely it is to be followed. The faster it all happens, the better a company you have.

There's a great report called the State of DevOps (2019). In it it talks about practices that lead to better business outcomes. We should not treat them as causation, more correlation, though even so, useful. A big take away in it is that If you are a better business, you typically have invested in your workflows, specifically automated builds, deployments etc. And if you are poorly performing business, you likely haven't etc. Again, not causation, more correlation.

I have two I care about and recommend people look at entirely:

Number of releases per day.

MTTR - Mean time to Recovery

But here's the thing. It's NOT that those matter, it's that if you are able to safely release more often per day, it's highly likely you have invested in the things that will make you a good business. And if you can very quickly, easily and automatically recover and respond to incidents/faults in production, you likely have invested in those things that will make you a good business.

So....here's the main point in a probably longer than you expected response: Automate nearly everything. Your goal is to speed with safety. Safety at speed. Automation will do this. Nearly nothing should be manual. Leverage all the tools that exist in the world for this.

If you look at why Heroku and GitHub had any success it's that they hid the hard and ugly bits, made things easy, and automated most of it. Heroku in particular had this from the beginning and now GitHub with GitHub Actions does this from your repo all the way to production with everything in between.

So, in closing: invest in your workflows, automate them, and make it so people don't have to remember steps or things along the way.