You and I could probably make a strong case against more meetings, but what I found is that some meetings do help. In fact, some of them can help reduce the cost of development considerably.

So here's what I hope you get out of this article:

• How to reduce development costs with just one meeting
• How to increase junior developer confidence
• And how to reduce development cycles

I'm sure you've seen this happen so many times, where one well-intended developer spends a week coding on some feature only to later realize (usually through code reviews) that her assumptions were all wrong from the beginning. I've written about this here, if you'd like to read more.

Assumptions are easy to make, especially for the new devs and the junior ones.

But assumptions are evil. They can eat up a lot of time and effort.

So I advocate for having at least one bridge meeting where business objectives are translated into developer readable tasks (and ideally tests) before any code gets written.

The reason I like to call this meeting a bridge meeting is because I think about it as the point of intersection between strategy and tactics (or goals and tasks).

If your team is practicing Behavior-Driven Development, it's impossible to get away without having this meeting.

Coming out of it should be two lists. One that talks about what defines an acceptable implementation and one that helps developers do the work.

Make the first list first

The first list, talking about the acceptable implementation (aka. acceptance criteria)) is the one validating what the developer is supposed to deliver.

It's UI (or user, or API client) focused and somewhat ignorant about the implementation detail.

Here's an example of one such list item.

Feature: Notifications
  Scenario: I receive my invoice over email
    Given I have an account
    And I purchase a product
    Then I should receive my invoice over email

A complete feature will have a few more scenarios like the one in the example above.

And as you can see, it's implementation agnostic. On purpose.

But the reason I'm excited about it is it starts a conversation about the implementation.

Your team can ask questions like "How do we want to send the email", or "Will there be multiple user roles", etc.

Some of those questions will have obvious answers, but others will explore different possibilities. And that's what you want, to remove assumptions.

You often get out of the meeting with more questions than answers, which is ok because that's a cheap way of figuring out the critical details.

Having a follow-up meeting is always better than re-writing a bunch of code.

Now make the second list

Armed with the knowledge from the previous meeting, the team can fill in their todos.

It helps to have a template for starting this list, which enforces some good practices and operating procedures.

Here's an example of what a list like that might look like:

TODO:
[ ] - Create git branch
[ ] - Push the branch to remote
Group - Process payment:
  [ ] - Write tests
  [ ] - Implementation
Group - Send email notification:
  [ ] - Write tests
  [ ] - Implementation
[ ] - Run all tests
[ ] - Validate code against style guide
[ ] - Push branch to remote
[ ] - Create pull request
[ ] - Tag reviewers
[ ] - Fix code using the pull request feedback
[ ] - Merge branch
[ ] - Update ticket

Each new feature should have at least one list like this. If the feature is big enough, or split across multiple developers, there will be multiple lists.

Making these lists look like a waste of time, but I would argue that the time spent vs. time saved from unavoidable interruptions makes it a no-brainer.

It's been proven that it takes about 25 minutes to regain focus after you get interrupted because you have to change contexts and remember where you were when you get back to work.

But by using a to-do list (and a suite of tests), that time can be reduced significantly.

The biggest productivity tip

I've been at it for more than 15 years now, and the best tip I can share about the practice of writing software is to learn how to write it test-first.

Not only will it make your code better and easier to extend, but the most important reason I find is, it reduces stress by a huge amount.

You can offload some of the cognitive load to the machine and only keep a very tiny fraction in your head. That fact alone is worth the time investment in the practice.

And all the other benefits will come for free.

Conclusion

Reducing the cost and increasing the speed of software development can be done by using some of these proven productivity tactics.

It might seem like there's too much ceremony involved, but that's just because we were told to ship fast and don't look back. I believe that's the wrong way to write software.