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 to share, 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. As it happens, many things we assumed at the beginning were wrong, and we had to go back 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 where we started naming our components like SampleComponent.jsx and SampleComponentNew.jsx. in the fear of losing some code that we might need in the future!
You can understand how these add up to a substantial technical debt over time.
Not investing enough time on 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 just 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 a lot of 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 the whole thing.
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
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
5 DRY Principles To Follow In React
Using Git properly
I learned how to use Git and GitHub efficiently. I am still learning it and get 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
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
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
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 Personal Website
Top comments (7)
As an experienced JS developer of over 20 years and TS developer with a few years on me, I'll say that TS is not essential, but it can be useful if used correctly.
Many of the issues your team had could have been even worse had you been using typescript, and I only say that because I've seen it. Typescript helps enforce some things, but if your devs are undisciplined, then undisciplined TS is even worse than undisciplined JS.
The solution? Learn to be disciplined. The best way I've learned to do that over the years is to focus on TFD (test first development, a sub variant of test driven design that focuses on only writing one test at a time). TFD, if practiced almost religiously, practically forces you to get disciplined. If say about 80% of the issues I've seen in JS/TS work themselves out automatically when the team practices TFD.
The hardest part about TFD is it takes a while to make it a habit. It feels slow and backwards to most devs at the beginning and it's not as fun, initially. It takes about 2-3 months of regular practice to get to the point where it really starts noticeably making a difference, but at that time, the difference starts getting very noticable. Most of those design patterns you talk about are more natural to do when you write your tests first. They almost seem obvious, and it's actually harder not to do them when practicing TFD.
Going for coverage, for coverage sake, may produce the opposite results. If those tests are written after the code is written, then they will likely be harder to write and may even help lock in bad practices. If you've ever seen articles decrying the use of unit tests, I can likely guarantee they were writing their tests after they wrote the code.
If there's any one single thing that makes the most difference in getting to Sr level development practices in the shortest amount of time, this is it.
It takes real courage to share a failure story. Respect.
Stories like these are an immense source of learning. Thank you for sharing.
Great post, its sad to see projects go downhill because of problems whose solutions exist.
I wonder if it really failed because of technical reasons like you imply or was it also product side to it?
At which point you realized that it had failed?
I wonder if it's possible for you to post the link of that whole project? Just curious how messed up, it could be. 😊
😅