Developers Are Cattle

July 14th, 2013

On twitter, I read:

Developers Are CattleĀ

Please go read it. I think it is wonderful, and I agree whole-heartedly.

One way to treat developers decently is to recognize that developers are first-class customers of the code they write, and their needs (testability, maintainability, monitorability-that-avoids-3am-pages) should be put at the same priority as the needs of external customers.

agile practices turn me into a finisher

May 10th, 2013

You know how some people are “starters” and some people are “finishers”? Well, I’m a “starter” who, with great effort and discipline, has figured out how to finish things. And when I write “great effort and discipline”, I mean lots and lots and lots of effort and lots and lots and lots of discipline. I remember Each. And. Every. Project. I. Have. Finished. Ever.

A few years ago, I noticed that the majority of projects I finished had at least one of the following two characteristics:

  1. They were broken down into small, unambiguously-finishable tasks
  2. I paired while doing them

Stories, ATDD/BDD, pairing. These practices turn me into a “finisher”


February 15th, 2012

I’m available, full-time or on contract, to help you and your company deliver high-enough quality software systems. My contact information is on my main home page.

Here’s a story that illustrates one way I have been of help:

One company asked me to complete a small set of interview programming puzzles. The first question involved writing a set of SQL queries and updates. The second, to take a set of csv files representing inventory and orders and report how much inventory was left after all the orders were filled.

Since I already had the environment set up, and mostly for amusement value, I implemented the solution to the second problem in SQL. (LOAD DATA LOCAL INFILE …)

SQL not being known for its ease of implementing exception processing, I did eventually switch to a scripting language. But I kept the SQL solution around, and showed it to a few of the folks in my network.

One of those folks, when we talked about this, had a bit of an “Aha!” moment. He said something like, “Wow! Maybe I don’t have to use [complex technology stack and various programming languages] to solve [problem involving loading and processing big chunks of data]. I could load the data into a database and run a much simpler set of SQL against it. Thanks Dave!”

This kind of thing happens a lot. As part of my work style, I learn things from and about the people and systems around me, and I share that learning with others. Often, what I share helps someone realize a new or better solution to a challenge they have been working on.

Bring me in, and let me help you learn what your organization already knows.

The New Gig – Look at the Wiki Waves

April 27th, 2009

The ritual for new hires at a past company included asking the new hire to copy a stack of papers containing the “shared knowledge and lore” of the organization. The new hire spent most of the first two days filling out HR paperwork, making copies, and reading the copied material. This kept them out of the hair of the manager/mentor who probably had a bunch of fires to put out from the weekend.

Fast-forward to today, where I was pointed at the wiki and the pages referencing ‘New Engineer’ and ‘New QA’ necessary information, giving the lead of my new group time to figure out what to do with me. (I’m in training for the next 3 weeks)

I can speed-skim with the best of them, and I noticed an interesting pattern. Clusters of last-modified dates.

Bunches of pages were updated in the past week. Another clump in the past 2 months. Then another cluster 6 months ago. More clusters at 2 years and 3.5 years in the past.

The clusters seem to be thematic, too. Almost like they correlate with starts of new approaches, or changes in approaches.

Hmmmm. Cultural archaeology can be such fun.

new type of bug

April 6th, 2009

snuffleupabug – a bug that is ignored because you think the reporter (who you consider less sophisticated than you) is making it up.

CubicTest, with pictures

February 8th, 2009

In a recent post, I mentioned that I was planning on writing a test in CubicTest to help refactor an IP address validator web page.

I finished the test, and fixed the script. My overall impression is that CubicTest is fairly straightforward, and I have not yet used it to its strengths. I still want to play with subtests, test suites, and custom test steps.

Now for the pictures:

The IP Validator looks like this:

IP Address Validator, initial view

IP Address Validator, initial view

When you enter a possible IP address and click the button, the server-side script returns a nifty table with the result:

Validator after entering a good address

Validator after entering a good address

Unfortunately, there was a bug in the script. After the third address checked, the display looked like this:

Validator showing display bug

Validator showing display bug

That bug is not the interesting bug I wanted to keep. Here’s the quick test I came up with, using the CubicTest plugin:

Test for validator

Test for validator

During the test development, I added id attributes to the result table elements. That made the common contexts much easier to specify. And I had a few go rounds with eclipse editor weirdness switching the sense of the last check from “text on the page” to “text not on the page”.

OSTATLI a success, and a lot of fun

February 6th, 2009

Yesterday, I was one of the attendees at the Open Source Test Automation Tool Love-In, hosted by Elisabeth Hendrickson at the QualityTree offices here in the Bay Area.

Other attendees included Dale Emery, Chris Sims, Jeffrey Frederick, Ken Pier, and Kevin Lawrence.

We chatted a bit about test automation philosophy, told war stories, and played with the tools.

I watched Elisabeth set up a RobotFramework test for some ATDD work she is doing with a new website. When she showed the “fixture” code and the interface capabilities of the tool, I was hooked. I’m going to write up some tests for the big-app-at-work next week.

Kevin Lawrence gave a demo of what he accomplished after 10 minutes of playing with CubicTest. It reminded me of the graphical workflow test for rails Brian Marick was working on.

Last night, I managed to get seleniumrc up and running on my MacBook, then this morning I got cubictest installed and running in eclipse. I think I’ll use it to write tests so I can refactor my ip address validator (the one with the interesting bug I’m keeping in, but the annoying bugs I want to fix).

Finally, Elisabeth shared a pointer to UISpec4J as a good unit test library for Swing.

Lots of other tool goodness happened, too.

Thanks again, Elisabeth, for calling and hosting the event.

Test Data Management

February 4th, 2009

A quick hint about managing test data for “enterprise” applications.

Does the application under test rely on a large central database?

If so, is that large central database backed up on a regular basis?

If so, can you get access to the backup files?

For some testing tasks, it might be easier to just load a new database instance from those backups than to create and populate a database from scratch.

In one case, we dropped, truncated, and pruned a number of tables from the backup, then created a new backup file. A much smaller backup file. One that loaded in one hour instead of many hours.

some of my values

September 5th, 2008

apropos of nothing, some stream of consciousness thoughts while scanning twitter. (hey look, I’m blogging again!)

  • I like to know what I am doing, and why I am doing it. (mindfulness)
  • I like to know what we are doing, and why we are doing it.
  • I like to know what we did, and why we did it.
  • I like feedback. Fast feedback, and close feedback.
  • I like creating affordances.
  • I like precision and accuracy.
  • I like to tell my audience when I am compromising precision or accuracy in order to better reach another goal.
  • I like people who are hungry to learn. (they make me a better teacher)
  • I like french vanilla ice cream.

Learning Java through TDD

September 5th, 2008

Over the past few weeks, I’ve been working through the book Agile Java – Crafting Code with Test Driven Development, by Jeff Langr. Why?

  • I’m evaluating it as a self-study guide for a co-worker who wants to learn java.
  • While I’ve read plenty of java, and made small modifications to existing java programs, I’ve never written a major java program from scratch, nor have I ever set out to systematically learn java. So I’m learning java. yay!
  • While I’ve written plenty of tests, and I’ve modified some existing tests, and I’ve written tests before I’ve written code, I’ve never written a major program using xunit-style tests and doing TDD. So I’m learning TDD. yay!
  • I’m also taking the opportunity to immerse myself in eclipse and intellij

I’ve had some interesting experiences (thoughts and feelings) doing this, and I’ll write up some details in separate posts.

I just finished lesson 12. Earlier, I wrote the following in my notes:

I’ve gotten through the end of lesson 6, and I’m very impressed. I feel confident that I can recommend this book to my coworker, and he’ll be better off going through it than not.

I’ve been using eclipse more than intellij for lessons 5 and 6, and I’m steadily becomeing more comfortable with it.

I found and installed the EclEmma plug-in, and very much like using code coverage to identify code I can delete after some refactoring. And I’m duly impressed that I get 100% code coverage when I run my tests*

*actually, almost 100%. the gaps are things like assertTrue not being called with a false condition (duh), never calling the constructor of a utility class, and not testing the default methods for enums. I can live with that, for now.

One thing I did not expect was that my brain felt like it filled up and overflowed, and I kept forgetting what I was doing, as I got towards the end of the lesson 6 exercises.

more on that last bit soon.