Author Archives: Dave Copeland

Tie Tuesday – more fun that it sounds

By Dave Copeland in Best Practice, Culture | January 19, 2010
The developers have an informal “Tie Tuesday” each work. It’s exactly what it sounds like. And, since you asked, yes, it is more fun to wear a tie when you don’t have to. Not everyone does it every week, but this week, we had the best participation yet:

When adding more threads makes it all slower

By Dave Copeland in Code | November 16, 2009
I've been working on a new feature that requires analysis of each individual's entire energy-use history. In other words, I have a process that will touch every single bit of data in our database. This should be a rare thing, so if it takes a while, it's not that big of a deal. [...]

Slides on Improving Your Agile Development Process

By Dave Copeland in Code, Development, Workflow | October 29, 2009
Dead last, after the headline act, and after Joel Spolsky told everyone to go home, I did a lightning talk at DC's recent DevDays (A StackOverflow production) on how we have used process metrics from our bug tracker to improve our process. Improving your Agile Process View more documents from David Copeland. Continue reading ...

A year-long analysis of snack consumption

By Dave Copeland in Culture | August 26, 2009
Consistently, month after month, the chips that get left in the giant 'box-o-free-snacks' are: Nacho Cheese Doritos. Honorable Mentions: Fritos and Cool Ranch Doritos. …

Measuring our awesomeness iteration by iteration

By Dave Copeland in Code, Development | August 19, 2009

Like a lot of startups (and big companies!) we use iterative development: we break up our work into "stories" describing features and implement as many as we can in one month. We then repeat that until we conquer the world. But, if we can do more, or work more efficiently with each iteration, our goal of world domination will approach that much quicker :)

The easiest way to do that is to look at the bugs our QA staff find in the product updates. Although we have a lot of automated tests, we still need some eyes on the applications to check for things like text overruns of our printed reports, or JavaScript weirdness in some less-than-well-behaved) browsers.