This series started as a few posts on our internal blog and eventually became my DevCon 2017 session, What Works – Increasing Code Quality While Staying Lean. I started these when we were bringing on a new employee and felt the need to document some of the reasons we were successful. With so much interest in the DevCon session, we’re now making the original posts public: this will be the first of four. These tactics have made a big difference for SeedCode and I hope you find them useful. – John Sindelar
Introduction: Increasing Code Quality While Staying Lean
The strategies we’ll be talking about in this series apply to projects of every size. In addition to building products like DayBack, SeedCode does a ton of custom work: from 3-hour mods to help someone implement a cool feature, to multi-year 10,000-hour projects. We use the same techniques for projects of both scales. And that’s part of the secret: to run the big ones like a series of very small ones.
What do we mean by Quality?
Software quality means different things to different people. Sometimes it means DRY code, reusable code, or code that conforms exactly to your style guide. In this case, I’m just talking about code that saves you money. Money and time. So in this context, quality means:
- Less rework
- Increased delivery velocity
- Role portability within your team
- Speedier project restarts
What do we mean when we say Lean?
SeedCode is a small shop, so we’re talking about techniques that don’t require:
- More software
- Adopting dev conventions
- Hiring more people
- Working longer hours
What Works? Video is the New Testing
With that introduction out of the way, what has made the biggest difference for SeedCode over the last four years? Video.
When we’re closing a case or delivering a mod to the customer we make a short video showing the feature working. These videos are less than three minutes long and demonstrate the whole feature: so if I changed the sort of an invoices portal, I start the video by making a new invoice… even though that shouldn’t have changed.
The very act of demonstrating the whole feature takes us out of developer-mode and lets us see the work more as a user might. I can’t tell how many times I’ve started making a video for a feature that was “all done” only to find tons of little things I need to clean up in the user experience. Ten takes later, my video is done and the software is MUCH better for it.
[bctt tweet=”Video is the new Testing.” username=”seedcode”]
Don’t worry that the videos take time to create, there are plenty of packages (see “Recent Ideas” below) that will record the video and upload it for you automatically, leaving a link to the video on your clipboard: it’s fast.
As you can imagine, you can only keep your videos to 3 minutes if you’re delivering very small chunks: we’ll talk about that in the next post.
Why Video Works
Videos are so important it’s worth mentioning a couple more advantages…
– a customer often can’t evaluate changes we’ve made for them: they often can’t recreate the initial conditions of a bug or don’t have time to make fake records to try out our changes. But they can always watch a short video and know we’ve delivered what we promised.
– when we have to support a modification, all we need to do in order to get caught up is watch a couple of the delivery videos and we know what the customer is seeing and what we did for them. Compare this to jumping into a mod someone else wrote in a solution you’ve never seen. You’d need to find the files, the account information, and instructions on how even to navigate to the mod or reproduce the bug. Video cuts through all that so you can get to work faster.
– and of course, the videos are a reminder to everyone that the mod worked when we delivered it =)
– videos are also a great way to answer support questions, especially as abstract software stuff can be very hard to write about. A short video using the customer’s name is often faster than writing four paragraphs trying to explain something, and the customers appreciate the personal response.
To make these videos work, we try to include a couple things:
- We record the video in the tone of voice you might use to demonstrate your software to an interested friend. We’re enthusiastic but not trying to sell anything. We’re also allowed to make mistakes, stumble, or stutter: you’re supposed to come off as human in the video, not as perfect.
- Important decisions or open questions in the video are also transcribed into the case or sent in an email to the customer. We can’t search video narration, so anything important, including next steps, should also be in writing.
- Videos delivered to mod customers always end with suggestions for what we could do next to enhance their software. If we’re working through a big to-do list, then we just remind the customer of what’s next. If we’re “done” then we suggest what could be our next enhancement and, when possible, let the customer know how long / how much $ that new work would take.
- On larger projects, we close every case with a video and then send the video to someone else on the team. They will see things that you missed. When they watch the video, they’re on the lookout for the same things that you’re looking for when you recorded it: anything that causes a bit of surprise or causes you to pause.
We’ve made a couple of changes recently to dial in our videos. We switched from screencastomatic to monosnap so we could get an ad-free experience for our users. Both are cross-platform, but monosnap also supports S3 as a storage location so we can set a retention policy for our videos.
The other thing we’re working on is to keep more monkey-mind in the videos. It’s tempting, especially when working on really tricky cases, to demonstrate (maybe “show off”) your solution in the video: even to open scripts and show someone what you did. That’s fine for showing a customer how they can extend your script, but for quality control, we really want to be playing with the software in our video. Making lots of records, printing them, showing how things around the feature work. It’s this kind of absent-minded play that gets your mind in the position to see bugs, and it gets you out of the tiny area you were working on into the broader areas surrounding it: the areas where you likely broke things. =)
Again, if I added a button to sort the line items on an invoice, I’d make a new invoice, add some lines items, sort them, delete one, print the invoice, switch invoices, sort the line items a different way, and then duplicate the invoice. I think you can probably recognize how this gets at the kinds of consequences we don’t always think about when we’re head-down in the code.
What’s a Case?
[bctt tweet=”If you’re reading this and wondering ‘what’s a case?’, you need a bug tracking system.” username=”seedcode”]
Personally, I recommend against building bug trackers in FileMaker so that you resist the temptation to tinker with it: you’ll resent your bug tracker and it’s easier to resent something you didn’t build. And believe me, the folks who make FogBugz, Jira, GitHub, or ZenDesk probably have better insights than you or I about what it takes to manage a large volume of software issues. At least learn from them for a few years before you build your own. For a more compelling argument on why you need a bug tracking database, check out the Joel Test. And if you’re managing a small team, try to pass as much of it as you can.
Your teammates will thank you.
(Yes, we’re re-reading the Joel Test right now, along with this updated version.)