Building the Habits That Lead to Quality

I’ve read in several places about the strategy of forming habits. That you have to do the same thing for 30 days in a row to start to form the habit of doing the thing all the time. And that takes discipline to do that thing consistently to form that habit.

I’ve talked about this a lot before (I call it engineering discipline) but a lot of the base principles to producing quality software is the attention to detail. Consistent quality software is a development lifecycle that includes the authoring and running of unit tests, and fixing the defects identified. It is taking the intentional time in your sprints to do things like load testing to ensure your performance and scalability are there. It is taking the intentional time in your sprints to author good comments, deployment guides, troubleshooting manuals, and operations runbooks for when the software is pushed to production. Doing all these things takes discipline, but this is even more so when you are not in the habit of doing it.

This is important due to the principle of functional decomposition. It might seem like you don’t have the energy or motivation to have attention to detail on all the “small, unimportant” tasks because you are saving that enthusiasm and time for the “big, important tasks”. But this all snaps into focus once you realize a big, important task is actually just a bunch of small tasks combined! Once you realize that all those small tasks are a part of the whole, you realize that focusing on the small tasks is the same as focusing on the one big task.

For example, you didn’t want to worry about performing the load tests because you were focused on the flashy business feature, and there wasn’t any sort of performance requirement in the specification. Well, what happens when the webapp suddenly gets popular and important and cannot scale to handle the growth?

Or you didn’t want to worry about updating the architecture diagram because it just didn’t seem important, but suddenly there’s a production outage and the ops team is unable to understand the dependencies. Or another development team wants to integrate or build on your product but their efforts are hampered because they don’t know the dataflows?

Building quality into your engineering output is about attention to detail, and the key to having consistent quality is to build the habits of adhering to that attention to detail, such that it just becomes part of your typical workflow. This culture change can elevate your teams and their projects to the next level of producing excellence in their work.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s