Only One Retrospective Action-Item at a Time

Retrospective meetings are probably the most misunderstood and underutilized aspect of agile development.

If you know the expression, “the three most important things in real estate are location, location, location,” then you can relate when I say that the three most important things in software development are feedback, feedback, feedback. And, one particularly powerful feedback mechanism is the retrospective meeting. It’s how the developers give feedback to themselves — about their own processes.

I like to hold retrospectives early and often, at least once a week, sometimes once a day. That way, I can capture ideas while they are fresh on everyone’s minds. To make up for it, the retrospectives are kept short, 15 minutes MAX. In fact, if they go longer than 5 minutes, then something is wrong.

Why so short? Continue reading Only One Retrospective Action-Item at a Time

Rookie Mistake: Jumping to Conclusions with Presumed Solutions

When entry-level developers are assigned a business problem, they tend to latch on to the first solution that comes to mind. Not only does this have a tendency to lock in an inferior solution too soon, but it may even cloud thinking to the point of missing some important requirements.

Listening for Clues

Telltale signs of this mistake are in the developer’s vocabulary, so mentors should pay attention. When the rookie attempts to gather a program’s requirements, does he or she jump straight to using programming terminology in describing those requirements, like hash maps, FIFO queues, reference pointers, and LIFO stacks? Or, does he or she carefully stick to problem-domain terminology like definitions, breakdowns, groups, relationships, andpriorities?

If your rookie is indeed having trouble distinguishing the problem-domain from the solution-domain, then the following techniques may help. Continue reading Rookie Mistake: Jumping to Conclusions with Presumed Solutions

Counter-Intuition: The Confounding Implications of Ticket-Count Stats

Ticket-count analytics should only be used for their intended purpose — managing the list of open tickets. The temptation to infer other implications in the way of employee performance, product quality, etc. must be avoided. In fact, even as a tool for managing the list of open tickets, we need to be careful.

Whenever presented with a metric that implies a certain conclusion, we need to look for confounds. (This goes for all metrics, not just ticket counts.) What other possible explanations could there be? If there aren’t any that come to mind, then the straight-forward explanation is probably correct. But, if there are potential confounds, then deeper study is required. Does a high bug count really mean that bugs are getting out of control, or does it merely mean that stakeholders are over-reporting improvement requests and new-feature requests as if they are “bugs,” either mistakenly or in an effort to game the system?

Using ticket closure-rate counts as a measure of employee performance is a particularly bad idea. The primary purpose of the bug-tracking tool is to be available to the developers as an honest representation of the state of the tickets lodged against the system. Overloading it with the goal of tracking employee performance is a conflict of interest, and Continue reading Counter-Intuition: The Confounding Implications of Ticket-Count Stats

Converting Between Go Unit Test Styles

I’m 4 weeks into a project using the Go language. It’s been an interesting change of pace from my usual Java/Groovy work. There’s a lot to like about Go, but there are some things I miss from Java/Groovy, so the jury is still out for me. (Go is a damn sight better than PHP, that’s for sure.)

Some of us on the project started out using the goCheck extension for unit testing ( Others went down the testify path ( For reasons I won’t go into here, we all just decided to standardize on testify.

To make converting easier, I wrote a SED script that converts “gocheck” style unit tests to “testify” style. At the moment, you can find it in this branch under my fork of testify:

I placed the script in a new “utils” folder that has a with usage instructions.

After my associates finish vetting it, I’ll issue a pull request to see if the testify custodians want to accept responsibility for it.

Java Coding Standards

One of the first things I did after joining PICS was to set up a study group around Bob Martin’s Clean Code book. At the same time, I handed out copies of my principles-based Java Coding Standards document, a document that I’ve been giving out to my clients over the years and which is based largely on Clean Code, but also other works (see the references section on p 1). I just realized that I never uploaded that document here, so here it is: Java_Coding_Standards.pdf

Please let me know if you find this useful, and/or if you have any suggestions for future updates.

Code Camp Downloads Available

Another Successful Event

This weekend was yet another Code Camp that came off without a hitch. I learned things. I got inspired. I made new friends. I won a raffle prize.

It’s time already to start preparing for the next one in January, at Cal StateFullerton.

Slides Available

I gave two speeches this time. Here are the slides (as a PDF) for the Introduction to Groovy talk I gave today at Code Camp. And, here are the slides (as a PDF) and the 1-page handout for the Simplicity Appreciation 101 talk. As always, feedback is appreciated.

Code Camp Schedule Posted

The next SoCal Code Camp is coming up fast. It’s the weekend of October 15 & 16 on the campus of USC. I will be giving two presentations. One talk is entitled “Groovy and Groovy++, In Case You’re Curious” and the other is an encore of my “Simplicity Appreciation 101” talk from the January Code Camp (at Cal State Fullerton). (Full descriptions below.)
Both of my presentations are on Sunday the 16th in room GFS-107.

  • 12:30-1:30 – Groovy and Groovy++, In Case You’re Curious
  • 3:00-4:00 – Simplicity Appreciation 101

For the complete Code Camp schedule, see Continue reading Code Camp Schedule Posted

On Shortening Wait Times

According to The Laws of Simplicity by John Maeda, shortening wait times goes a long ways towards the appearance of simplicity. People hate to wait, and systems that make people wait seem more complicated than systems that don’t. So, for one thing, an engineer charged with improving the performance of a system would do well to first look at the places in the UI where the user is made to wait and optimize those areas, before moving on to areas where the user does not need to wait. Continue reading On Shortening Wait Times

a blog by Craig L. Jones, Software Agilist