Category Archives: Simplifying Software

Extreme Programming, Scrum, Simplifying Software

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 →

Simplifying Software

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 →

Simplifying Business, Simplifying Software

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 →

Simplifying Software

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 (https://labix.org/gocheck). Others went down the testify path (https://github.com/stretchr/testify). 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: https://github.com/polyglot-jones/testify/tree/sed_script/utils

I placed the script in a new “utils” folder that has a README.md 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.

Extreme Programming, Simplifying Software

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.

Blog Notes, Events, Simplifying Software

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.

Blog Notes, Events, Simplifying Software

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 http://www.socalcodecamp.com/schedule.aspx Continue reading Code Camp Schedule Posted →

Simplifying Business, Simplifying Software

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 →

Getting Things Done (GTD), Simplifying Business, Simplifying Software

Brainstorming for One

I just went digging through some old blog posts of mine, and a found a few worth reposting. Here’s an excerpt of one from early 2004…

A colleague of mine gave a presentation yesterday about brainstorming techniques. For example, he talked about how an initial pool of ideas can be built up in the generation phase by pushing the boundaries, piggy-backing on the previous ideas, and inverting or negating the previous ideas.

I will never forget the first time I tried it. Continue reading Brainstorming for One →

Lean/Kanban, Scrum, Simplifying Software

Scrumban = Scrum + Kanban

I’ve been a follower of Scrum ever since I first heard Ken Schwaber present the subject at an XP user group meeting in Pasadena in ’04. Scrum has come a long way since then, boasting over 50,000 Certified ScrumMasters worldwide. Scrum is well beyond the innovator and early-adopter stages and firmly entrenched in the early-majority stage. People are no longer asking, “Will Scrum work?” but rather “How will Scrum work for me?”

Unfortunately, along with popularity comes dilution and permutation. Surrounding a core of solid, serious adopters lies a realm of half-serious adopters sometimes jokingly, but affectionately, referred to as “Scrum-buts.” You hear them say things like “We’re doing Scrum, but we’re not doing daily standup meetings,” or “We’re doing Scrum, but we can’t track velocity because the iteration work keeps getting interrupted with support calls.” Scrum purists would say that these people are missing the point of Scrum. That the full measure of benefit from Scrum cannot be realized by adopting it piecemeal.

I used to be that kind of a purist, but I’ve changed. Continue reading Scrumban = Scrum + Kanban →