Defeating Analysis Paralysis

What is Analysis Paralysis?

Analysis Paralysis is a curse that has plagued many developers. It's the creeping voice in the back of your head that says "what you're doing won't work for this case so might as well refactor it." This leads to a cycle of self-doubt and endless refactoring to try to cover all possible edge cases. Your first run of code passing every test is a pipe dream.

Defeating it

I've found that the best and easiest way to get started is with technology you are comfortable with. A lot of people will write blog posts (guilty!!!) hyping up the new hot NPM package, the new JavaScript babel plugin that allows you to use the new JS stuff, but that's no replacement for the tried and true method. When I use the technology that I am most comfortable with; I know its strengths and weaknesses. I know when to add extra code to fill in the gaps that isn't covered by my chosen technology. I can do this piecemeal and I can address each issue while delivering a product.

Progression

Similar to Dark Souls, coding is a progression. Sometimes you'll do it by yourself. Other times you'll summon the help of others. Either way, you progress towards the goal; whether that may be the product launch or Lord Gwyn, I'll let you decide. Dropping in new code and refactoring is also a part of progression. It's worth starting from a strong foundation and achieving results early on while acknowledging potential shortcomings. This is perfectly valid. An actionable solution now is better than constantly worrying about whether or not your solution is the best one.

There are no "right" decisions. You decide and you make it the right decision.

While working with other people, it's immensely valuable to balance easy and quick wins with more difficult and challenging wins. An example: an easy win would be something similar to adding an icon with a tooltip onhover event that explains its content. A more challenging and difficult win would be something similar to implementing an entirely new workflow for your users. If your day to day work is full of challenging work for you to slog through, I think that's the quickest way to burning out. Striking a good balance is key in retaining people.

Planning for the future

A lot of what happens during bouts of analysis paralysis for me is that I tend to overthink my application structure and potential areas of support. I've learned that this is a terrible way to build any sort of application. I've also learned that the simplest way to deliver a MVUP (Minimal Viable Usable Product) is to start with the basics. If you can't do the basics well, why add all the bells and whistles? It's similar to having a fancy new HUD in your Bugatti Veyron, but no engine. People would look at you like you were crazy for buying a sports car without its engine. Coding is the same way.

Summary

Plan for future core additions after building a strong foundation through a solid architecture that makes sense for your team and you. Use technology that you and your team are comfortable with and add new technology or patterns as your product grows larger. Accept that refactoring is a part of the application lifecycle. Your team and your future self will thank you for it.