DEV Community: Sam Swinton

One Release, One Smile

Sam Swinton — Tue, 13 Apr 2021 04:17:06 +0000

Only so many hours in the day

Each developer on a tech team has 8 hours a day, 40 hours a week, 2000 hours a year to develop a product. Time is limited, we can't get any more. (Working more than 40 hours a week actually lowers per-hour productivity so that is inadvisable.) You can always add more developers to a team, but features can only be broken up so much; you can't grow a garden in half the time by having two farmers! Your tech team's time is limited, the sooner you accept that the better.

Every release should make one user happy

Now that we accept that time is limited, we must figure out how to use the time in the best way possible. But what is the "best way"? The most lines of code written? The most features completed? The most code releases made? I suggest that the answer is: the most smiles created.

The thesis of "most smiles per release" implies two things: some features create more smiles than others and features must be released to makes the smiles happen. This definitely requires a balancing act: release too fast and nothing will be of enough value to create smiles or take too long to release and the frowns will multiply.

Finding the most smiles

You may think you know what your users want. You might be right! However, it doesn't hurt to justify your assumptions with actual data. I've seen stakeholders respond to delays with: "it is okay that feature will take another month, nobody really cares about that". That's not a feature that will generate any smiles, is it? Remember, we have limited time; we shouldn't waste it on non-smile features!

The best way to find out which features will create the most smiles is to talk to your users. Not send a survey, ACTUALLY TALK TO THEM. You need to know how your different user segments experience the product. What do they love about it? What do they hate about it? Do they use it for business or pleasure? Would they use something entirely different if they could? Your users are people. if you want to work well with people then you have to be a person! Talk to them and really listen!

However, it is unlikely the user will come to you and say "here is the documentation of the feature I want with time estimates". You have to be prepared to steer the conversation. You have to be able to hear though what they are saying and interpret what they actually want. This is an art and a skill. It requires practice. Start now.

Stop reading this and start releasing

Now that we know the features that will put the smiles at the most faces, assign them a duration to complete. Next, sort them by most smiles per day. This is your list of priorities. Now get to work, those smiles won't make themselves!

Your time as a tech team is best spent making your users as happy as possible. Anything else is a waste of time. It is about focus. By the way, reading more articles doesn't make more smiles! Cut it out and start making smiles: one release at a time!

Please Write Tests!

Sam Swinton — Fri, 20 Nov 2020 00:41:29 +0000

Programming isn't just writing a program, especially if you're coding professionally. You need to think about writing tests if you're coding as a member of an organization or team. This is still true even if your focus is developing new features. Today, I'm going to try to convince you that tests are worth your time.

Find fast, fix fast

When you're part of a larger organization with multiple teams working together, it's better to find problems earlier. Let's look at the impact of finding a bug in different phases of development.

If you can find a bug in the requirements phase then you might be looking at a two-second decision that saves you days of coding down the wrong path.

You may face a small inconvenience of a couple minutes if you find the bug while implementing the code.

However, if you release your code to the rest of the team, then it might waste hours of QA or UAT time to find the bug. Even then, you still have to fix the bug. (Remember, the fix is the same no matter who finds it; you'll be making the same commit to the repository.) After that, your team has to re-test your fix. When you wait longer to find a bug, you start wasting other people's time, not just your own.

In the worst case, if you have a problem in your code and you release it to production, you may actually be spending the rest of your career dealing with it. Really! Sure, the result may simply be a couple panicked hours of fixing and redeploying. Worst case, you could be creating a foundational problem that your team members will build on for years. You might be setting up to maintain this house of cards for the rest of your career, adding chewing gum, paper clips, and rubber bands to the code that you just deployed today.

If you have tests for your code, like unit tests, then you can catch problems earlier. Earlier is faster; faster is better. If you have to make a fix, you should address it as quickly as possible. Write unit tests for your code so you can catch problems fast.

Code confidence

Tests will give you and your team confidence to make changes to existing code. Frequently, you will be unavailable when the time comes to make changes to the code you are writing today. Having tests allows your teammates to confidently change your code, especially junior developers. (If you've ever had to modify existing code as a junior developer, that can be pretty intimidating without tests!)

Be a good teammate and write unit tests so any member of your team can make a change without fear of causing a regression. Remember, that teammate could be a forgetful future you!

Reduce scope creep

My biggest programming pet peeve: scope creep. The scope of projects tends to get bigger over time; more is added instead of delivering the product to the customer and scheduling any additional enhancements into future sprints. The main idea in agile methodology is to get the customer the most important features as quickly as possible. This can be accomplished using TDD (test-driven development).

In TDD, tests are written before development begins. When you write the test before the code, you only implement what is necessary to get that test to pass. This forces you to stay focused on the exact scope outlined in planning. Tests that are written beforehand enforce the predetermined scope of the project to avoid letting it get out of control.

Provability

To every developer who doesn't write tests before they begin development on a new feature, I ask: how do you know when you're done? A developer using TDD test-driven development will be able to answer: I am done when all of the tests pass. Any developer without tests is just guessing that they are done.

The inverse is also true: tests allow your team to prove themselves to YOU! You may trust your more seasoned teammates, but you may want to keep a closer eye on the team's new hires and temporary contractors. Tests allow for accountability without requiring you to check every line of their code.

Working documentation

Look, I know agile says documentation isn't the most important thing in the world, or at least it shouldn't be your main focus, but all features need some form of documentation. When you're onboarding someone new onto the team, you need to be able to explain to them what everything does. Sometimes you forget and need a reminder. If you don't have any documentation or any sort of manual, you just have to rely on everyone remembering everything correctly.

Having some form of documentation is good, but if you're going to have documentation, why not have working documentation? Test documentation has a dual purpose of providing confidence in the code and explaining what the code does.

Tests are better than static documentation written years ago; they are prove-ably true. If you ever wonder if the tests still accurately document the code, then all you need to do is the tests! If the test pass then you know they are current and correct.

Kanban: The End Of Status Updates

Sam Swinton — Mon, 29 Jun 2020 14:41:36 +0000

The Problem.

There are stakeholders who ask for status updates in every tech project. Whether they are managers, project managers, or investors, someone always wants an answer to the question: "Where are we now with this project?" The common solution is to get everyone together at the same time to discuss the project status, sometimes known as a "status update meeting".

Why are status update meetings a problem? If the project's developers are in a meeting then they are not writing any code. However, the various stakeholders can have good reasons to want to know the status of an ongoing project. Any solution to this problem must balance stakeholder concerns with maximizing development speed.

The Solution.

The kanban board is an effective solution to status reporting that removes the need for a status update meetings entirely. The general idea of a kanban board is to always have an accurate summary of the current status of the project.. Therefore, if a team has a kanban board, then status may be communicated through the board rather than in a meeting.

A basic Kanban board will organize all project tasks into three categories: To Do, Doing, and Done. Every time a developer starts or finishes a new task, they will update the board to reflect this status change. If a stakeholder wants to know the big-picture status of the project at any point in time then they only need to look at the board.

Example Kanban Board

Kanboard boards can be physical or virtual. Many ticket tracking software solutions have built-in kanban boards that update automatically to reflect the status of the corresponding task ticket. Does your team's software not have this feature? No problem! A kanban board can be as simple as putting stickey notes up on the wall of an office!

After you adopt a kanban board, please resist the urge to have daily status meetings where everyone reads the kanban board together! This practice is still a status meeting and eliminates all the benefit that a kanban board can provide while adding the extra work of building and maintaining a kanban board.