Agile

I recently completed a winter survival course where we built shelters in just ten minutes with only the contents of our packs. The pack I brought was nearly empty, so I made a tent out of my parka. It was ugly, but it could have saved my life. How does this apply to software? When building a feature, first get it working, then make it look good. Let’s say you’re building an app that queries a third-party API to get data. “Get it working” could mean getting the API to return the data you need, and then dumping it onto the page as a raw object with JSON.stringify. It works! ...

I think the most important factor in consistent delivery is understanding the work. When you understand the work, you build what the stakeholder wants, better and faster. Here’s an idea that’s not ready for programming work: “Let’s add social login to our website.” Same idea, ready for work: “A logged-out customer sees the Google login button,” with clear acceptance criteria about what that means. In this post, I’ll explain how I go from such a vague idea to a deliverable unit of work. ...

When I create Agile bug tickets, I leave the story points blank. Why? Two reasons: pointing bugs creates the wrong incentives, and bugs are hard to estimate. Bug Terminology First, some context. Pointing is an Agile process of estimating how long a piece of work will take, or how complex it is. Bugs are defects in a computer program that produce undesirable behavior. And so, pointing bugs means trying to estimate how long it will take to fix a bug, or how complex it is. ...

I’ve been working on a development roadmap for my projects, and wanted to share my process. Consider this my recipe to turn an idea into software. The purpose of codifying a workflow like this is to make working with me a predictable and thorough experience. Writing software is pretty hard; it’s much harder when you don’t have a plan. Every item here is à la carte– I wouldn’t typically do more, but I might do less on projects of modest scope. ...

There’s a detail about Today I Learned some might find unusual: we never added a way to delete posts from the site. Why ignore a basic CRUD feature? We didn’t ignore it. It was intentionally omitted. I’ve thought about this decision a lot over the last two years. It’s lasted over many pull requests, issues, forks, and discussions. I addressed it directly in a Github issue not long ago. Preventing deletes was a hack to make Today I Learned feel permanent. If the goal of the site was to show the world what we at Hashrocket are learning, why allow people to self-censor that journey? The temptation to obsess over your output until it’s a flawless diamond of competence is too great, especially among high-performing programmers. ...