Home » Testing » “Debbie-Done”



A long long time ago, in what seems now like another world, I worked for a company as a Clipper programmer.  While I was there I heard this story about a lady named Debbie.

I was told that Debbie was a programmer who used to work for this company.  Debbie was a lazy programmer.  She worked harder at avoiding work than if she just did the job she was supposed to do.

The ultimate lazy programmer

For example.  Once my boss had stopped by her desk to see how she was progressing on a report she was supposed to be writing:

Debbie: Oh, that’s done.  Here.  Take a look.

The boss looked it over and found an error.  Some of the numbers didn’t match up.

Debbie: Oh, I know what that is.  I can get that fixed right away.

Which she did.  At least that’s what she made everyone believe.

After she left (shortly after this) they found out that she hadn’t even connected to a database to create that report.  The whole report was hard coded.  Every time you ran it, it gave you the same numbers.


The one thing I was told that sticks in my mind the most is that Debbie considered a project “done” if it compiled in linked.  She almost never ran the code.  Or if she did, she certainly didn’t run enough of it, or run it more than to make sure it didn’t crash.  Anyhow, the perception she left is that she only compiled and linked the code.  Today, we’d say all she did was build the project or solution.

But recently, I’ve discovered that many programmers work at the “Debbie-Done” level more than we’d like to admit.

I’ve always thought that programmers wrote code like I do:

  • Write a bit of code. 
  • Build the code.
  • Run the code to see if that change works as expected. 
  • Write a bit more code. 
  • Build the code.
  • Run the code to see if that change works as expected. 
  • Rinse, lather, repeat.

But what I’m discovering is that MANY programmers do not program that way at all.  No, many of them look like some version of “Debbie-Done” programming:

  • Write some code. 
  • Build the project to make sure it will build
  • Write some more code
  • Build the project
  • Rinse, lather, repeat
  • Run the code and “test” all of the changes at once.

The problem with this method is that no one can remember all of the changes they make so, in the end, the code I write tends to be more completely tested than the code that was tested in bulk.  The only difference between this method of development and “Debbie-Done” is the degree of completeness with which each developer is able “test” their code.

Avoid “Debbie-Done” with Test First Development

It is no wonder that many programmers I talk to think that test driven development takes too much time.  Compared to how they are programming, it does.

But think about this.  If you were to code like I do, suddenly writing test for every change you make suddenly makes sense because instead of you running the application and getting to the place that will trigger your code and observing if it will work or not, you can write a test for just the piece of code you are working on and run that each time you want to verify if it is working or not.  Yes, initially, this will take more time.  But over the life of the program, and I would say even over the time span that it takes to initially write the code, writing at least the Unit Test as you are writing the features will actually save you time.  Not only that, you will end up with test you can repeat every time the code is changed.

Even my method of “code, build, test, code, build, test” is “Debbie-Done” compared to writing test for each change as you make the change.


Other post in Testing

Related Post

  • Test Driven SpecificationsTest Driven Specifications Several years ago, long before the community was actively talking about Test Driven Development, I worked for a short time at a company as a “bug fixer.”  That was my role.  They […]
  • TDD Saves Time – A StoryTDD Saves Time – A Story I recently had an experience writing code that proved to me, once again, that using Test Driven Development really is faster than the way I have been working.You will remember a couple […]
  • Limiting Beliefs of ProgrammersLimiting Beliefs of Programmers At the risk of making half of my audience think I’ve gone off the deep end, I’m going to address a topic that I’ve only recently REALLY begun to understand, in part thanks to Soft […]
  • What Not To TestWhat Not To Test Many people believe that implementing Test Driven Development means that you need to have a test for every line of code in your system.  When  they start thinking about TDD in […]
  • 8 Reasons Johnny Does Not Write Bug Free Code8 Reasons Johnny Does Not Write Bug Free Code There have been a number of things that have occurred over the last week that have prompted this particular post.  And for anyone I work with, this is not an indictment of our work place […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer focusing on ASP.NET, C#, Node.js, JavaScript, HTML, CSS, BootStrap, and Angular.JS.Does your team need additional help in any of the above? Contact Dave today.