Skip to main content

Just good enough or why TDD should be dead

It's Thanksgiving 2014 and we've returned home after a nice family Thanksgiving dinner. The icing on the cake was the recollection of the Vietnam era Soviet Union and how that story could have meaning on the modern view of TDD and other types of software testing and development. While the stories were wonderful to hear I cannot do the storytelling justice so I'll limit my comments to the learnings except to say that the storyteller was an engineer which included working for the old Soviet space program and other agencies.

When we talked about the space program he verbalized something that UX designers already know. Keep is simple. But what UX designers don't appreciate is that simple also means few moving parts or the second layer of simple in the actual implementation.  As he described it when you're out there in space you do not have time to be distracted by bad interfaces. And things have to be simple to prevent the number of potential points of failure.

The conversation shifted to what I have always referred to as "good enough". When US planes were shot down in Vietnam they would be recovered and reverse engineered by Russian engineers. Oddly enough they discovered that the planes were constructed to be "good enough". It was said that US designers knew that the planes would eventually fail; either by stresses they were performing under or because the enemy would shoot them down.  In either case there was no point in over-engineering them for the long run. They had to be "good enough". One specific example was the size of the bearings used on a particular component. In the US version the bearing was just a few mm and in the Soviet version they were much bigger. The smaller bearings were easier to manufacture but had a shorter life.

As I look back on my career I see moments when I was designing systems that I intended to live forever and others that were only going to run for a few years before they were replaced. One perfect example is a pair of payment gateways.  The first system was implemented in the erlang programming language. I had great hopes for the project based on the capabilities of the language and for the most part it has lived up to that potential, however, [a] it took a lot longer to write the gateway and [b] while gateway is bulletproof it's been so long that I don't think I could make changes to it if I wanted to. Having the maturity to know what is good enough is contrary to what we are taught in school and when we learn early in our careers. Making that right decisions is non-trivial. Most software is replaced after a few years so there is no point in write something that could live for years.

So what I've learned is that I/we need to keep things [i] simple, [ii] good enough, and [iii] that simple and good enough also means that the testing can also be limited to that which supports simple and good enough. So the next time you're thinking of implement tens of thousands of test cases meant to produce 100% code coverage consider that your project might not need all of them and that simple things only need simple tests.

Comments

Popular posts from this blog

Entry level cost for CoreOS+Tectonic

CoreOS and Tectonic start their pricing at 10 servers. Managed CoreOS starts at $1000 per month for those first 10 servers and Tectonic is $5000 for the same 10 servers. Annualized that is $85K or at least one employee depending on your market. As a single employee company I'd rather hire the employee. Specially since I only have 3 servers.

The pricing is biased toward the largest servers with the largest capacities; my dual core 32GB i5 IntelNuc can never be mistaken for a 96-CPU dual or quad core DELL

If CoreOS does not figure out a different barrier of entry they are going to follow the Borland path to obscurity.

UPDATE 2017-10-30: With gratitude the CoreOS team has provided updated information on their pricing, however, I stand by my conclusion that the effective cost is lower when you deploy monster machines. The cost per node of my 1 CPU Intel NUC is the same as a 96 CPU server when you get beyond 10 nodes. I'll also reiterate that while my pricing notes are not currently…

eGalax touch on default Ubuntu 14.04.2 LTS

I have not had success with the touch drivers as yet.  The touch works and evtest also seems to report events, however, I have noticed that the button click is not working and no matter what I do xinput refuses to configure the buttons correctly.  When I downgraded to ubuntu 10.04 LTS everything sort of worked... there must have been something in the kermel as 10.04 was in the 2.6 kernel and 4.04 is in the 3.x branch.

One thing ... all of the documentation pointed to the wrong website or one in Taiwanese. I was finally able to locate the drivers again: http://www.eeti.com.tw/drivers_Linux.html (it would have been nice if they provided the install instructions in text rather than PDF)
Please open the document "EETI_eGTouch_Programming_Guide" under the Guide directory, and follow the Guidline to install driver.
download the appropriate versionunzip the fileread the programming manual And from that I'm distilling to the following: execute the setup.sh answer all of the questio…

Prometheus vs Bosun

In conclusion... while Bosun(B) is still not the ideal monitoring system neither is Prometheus(P).

TL;DR;

I am running Bosun in a Docker container hosted on CoreOS. Fleet service/unit files keep it running. However in once case I have experienced at least one severe crash as a result of a disk full condition. That it is implemented as part golang, java and python is an annoyance. The MIT license is about the only good thing.

I am trying to integrate Prometheus into my pipeline but losing steam fast. The Prometheus design seems to desire that you integrate your own cache inside your application and then allow the server to scrape the data, however, if the interval between scrapes is shorter than the longest transient session of your application then you need a gateway. A place to shuttle your data that will be a little more persistent.

(1) storing the data in my application might get me started more quickly
(2) getting the server to pull the data might be more secure
(3) using a push g…