This is the fourth post in a series that formed the basis of my 2017 DevCon session on Increasing Code Quality While Staying Lean. Check out the first post for an introduction to the series. These techniques have made a big impact at SeedCode and we hope you’re inspired to incorporate some of these into your own work.

We Record our Debt

In Documenting our Decisions, we talked about “creating a path from the customer’s cases (or feature specs) to the code that addresses them—a path that our future selves can follow.”

Similarly, when we take shortcuts, we record the path not taken as a new case. Technical debt taken on intentionally can help us get there faster, just like debt financing can help a company grow faster. Debt taken on invisibly is like a variable rate loan—not good—and in both cases it’s the unknown that makes all the difference.

What We Do

• We know there is a better way to do something but we’ll defer hardening until our work is validated by the customer. Instead of premature optimization we create a case for the optimized approach and ship what we’ve got.

• We can’t finish a feature, or can’t get to the edge cases, so we create a case for what’s undone. Sometimes the isn’t debt, but just “Friday”—I find myself making cases at the end of the week or end of the day for what I wanted to get done but couldn’t. Come Monday, it takes less time to get back to work because I know just where to pick up. This is a version of Hemingway’s dictum to always stop when you know exactly what you’re going to do next.

• When we’re doing QA videos we create cases for any bugs we see that aren’t going to be fixed IN the video. By creating a case for anything weird we see, we can deflect the hard work of deciding when to fix it, or who’s going to fix it, or even to fix it at all. Without having to worry about that we can pay attention the nuances of the bug, and tag the case with any customers who’ve been affected.

Why This Works

Recording instead of coding lets us observe our work without the pressure to fix it. I’m just capturing the bug, not also trying to determine how big a change it’s going to be. This means we see more–and see more consequences–than if we were just looking for how to fix something.

This also works hand-in-hand with delivering small chunks. Think of a feature as hub with several spokes. The hub might be creating a new contact. The spokes might be checking to see if the contact already exists and then merging the new contact with that existing record. Would an existing contact count if they were archived? What constitutes a “duplicate” contact, is it an exact name match or a close name match at the same domain? And who is allowed to create new contact anyway? Who is allowed to merge?

It’s much easier for me to create cases for these “spokes” (to treat them as debt) than to account for them in my code. If my code is the only place to capture these spokes then I’ll capure very few of them. Further, the deferring part of technical debt means I embargo the spoke cases until the hub has been validated by our customer: and that’s key. Because if we get something wrong about the hub, I’d rather just rework the hub than rework the hub and all it’s spokes.

Recent Ideas

Defering the spokes until the hub is validated is proving to be key. It mean we’re less resistant to chages suggested by the customer and, importantly, less resistant when the customer wants to pivot to a new problem: we’ve already got the landscape of this problem documented.

This was probably the part of my DevCon session that sparked the most… “discussion” =) This is the third post in a series that formed the basis of my 2017 DevCon session on Increasing Code Quality While Staying Lean. Check out the first post for an introduction to the series. This series describes techniques that have made a big impact at SeedCode and we hope you’re inspired to incorporate some of these into your own work.

We Break Things into Small Chunks

Of all the things we do, this probably has the widest application. I think of this when I’m replying to a customer’s email, when I’m designing a new feature, or writing up the cases for what’s to be done in a sprint. And the more I keep this in mind, the better things go.

Here’s what we do:

We deliver every 5 or 10 hours of code.

For large projects, we deliver every week.

Deliver means deploy: putting code into production with data migration and everything.

We do not listen to a client for 2 hours then head into the desert for 4 months to build their software, hoping they like it when we return. That is not how great software is made. Instead, we break things into really small chunks so we don’t outrun our understanding of the client’s issues. And, by delivering small pieces of work more often, that work gets validated quickly so clients can easily course correct. Read Full Article →

As we prepare to bring some new developers on board, it’s worth taking a look at a few of the things we do that make us successful. Sometimes we internalize these things and, not having had to explain them to anyone for a while, they kind of dissolve into habit. Or dissolve into habits we don’t think we need to practice anymore. Documenting our coding decisions is one of the reasons we can support so many customers with such a small team. It’s easy to overlook, but it works.

This is the second post in a series that formed the basis of my 2017 DevCon session on Increasing Code Quality While Staying Lean. Check out the first post for an introduction to the series. We’re looking at techniques that have made a big impact at SeedCode and we hope you’re inspired to incorporate some of these into your work.

Documenting Decisions – We’re Coding for Our Future Selves

We’re coding for our future selves—both in our products and in custom work. We end up coming back to our own code months later and sometimes it’s as opaque to us as if we’d never written it.

So when we make decisions, we want to document them so that our future selves (or our teammates) can more quickly pick up the thread when they return to our work.

This means you can restart projects more quickly, which in turn increases the delivery velocity: especially the velocity of delivering change requests and bug fixes.

Here’s what we do:

• When we comment out or change code in a script or in a calculation, we include a note in the comment about why we did it.

• If work is related to a Manuscript case, we include the case number in the comments: it’s amazing to be looking at an If() statement you don’t think should be there and see this telling you exactly why it’s there… “If filter is not empty and field DOES NOT match this source: Case 30325”. Now you can go read that case and see the real-world situation that required the If() statement.

Read Full Article →

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.

Read Full Article →