Archive for the ‘Uncategorized’ Category

Developers Are Cattle

Sunday, July 14th, 2013

On twitter, I read:

Developers Are CattleĀ http://theotherzach.com/writes/2013/7/6/developers-are-cattle@TheOtherZach

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.

Available

Wednesday, 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

Monday, 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.

Test Data Management

Wednesday, 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

Friday, 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

Friday, 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.

something I learned from my boss

Thursday, September 4th, 2008

(if it is wrong, consider me tragically misinformed)

In the Navy, when they have a “bad ship”, they disperse all of the crew throughout the fleet, then assemble a completely new crew and try again.

Applying this lesson in our context – if you have a “bad team”, break it up and assign the team members to other teams. Then staff the project with a new team and try again.

Just like breaking up a great team and assigning the members to other teams won’t necessarily turn those other teams into great teams, doing so with a bad team won’t necessarily turn the other teams into bad teams.

This lesson is not license to turn your brain off. Bad team != bad people, and sometimes there are people who would find a better fit at some other company or pursuing some other career.

groups who do good unit testing

Thursday, September 4th, 2008

In most software development groups I’ve worked, there have been at least one or two programmers who both believe in unit testing and have the discipline and knowledge to create good unit tests. This has not changed during my career.

I’ve seen a few groups where there are enough unit-test-infected programmers to create critical mass, and the entire group writes, maintains, and believes in unit tests.

I have seen even fewer companies that explicitly and consciously set out to build a group of programmers with the above critical mass in test-infectedness.

So I wonder if the majority of companies where good unit testing happens are the result of chance.

(in response to questions about Is unit testing doomed )

Don't call it a test plan?

Sunday, August 10th, 2008

Inspired by a tweet from “utahkay” where she stated

Organizations that still use the term “test plan” don’t get it yet.

Maybe call them “done plans” since they help us determine when something is done.

As an aside, I’m finding twitter an attractive outlet for writing.

Did I miss the Spock memo?

Saturday, December 22nd, 2007

Invites to join the network site Spock continue to flood in. Thanks for keeping me in the loop, everyone. I really do appreciate it. I wonder, though, who started the wave, and why.