As a longtime associate of ThotSpots, I regularly contribute to their blog as well my own. Here are two recent examples:
Why Having a “Backlog” Sucks the Life Out of a Project
Put Your Wisest Developers on Maintenance, Not the Rookies
Click here for the complete list of my contributions over the years: http://www.thotspots.com/author/craig/
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
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.
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
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
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.
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.
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.
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.
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.
For the complete Code Camp schedule, see http://www.socalcodecamp.com/schedule.aspx Continue reading Code Camp Schedule Posted
Here are the slides (as a PDF) and the 1-page handout for the speech I’m giving tonight at Agile SoCal. It’s entitled Simplicity Appreciation 101. (Note: These materials have been revised greatly since I debuted the topic at Code Camp last January.)
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