In 2008, Nachiappan Nagappan, E. Michael Maximilien, Thirumalesh Bhat, and Laurie Williams wrote a paper called “Realizing quality improvement through test driven development: results and experiences of four industrial teams“ (PDF link). The abstract:

Test-driven development (TDD) is a software development practice that has been used sporadically for decades. With this practice, a software engineer cycles minute-by-minute between writing failing unit tests and writing implementation code to pass those tests. Test-driven development has recently re-emerged as a critical enabling practice of agile software development methodologies. However, little empirical evidence supports or refutes the utility of this practice in an industrial context. Case studies were conducted with three development teams at Microsoft and one at IBM that have adopted TDD. The results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD.

In 2012, Ruby on Rails development practices assume TDD. I personally rely on tools like rspec for writing tests and mocks, factory_girl for creating objects, capybara for browser automation, simplecov for code coverage and guard for automating these tests.

As a result of using this methodology and these tools, I tend to agree subjectively with Nagappan et al:

• It does take more time to write tests. But a 15-35% increase in time seems excessive. Most tests are short, quick and simple to write. Using mocks and factories helps a lot.
• It takes no time to run them if you use a tool like guard that continuously monitors and runs them as they change. Add growl notifications on the Mac and you only need to pay attention when you see red.
• Tests help me write better code. Because thinking up and executing tests often shows up code defects early, and this is a very good thing. I often find myself writing a function that I think is great, then throw a few additional tests at it and find my logic or execution was flawed.
• My defect rates are much lower, just like Nagappan et al state. I think this is simply due to the use of TDD to identify and catch defects earlier in the process. And I get far fewer bug reports from Beta testers.
• I am no longer afraid to refactor mercilessly. The tests will tell me if the refactor breaks anything. This is probably the most important point. I know that its safe to change code, I know if the change affects other components and I can see where and how it does so, so I can fix it.
• I can trust the code base. No need to tiptoe around API’s or functions. I can trust that calling an API or module will work, and that the tests will tell me if they break. I can trust the work of others because their tests work too.
• I seem to have found, empirically, that writing tests after the fact is just as fine as writing them before. The important thing is to have the tests, and to have good tests, to have tests that go after both expected and unexpected cases, outlier cases, failure modes and are in some cases ridiculous tests.
• It also helps when taking on legacy or other people’s code to spend time writing tests to help you learn that code. Or at least trust that code by testing the components you use.
• Testing for 100% coverage does not seem to be all that worth it. Using my toolkit in Rails, I can test the workflow, UI and all models and business logic. In reality, getting 100% coverage on models and libraries pays off, but the UI and workflow stuff changes so much during development that the tests for that stuff get in the way.
• Adding tests for bugs found is another great way to document not only the bug but your bug checking and fixing process. You know something is wrong when a bug is found, tests can help you to corral it, and then be sure that it never happens again. Tests also ensure that your fix does not break anything else. I often find new bugs by fixing one bug and watching other tests fail.
• I don’t release unless all tests are passing, obviously.
• I also don’t skip testing to meet deadlines. I estimate with tests in mind, I develop with tests in mind. And if I have a deadline, the few minutes more it takes to create and run tests make no significant difference.
• I make no secret that I use this methodology. My clients understand that the small increase in development time pays off handsomely in later iterations, and reduces beta testing and maintenance issues. Based on my experience alone, TDD actually reduces the net time to develop and ship quality software because you don’t spend time later in the project trying to figure out what went wrong.

For many developers, introducing Test Driven Development, is a challenge. You have to explain it to your team, to managers and clients, then find the time to write tests, then find the time to learn how to write good tests, build a process and infrastructure to automate testing, and the payoff is difficult to see until far later in the project timeline. I hope just some of the benefits I have found above help you get there. With TDD, you will make better software, you will be a happier developer and your manager and client will see the benefit in the end.

A woman comes across a man crawling under a street lamp. “I’ve lost my car keys,” he explains.

The woman tries to help the man find his keys. After a few minutes of searching, she asks “Where exactly did you drop them?”

“Down the street, next to my car.”

Puzzled, she asks “Then why aren’t you looking over there?”

“The light is better here.”

People often look where it seems easiest or most convenient to look, rather than in a more difficult, but more correct place. Opinions regarding where the best place to look often comes down to “Where The Light Is Better”.

• Support teams base their knowledge of a software system upon specifications and documentation, rather than observing the actual system in action or examining its source code. Documentation is usually incomplete and out of date.
• Analysts make decisions based upon easy-to-collect metrics, rather than on detailed study of the complexities of a situation. Not enough time to do it right, so find a short cut.
• DBAs prefer that database query logic be written as stored procedures in the database, where they can get at it; whilst developers prefer that it be in the application code, where they can get at it. More convenient location, not necessarily the right location.
• When a bug is found in someone else’s code, developers will generate complex workarounds in their code, rather than trying to get the bug fixed. Either it takes to long to get it fixed, its too hard to fix it yourself or something else may depend on it. Workwround instead of finding out.
• Almost everyone uses a tool they know well to try to solve a problem, even if that tool is poorly suited to that problem, rather than to try and learn an unfamiliar tool that is far better suited for that job. Use your “hammer” tool instead of the right tool. We’ve all see abuses of Excel and Powerpoint, no?
• Architects try to gather existing knowledge informally, through conversations, online forums, and wikis, rather than reading papers and books. More convenient to ask than to learn, see the success of StackExchange.
• Consultants try to gather information on industry practices through reading academic papers, rather than examining real-world work and case-studies. Hoping someone else saw and solved the problem first.

Having alternate places to find and gain knowledge is a good thing. But you need to make sure that the alternate location is referring to the same knowledge. And that you truly understand the problem and solution space. Searching where the light is better does not necessarily mean you are searching where the keys are, where the solution exists.

Expedient is not necessarily efficient.

Rephrased without requesting permission and hoping for forgiveness, from http://c2.com/cgi/wiki?WhereTheLightIsBetter (Last updated November 2004).

The sub-theme this week is on trying to find ways to improve developer happiness and to reduce unpleasant time wasters.

Rafe Colburn in Don’t order your team to work more hours talks about bosses who ask staff to work more hours:

Every time you’re tempted to do so, sit down with members of the team and ask them how many hours a week they spend dealing with stuff not related to shipping and work to make those things go away instead.

David Heinemeier Hansson gets specific in Refusing administrative minutiae, picking on expense reports.

Optimizing your business for happiness is about a lot of things, but taking out all the needless administrative minutiae seems like one of the easiest. Why aren’t you?

Pass these on to your boss.

A brilliant essay by Danielle Fong called Trade Trade Secrets, very worth a read, covers everything from Intellectual Property, to explaining the differences between theft, transcription, transformation and inspiration, to how the law stifles all four of them.

The great danger of laws that ignore these is not that they will prevent theft, but that they will so heavyhandedly prevent transformation and inspiration: the engines of our entire civilization.

Just read it.

Lets see if I understand ACTA, the Anti-Counterfeiting Trade Agreement:

THEM: It’s purpose is to create a legal standard for global intellectual property rights enforcement.
US: Sounds good, it’s all so confusing, consistency may be nice.

THEM: The WTO already has 153 countries signed up to TRIPS which is a legal standard for global intellectual property rights enforcement, ACTA overrides it.
US: Mmmbokaaay, do we need a new deal then?

THEM: It was negotiated by a small group of countries, excluding most countries, governments, trade organizations and any public forums.
US: Negotiated? Excluding most players? Not good.

THEM: It overrides other countries laws and legal systems, forcing them to follow ACTA or lose safe harbor trade protections.
US: Can they do that? Seems they can!

THEM: It was done in secret, even to the point that talking about ACTA was a secret.
US: This is not Fight Club! A secret law. That affects us. WTF?

THEM: We only know about it because if Wikileaks.
US: Phew.

THEM: It has been signed by the USA.
US: Wish we had been consulted first, this is a democracy you know.

THEM: The USA has banned the release of this agreement under National Security laws, which means us poor citizens are subject to laws that we cannot find out about. All Freedom of Information Act requests for this document have been denied.
US: Triple WTF? In what alternate universe does a ripped CD or a fake Gucci bag affect National Security?

THEM: It enables countries to search personal baggage, personal computers, iPods and phones without cause for infringing materials, and to then punish people via fines or confiscation without recourse.
US: What about privacy, human rights, international law, freedom? Could it get any worse!

THEM: It requires countries to share all information related to searches and seizures on private citizens.
US: It just got worse!

THEM: ACTA does not require probable cause to perform a search.
US: What? No rights! Nooooo!

THEM: ACTA does not define what an infringing item is.
US: No definitions! So anything could be claimed as infringing, by anyone, anytime? Great, I hereby claim all iPads to be infringing. Oh, and chocolate too, it may be a fake Cadbury’s.

THEM: ACTA does not explain how border guards are supposed to know the difference between legal and infringing goods.
US: No way! They have to guess? That’s an ugly handbag, lets fine her!

THEM: ACTA does not provide any protection that the search will be restricted to infringing items (they can read your communications under ACTA which is currently and patently illegal under tons of international and national laws, then prosecute you on what they find).
US: That’s bat-shit crazy! It even overrides the USA’s 5th amendment rights? And the USA Government signed it!

THEM: ACTA allows these searches to be performed at the ISP level as well, not just at borders, so it’s global SOPA.
US: Beyond insane! So Slovenia can search my ISP in New York and fine me because they need the cash?

THEM: ACTA offers no due process for notification, charge, or response.
US: Oh, add icing on this shitcake!

From 16–18 June 2010, a conference was held at the Washington College of Law, attended by “over 90 academics, practitioners and public interest organizations from six continents”. Their conclusions were published on 23 June 2010 on the American University Washington College of Law website. They found “that the terms of the publicly released draft of ACTA threaten numerous public interests, including every concern specifically disclaimed by negotiators.” A group of 75+ law professors has signed a letter to President Obama demanding a host of changes to the agreement. The letter alleges that no meaningful transparency has been in evidence.

We stopped SOPA and PIPA, but it may be too late to stop ACTA.

If we define operations as “a piece of organized and concerted activity involving a number of people”, then all businesses consist of a lot of operations. Back offices, accounting groups, processing units, operations departments, call them what you may, there are departments and departments of operations.

In the Automate or Die Hiltmonism, I pointed out the need to automate as much of your process flow as you can. This means tackling operations, its hordes of people, its arcane processes, its political hierarchy and its bureaucratic inertia.

This painful area of business is also where technology really shines if done right. Operations are usually rote, rule based and data intensive, everything that software is good at. Automating operations reduces errors, frees up people to work on value-add processes, improves the flexibility and nimbleness of a business and enables you to pump much more work through the process quicker and using fewer resources.

But operations is also a very messy business, most because it is human based and operations evolve, they are rarely discussed or designed. There are always exceptions to every rule, conventions that are not followed, special cases and odd duck flows that are the result of long ago conversations that still seem necessary to those who perform these tasks. Getting operations people to even agree what the 90% is takes time, patience and an ability to stay on topic.

But, as a developer, if you do get the 90%, then you can automate it. 90% increase in throughput, 90% decrease in errors, 90% less hassle is sure better than none.

So what about the remaining 10%?

You run Operations by Exception.

For the 10% of operations that don’t fit the usual operations flow, catch them early, fail and bust out an exception that explains clearly what is unusual. Pop a list of these on a screen send out an alert. Then let the people deal with it.

Operations staff, instead of having to execute the operations themselves, can now ignore everything but the exceptions. Their workload drops to looking to see if there are any new exceptions to deal with, and then dealing with them, and then moving on to the next one.

Running operations by exception relieves the burden and stresses on staff, reduces tediousness, increases the amount of fun challenging work they do, and ensures that any exceptions are given their full attention and that they get resolved. It allows businesses to grow and expand without much increase in people’s workload, headcount or error rates.

Write operations software that automates 90% of cases, and produces clear exception reports for the remaining 10%. Add components to track and close exceptions, turn it into a game if you must, and get a whole lot more operations done with less.

I switched over to Day One for journaling at the start of the year on a lark, and its become a core part of my process.

Here are three things I do with it:

1. Bread crumb blog posts

I have updated the Octopress rake file for new_post to also bread crumb the new post in Day One (and launch Byword for editing).

Place this at the end of the :new_post task (see below for details on the LogToDayOne.rb script)

1
2
3

  # Log to Day One and open it for editing
  %x{~/scripts/LogtoDayOne.rb "@blog #{title}"}
  %x{open "#{filename}"}

The first line runs the LogToDayOne.rb passing in the blog title. The second line opens the generated markdown file using the default editor (of course Byword is it).

Here it is in Day One:

2. Log all commits

I have created a shell macro to log all git commits such that the project and commit message is also logged to Day One.

In .bash_profile:

1
2
3
4
5
6

function gca(){
  msg=$*
  path=$(pwd)
  ~/scripts/LogtoDayOne.rb "@${path##*/} $msg"
  git commit -am "$msg"
}

Now all I do is type gca "The commit message" and its both logged to Day One and saved in git.

Here it is in Day One:

3. Use the annoying reminders

I have enabled the reminders function in Day One so that 3 times a day, an annoying gray box comes up asking me to journal something. So I do. And its been totally worth it. There is always something to note, something to remember, something to write about. Even though I have only been doing this a month, I can already see a clear journal of my activities in Day One.

The script

Logging commits was not my idea. I got the LogToDayOne.rb script from Brett Terpstra in Logging with Day One, Geek Style - and removed the dependency on chronic since I do not need it and it was conflicting with the RVM in Octopress. I though it was so cool, I added the blog bread crumb myself in Octopress.

The result

As a result of these, I have a comprehensive journal of what happened each day over and above my project and coding notes.

Anyone else got some cool scripts for Day One? I’d love it to become more like Momento for the Mac.

By @macdrifter, Developers, A Love Story.

While browsing my Application folder on my Mac, I noticed something. I have a fondness for some apps that I rarely use. I’m just glad that I own them. I may not use them all but I feel good about the money I’ve spent.

I second the motion.

A classic by James Hague entitled A Spellchecker Used to Be a Major Feat of Software Engineering.

Writing a spellchecker in the mid-1980s was a hard problem. Programmers came up with some impressive data compression methods in response to the spellchecker challenge. Likewise there were some very clever data structures for quickly finding words in a compressed dictionary. This was a problem that could take months of focused effort to work out a solution to.

Reminded me of when I used to program with disk, CPU and memory constraints back before I had gray hair. And how much our tools have progressed since then.

See Also: Things That Turbo Pascal is Smaller Than - it was my first CS language at university.

Rich Siegel, of BBEdit fame, in his blog article Bar Sopa, makes the right point on piracy:

A good way to do this is to make a product for which more people want to pay a fair price than who are willing to steal it.

and

Take the money you would have spent on fighting piracy and use it to make a better product and/or service. Making more laws is not the answer.