Laziness Driven Development

This is not a new idea at all but it is seldom applied. I like to call it “being lazy”. The essence is to identify what is painful and then eliminate the pain. Spend some time each sprint to eliminate pain and see huge productivity improvement.

Here are some examples:

  • It takes a few minute to compile the code, load the binaries to the embedded device, and restart the program. This is done many, many times a day when we are working on the code. The idle time is not enough to work on a different task but is definitely enough to break my chain of thought. Instead, I spent about a day to create a Docker image containing the entire tool chain to compile and run the program. We can now compile the code and run it. No more waiting time.
  • I recently joined a project which has its own source control system different from everyone else in the company. It isn’t integrated with the code review tools so doing code review was a pain. People complained about it but tolerated it anyway because while it was painful, it was not that painful. I, on the other hand, didn’t want the pain at all (see this post where I described a temporarily method to make it less painful). I talked to DevOp and asked for an integration with the code review tools. Now, it is all integrated. No pain at all.
  • When implementing a particular feature, think about what’s the general problem then solve the general problem. Any instances of the general problem can then be trivially solved. This is exactly what libraries do.
Advertisements

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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