Imagine a man named Bob who has a fatal disease and he has a very low chance of living more than a year. Expensive and regular treatment may save him.

Bob needed a new laptop so that he can earn some money from home, he bought one with $400 which comes with 1 year warranty. The sales girl asked him if he needs additional protection plan for $100 which will give him 3 more years of warranty? Bob thought that’s a great deal, it will make his laptop secure for 3 more years and he won’t have to worry about it anymore, but then he thought, even his life is not guaranteed for one year, why would he care about 4 years? It is much better for him to spend $100 on his treatment, it’s the priority now. Bob did not buy the additional protection plan. Smart decision, right?

Now Imagine a Startup

A startup is trying to build a software product on a budget. The developers are very excited, they outlined project idea, wrote user stories, UML diagrams look cool, discussions on high scalability and high availability make them feel smarter than ever, they want rigorous automated testing so they don’t accidentally break anything. Does it ring a bell?

So after a few weeks they started writing unit tests before writing the actual code (because TDD says so).
You know why it’s taking so long? Because they want the project to be maintainable for years to come. Smart decision, right?

Dear sir, it’s a startup building a product, who guaranteed that the startup will exist for years to come, let alone the product? Most of the time, chances are very low that the product will succeed. Just compare this situation with Bob’s situation.

How often do you hear or think a startup or product died because it was buggy, it was poorly coded or it didn’t have unit tests?

What If We Are Building Something That’s Not Gonna Die Soon?

Then you’ll have a budget that’s not gonna die soon. Company will have the resource to decouple you (the developer) from the burden of best practice and architecture.

If you’re just a developer and you think more about the architecture than actually writing code and building things, then you’re doing it wrong. It’s a signal that you’re in a team or situation where architecture doesn’t matter too much, if it really mattered then there would have dedicated software architects, you didn’t have to worry too much about it.

Remember, theories of programming are not invented out of air, they exist in our daily life from years. Consider “Single Responsibility Principle”. If a company doesn’t care about it too much in human and you(the employess) have multiple responsibilities like software architecting, development, maintenance, testing then what’s wrong if this company’s codebase has a damn Class named UserAuth having a damn method named userProfile()? Now don’t shout “OMG! OMG! It’s a clear violation of Single Responsibility Principle.”

One masterpiece quote from me to rule’em all:

Break your class’ responsibility according to your responsibility as a team member.

Here comes the disclaimer

I’m not against the best practices, rather I follow many of these practices most of the time. I am against following these blindly, I am against following these out of guilt. These are just rules, and you can break a rule if you need, you can break it when it’s not a priority.

We developers are already much prone to anxiety disorders, writing a line of code and feeling guilty for 10 minutes is nothing less than an Obsessive Compulsive Disorder.

Wish you a guilt-free coding life.

There is a very interesting discussion going on about this post on Reddit,
check it out.