Introduction

We all want to ship features as fast as possible. Especially when we have a long wishlist of other features waiting to be shipped. The catch is our shipped code must be clean, scalable, and working as expected. The big question is, can we have the best of both worlds? This article explores how to release quality code and still have time to watch the Champions League finals.

Why do developers fail to ship fast?

Developers fail to ship fast for a couple of reasons

1. Developers often struggle with understanding complex features. They spend a significant amount of time analyzing ambiguous feature requests and translating them into detailed specifications and algorithms. Breaking down a feature into smaller, logical components can be a challenging process.

2. They spend too much time on things that don't matter much. Spending hours or even days trying to make a function 1% faster or turning that for loop to a list comprehension.

3. It can be demotivating to write unit tests, documentation, and change logs, often resulting in taking longer than necessary.

4. Developers often get sidetracked by fixing bugs unrelated to the feature.

5. Fixing bugs takes a lot of time, especially when found by QA instead of yourself.

Luckily for us, all these problems have solutions.

Build Early, Validate Continuously

Instead of spending so much time worrying about whether you designed the right feature, build what you understand. Keep the client in the loop. Design a version or prototype and demo it to the client. Let the client tell you how far away you are from what they want. Always remember that success is just iterative failure.

Lay the foundation: Write clean code from the onset

Avoid technical debt by writing code that's clean and reusable from the very beginning of the project. Apply design patterns that support extensibility and reduce coupling. You shouldn't have to refactor your entire codebase for every new feature. Having a good project directory also goes a long way.

The Zen of Testing

Always write your tests before you code, while you're still full of energy. It keeps you focused on the task at hand. Every piece of code you write should aim at passing those test cases. Start by designing integration tests (tests that cover the entire feature) then decompose them into smaller units, testing each function or module to be written. If the requirements change, remember to adjust the tests first before updating the actual code.

Solve first, optimize later

Most times, the client doesn't care about how fast your product is, as long as it is fast enough. They don't care if it is multithreaded or runs on the GPU. Don't waste everyone's time trying to make the code faster when the code doesn't even exist. It doesn't hurt for your product to be the fastest bunny in town, but fast code that's full of bugs or doesn't work means nothing. Focus on getting it working first, and spend time speeding it up later.

Conclusion

In this article, we've looked at the various reasons why we developers may fail to deliver on time and how we can tackle each of these reasons. Overall, it promotes an agile culture and a Test Driven Development methodology. It also encourages developers to embrace clean code and proper use of design patterns throughout their projects. This article is helpful to all developers from interns, to seniors across all niches.

Relevant Reads and Watches

1. Agile Development

2. Clean Code by Uncle Bob

3. Design Patterns

4. Software Testing

5. Test Driven Development