Skip to main content

Weight Loss Gimmicks And TDD: Buyer Beware

There is no one product used alone that will enable you to lose weight. Just like there is no one development practice that will help you attain high quality software.

You might see on TV an add for some piece of equipment, say something called the Ab Master 3000 (completely just made that up, may or may not exist). The company selling said product might promote it by showing an extremely fit person, with a tag line "you can get these amazing results by using the Ab Master 3000 for 30 minutes a day".

They aren't lying to you, you could get the amazing results such as six pack abs. But unless you have a proper diet and exercise regiment, and the will power and persistence to keep at it long enough to get your percentage body fat low enough to be able to see these results. For those who buy this product and only use that product and nothing more, they won't see the results the are picturing.

The same thing applies to software development practices such as TDD. A TDD evangelist might tell you that you can write high quality software with less bugs at a steady pace if you use TDD. Or you can safely refactor your code base because the tests written give you the confidence to do so. TDD may work for you, and you may see some of the benefits claimed. But unless you have good software design skills, no one technical practice will help you write high quality code. You can't TDD your way to high quality, if you don't already know what high quality looks like.

The people who do well using weight loss products use them only a small fraction compared to everything else they did to lose the weight. They eat smaller meals more frequently. They drink lots of water. They take care to choose the right nutrients to consume. They treat food as fuel. They have the discipline to exercise even when they don't feel up to it. And they know why they do the things they do, and how they contribute to their weight loss.

Similarly, developers who do well with TDD probably already know how to write high quality code. They've been writing code for years, and most likely have worked with other really good developers. They spent thousands of hours honing their craft. They are voracious readers. They probably speak at conferences, and write blogs posts. They attend meetups. They debate with other developers. They've worked with legacy code and know the nightmares of not having sound technical practices. TDD works for them because they make it work for them, just like they could make any technical practice work for them.

Losing weight and writing great code both require knowledge, determination, persistence, and experience to accomplish. Those who have done either know that there is no one thing to get the results you want over the long haul.

Buyer beware.


Popular posts from this blog

Basic Web Performance Testing With JMeter and Gatling

Introduction In this post I'll give a quick way to get some basic web performance metrics using both JMeter and Gatling . JMeter is a well known, open source, Java based tool for performance testing. It has a lot of features, and can be a little confusing at first. Scripts (aka Test Plans), are XML documents, edited using the JMeter GUI.  There are lots of options, supports a wide variety of protocols, and produces some OK looking graphs and reports. Gatling is a lesser known tool, but I really like it. It's a Scala based tool, with scripts written in a nice DSL. While the scripts require some basic Scala, they are fairly easy to understand and modify. The output is a nice looking, interactive, HTML page. Metrics   Below are the basic metrics gathered by both JMeter and Gatling . If you are just starting performance testing, these might be a good starting point . Response Time – Difference between time when request was sent and time when response has been fully rec

Generating Java Mixed Mode Flame Graphs

Overview I've seen Brendan Gregg's talk on generating mixed-mode flame graphs  and I wanted to reproduce those flamegraphs for myself. Setting up the tools is a little bit of work, so I wanted to capture those steps. Check out the Java in Flames post on the Netflix blog for more information. I've created github repo ( )  that contains the scripts used to get this going, including a Vagrantfile, and JMeter Test Plan. Here's a flame graph I generated while applying load (via JMeter) to the basic arithmetic Tomcat sample application. All the green stacks are Java code, red stacks are kernel code, and yellow stacks are C++ code. The big green pile on the right is all the Tomcat Java code that's being run. Tools Here's the technologies I used (I'm writing this on a Mac). VirtualBox 5.1.12 Vagrant 1.9.1 bento/ubuntu-16.04 (kernel 4.4.0-38) Tomcat 7.0.68 JMeter 3.1 OpenJDK 8 1.8.111 linux-tools-4.4.0-38 linux-to

Multi Threaded NUnit Tests

Recently I needed to reproduce an Entity Framework deadlock issue. The test needed to run in NUnit, and involved firing off two separate threads. The trouble is that in NUnit, exceptions in threads terminate the parent thread without failing the test. For example, here's a test that starts two threads: the first thread simply logs to the console, while the other thread turfs an exception. What I expected was that this test should fail. However, the test actually passes. readonly ThreadStart[] delegates = { () => { Console.WriteLine("Nothing to see here"); }, () => { throw new InvalidOperationException("Blow up"); } }; [Test] public void SimpleMultiThreading() { var threads = delegates.Select(d => new Thread(d)).ToList(); foreach (var t in threads) { t.Start(); } foreach (var t in threads) { t.Join(); } } Peter Provost posted an article that describes how to make this test fail. It