Always brought up in conversations in delivering, whether it be software, manufacturing, or services is topic of 
quality versus quantity.
When I first started programming, developers skill was measured in the number of lines per day. This was about as useless as a BMI (Body Mass Index) measurement for athletes. I even once had a manager brag about how many lines of code he used to write in a day. I asked him how long the lines were. He didn’t find it funny.
We now often joke about how few lines of code we write and even brag about removing large chunks of code to replace them with smaller routines. This concerns me a bit since shorter isn’t necessarily better.
There are three things that I look for in code and I don’t care how many lines of code are used to achieve this. For that is the right amount. In this case, quality is no longer and opposite of quantity. In fact, quality usually means the right amount of quantity. The three things are as follows:
1) Does the code solve a problem?
2) Is the code easy to understand?
3) Is the code easy to update?
If you use the minimum amount of code that accomplishes these three things, you will have quality and quantity. In fact the quantity and quality of your entire program will reflect good quality and the right quantity. Let’s examine these three things in details to see why.
First of all, you shouldn’t be writing code unless you are trying to solve a problem. Writing code is a last resort due to the time and expense required. The problem may be a bug but it might also be a feature a customer needs, or a hypothesis from marketing about rearranging a page to get more click-throughs. Once code is responsible for making money for our company, it must be treated with appropriate respect and not changed unless necessary. The code needs to solve this problem. This is where most developers used to stop.
Secondly, the code should be readable. I don’t just mean by you tomorrow but by another developer looking at the code for the first time. A code review is a great way to validate this. This means, code well named, in proper order, consistent spacing, no unnecessary comments. If you disagree with any of this, please go argue with Robert C. Martin, James Grenning, Ron Jefferies, Martin Fowler, or one of many others. I met a developer, Amir Barylko recently who referred to spaghetti code as “Write-only code”, because you can’t read it.
Finally, code is never finished. If the code is any good, you’re going to have to update it. If you don’t write it so it can be updated, new features will take increasingly longer to write. Without caring about your code, my experience indicates a heavily used piece of software has a two year life-span. This is because the time to develop keeps increasing as the value of each feature decreases. One reason approaches such as TDD (test driven development) are used by veteran programmers is that they buck this two year issue. Since the software is continually cleaned, you can continually update it. Over time features can be added on with minimal interference by older code because the code is easy to update.
Once again, I have wandered off on a technical path. How can this apply to the human body? The comparison first hit home for me as I was reading The 4 Hour Body by Tim Ferris. Tim spoke of the minimum effective dosage needed. Essentially, why exercise more then was needed to achieve your goal. I immediately thought of Eric Ries talking about MVP (minimum viable product). Furthermore, I thought of how when writing TDD, you only write the minimum to pass the test. Now that the link was in mind, I started mapping the analogy across to see if there were other similarities.
Great quality is not just desirable in code but in our bodies as well. We are always taking medicine and following the latest instructions from doctors on what we should be eating, most, well, some of the time. It seems the same problems that plague code, plague our bodies as well. Yes, I have bragged about how much food I have eaten in sitting. In fact, one of my current rules is not to have thirds. Seconds are going to be eaten but if I can stop before having thirds, I’m doing ok. The threat of quantity haunts me on the plate and on the screen. Many runners, get obsessed with running so much that they injure themselves over preparing for races. I’m sure everyone knows someone who is limping and tells the story of how they over did it at the gym trying to set a new personal best for lifting. It doesn’t have to be like this.
We can use our discipline from code to improve our lives.
Lets look at eating as we compare it to writing code. Let’s start with eating:
1) Does it solve a problem? Well, since it is necessary to eat. It meets survival. But food is more then that. Michael Pollan suggests “Eat food, not too much, mostly plants”. He goes on to clarify what he means by food. One of the interesting thing he says, is that you must eat with someone else for it to be food. We also enjoy eating food and often eat way too much and lots of things “we shouldn’t be eating”. We all know how we feel later about these decisions.
2) Is it easy to understand? Let’s review the foods we ate today. If you read all the ingredient lists, could you pronounce every ingredient? If the foods we eat contain basic foods such as meats, vegetables, fruits, and nuts, our systems have no problem digesting them. Our systems are optimized for these foods. When we eat processed items we are just guessing at the impact on our bodies. Especially in the long term. I’ve also found myself coming up with new ways to describe how I eat. If people understand how you are eating they often start thinking about what they eat. “Maybe I’ll try that”.
3) Is it is easy to update? For me this is updates to my diet during soccer season. By eating natural foods, I find it easy to add on extra carbohydrates in the summer time while I am playing soccer. Can the food you eat, handle different environments, social events and special occasions? We can’t eat the same thing everyday so your diet of choice needs to have some flexibility.
To fully explore this, we should add try applying it to exercise and other life impacting factors. To be continued…
Remember, you are the code.
HumanRefactor 