To read more articles like this, visit my blog.

How does a project fail? How do you know if you are working on a project that is doomed right now?

That is not an easy question, but we can dissect a failed project to get a better picture.

That’s what I will do today.

Why?

In a previous story, I shared how our startup failed. One of the primary reasons behind it was technical failures.

As I was involved in the development process, I saw firsthand how it all spiraled out of hand.

It’s not a proud story, but this experience made me who I am today. I will share that story of transformation, too.

We Avoided Best Practices.

There are tons of principles for the developers out there. SOLID principles, DRY principle, Clean Coding, etc are some of the most notable ones. But as a junior, we sometimes fall into the trap of achievement.

Building something people can use becomes a point of pride for us developers. That’s exactly what we were told when doing online courses.

We cared little about the project’s internal architecture, let alone following best practices. We just added features and got shit done.

But Requirements Change

I can still remember most of our components were above 500 lines. It was a mess. But unfortunately, we couldn’t understand that at that point. We missed the bigger picture because we were so focused on shipping features.

However, things started to cause problems when we started getting customer feedback. Many things we assumed at the beginning were wrong, and we had to return to the drawing board.

Every slight modification either broke something else or required a complete rewrite of the component that required even more testing, and some other parts failed, and so on.

You get the picture.

Poor Use of Git

Git and GitHub were very easy for us to start with. But we only used it to store the code online and nothing else. Things like

• Maintaining meaningful branch names.

• Issue tracking

• Release Pipeline

• Tagging

We never thought about these.

We worked on branches named after us. Yes, so the branch I worked on was named faisal.

We coded our stuff and just merged it with the master. That’s it. I know it can sound weird, but that’s how it was back then.

As a result, we were too afraid to delete anything.

At one point, we started naming our components like SampleComponent.jsx and SampleComponentNew.jsx. In the fear of losing some code we might need in the future!

You can understand how these add to a substantial technical debt over time.

Not investing enough time in using git properly costs a lot more than people can imagine.

Inexperienced Developers

We were just friends at the end of our university life. And the people we hired were also very inexperienced.

There are two reasons behind that. The juniors were cheap to hire and didn’t know better than us.

We felt a sense of self-gratification that we have become something. As a result, when we realized some of our mistakes, it was too late.

Because the culture was already bad, and we couldn’t get out of that.

Not Testing

Yes. I guess it’s the obvious one.

The main benefit we could get by testing was the reduction of time in manual testing, which needed to be done after every change, which wasted a lot of time.

Even now, after working in the industry for some years, I haven’t seen a single project where testing is done appropriately.

It’s not to say 100% coverage is the way to go, but at least some functional testing with something like react-testing-library and cypress can save time.

Not taking advantage of TypeScript early enough.

TypeScript was gaining popularity back then. And we adopted it eventually, but it was too late then.

When we started adding TypeScript, we realized we had to rewrite everything.

I probably don’t need to explain why TypeScript is essential, but looking back, I can see how adopting TypeScript earlier could help us better.

What did I learn?

Well, a lot of things. My Medium profile is a living journal of what I learned.

Best practices

Best practices are here for a reason. I learned to care more when naming variables and functions and keeping things small and tidy.

21 Best Practices for a Clean React Project Practical advice for improving code qualitybetterprogramming.pub

Design principles

Design principles like SOLID and DRY can help you decide when you are making your technical choices on a day-to-day basis.

I learned why they are essential and how to use them effectively.

How To Apply SOLID Principles To Clean Your Code in React A Look at the single-responsibility principle (SRP) in actionbetterprogramming.pub

5 DRY Principles To Follow In React 5 Useful Techniques You Can Use Today!javascript.plainenglish.io

Using Git properly

I learned how to use Git and GitHub efficiently. I am still learning it and am fascinated every day by its depth.

I learned how an effective release pipeline mechanism can help remove many headaches.

Continuous Deployment Pipeline for React Apps Using Github Actions and AWS S3javascript.plainenglish.io

Testing

I ignored it for such a long time! But now I know its importance and can’t count how many times it saved my a.

Everything You Need to Get Started With Testing in React A gentle introduction for beginnersbetterprogramming.pub

I Became Frugal

I learned the importance of choosing the right tool for the right job. I won’t say I have become perfect, but before selecting any library, I spend a substantial amount of time researching the ins and outs of it to make an informed decision.

45 NPM Packages to Solve 16 React Problems An in-depth guide on how to choose the perfect npm packagejavascript.plainenglish.io

That’s my story. I hope this story will help you decide better than me next time. Some learn by doing; others can learn by watching others fail.

I hope you will take something away from this story.

Thank you so much for reading the whole thing.

Have a great day!

Have something to say? Get in touch with me via LinkedIn or my Personal Website.