From, with love.
Subscribe now

Defining "Done"

Hi everyone,

After a couple of years at Yahoo, my manager pulled me aside and said he really liked the way I went about my work. I gave good estimates, my work was typically done on time, and there were usually very few bugs once shipped. He asked me if I would help teach the rest of the team how to work like I do. I hadn't realized I was doing anything different than anyone else, but my manager had pointed out an important distinction: my definition of "done" was different from a lot of other people's.

Most will say that code is done when it has shipped. Most timing estimates focus on when something is pushed to production and users are able to interact with it. However, everything has bugs when first released, so can you really say the code is done if you're still fixing bugs week after week? That bug fixing prevents you from moving on to your next task and will push back all further tasks. Is that really done?

I believe that code is done when you no longer have to make changes to it (outside of enhancements). This might seem like a dream given today's agile methodologies, but it is possible. Keeping your files small and focused on specific tasks is a good way to create a bunch of code that doesn't need to be touched. Your goal in writing software is to move as much code as possible into this state of done. The less code that changes, the fewer bugs introduced.

So I'd encourage you to take more time up front for the development phase of your work. Adjust your estimates accordingly. Planning for one month of development but spending six months fixing bugs means it takes seven months for the code to be done; if you instead take some more upfront time and maybe use two months of planning and development, you might end up spending only two months fixing bugs (only four months for the code to be done). There are few managers who would argue with those results.

This is the software equivalent of the old addage, "measure twice, cut once." The more upfront planning you can do for your work, the fewer bugs you'll face when going to production, and the faster your code can reach "done."

Be well.

JavaScript WeeklySponsor: The O’Reilly Fluent Conference
Subscribers receive $200+ off with discount code NCZ20 (extended until 12/31)

Recommended Links

The importance of import and export (slides)
ECMAScript 6 modules are much more than syntactic sugar for CommonJS or AMD modules. In this set of slides, learn how ES6 modules solve a bunch of problems that other module systems are unable to. There's also a video of the talk.

ally.js (JavaScript Library)
Accessibility is something that doesn't get nearly enough attention in web development, so I'm always happy to see tools that make it easier. ally.js is a small JavaScript library that helps manage focus on DOM elements. Focus management is extremely important for making accessible web applications, and this library helps solve a lot of the more difficult problems (including cross-browser focus differences).

I turned off JavaScript for a whole week and it was glorious (article)
What would happen if you started using the Internet without JavaScript? That's what Wired magazine decided to find out. How about faster load times? Less annoying ads? Content sites that let you read the content? And interesting look at how removing JavaScript from the user experience might actually be a better user experience.

Recommended Book

Being Wrong looks at why we make mistakes. No one is correct all of the time, but why do we feel that we are usually right? What processes are at work that cause us to deceive ourselves? This book explores the various ways we can be wrong and the systems that generate those mistakes. Since software developers often chastise each other for being wrong about nearly everything, this is a great read to help you consider other people's viewpoints and how your own might be faulty. You'll gain some insights into why people hold onto beliefs that obviously incorrect and how we can be very unforgiving when people change their mind. 

Recently on NCZOnline

Hidden performance implications of Object.defineProperty()
I've recently been working on a project to port Espree[1], the parser that powers ESLint[2], to use Acorn[3]. In so doing, I ran into an interesting performance problem related Object.defineProperty(). It seems that any call to Object.defineProperty() has a nontrivial negative affect on performance in V8 (both Node.js and Chrome). An investigation led to some...

ECMAScript 6 destructuring gotcha
With all of the new syntax in ECMAScript 6, you're bound to periodically find something that is confusing (likely as you're hunting down an error). Recently, I've seen an uptick in the reporting of a specific type of error as it relates to destructuring assignment[1] using object patterns. Destructuring basics Before you can understand the...

Triggering Jenkins builds by URL
As you might have read not too long ago, I recently moved my site from Wordpress to Jekyll[1]. In so doing, I ended up using Jenkins[2] to periodically build and upload my site to S3. Having a Jenkins instance running turns out to be quite useful for all sorts of tasks and so I've been...


Love this newsletter? Hate it? Have suggestions for how to make it better? When you subscribe to the newsletter, you can just reply to send in feedback.
Copyright © 2015 Nicholas C. Zakas, All rights reserved.

unsubscribe from this list    update subscription preferences