What you learn, when your project fails

I am a self-taught developer, as most of us I usually followed tutorials on YoutTube or Udemy. I started (almost) hundreds of projects and never finished any. Ok, I published an app in Mac AppStore, so not that bad…

I had a bold/great/ambitious idea, I should join a real-life project, where I have deadlines and have to deliver regularly. The perfect way to improve or … Here I am collecting all the lessons I learned. Some of you can easily say: “How stupid someone must be not to know all of these in advance?” Believe me, I knew all of them, simply didn’t consider them too important or got tired to make the others follow them. Still, they were my mistakes, my failures and my learnings too.

Background

I found a project on donatecode.com, where a little group of non-technical people requested help in finishing their iOS project. They worked with 2 companies before, and their founding was gone but the app still needed some final touches before beta testing.

The first time I opened the repo I was shocked, there was 0 fork of the project, and everyone simply pushed their code to the central repo using different branches… The “main” branch was not the main, but no one was really sure, which branch contained the latest code.

I did my best and went through almost all the code base, finding out:

  • no documentation at all, not even a README file

  • copyright issues

  • lots of used methods, classes, plenty of lines commented out

  • using CocoaPods but half of the pods are not imported or used - some didn’t work on M1 Mac at all

  • all views were created with Interface Builder, and placed in one .xib. I stopped counting the number of views after 35…

When I was finally able to run the app, it looked and behaved completely differently as it was described and as it was presented in Figma.

The questions appeared: “How I should move on? Continue or rewrite?” Which is the easier, faster and most efficient way?

Dilemma.

One of my favourite article about “rewriting” is by Joel Spolsky. You can say it is old, but I think many parts are still very relevant.

The two main reasons against continuing were the lack of documentation and copyright issues.

After a long discussion, we had no other option than start from scratch again. Focusing on documentation and proper copyright practice. I wish it had been so easy…

Pr(oject)/oblems

I set up a GitHub repo, and wrote a proper README on how to fork, create and name branches, how to make PR. Expecting new team members can join easier and faster. Although I wrote comments in the code and continuously updated the README, I progressed quite fast. And the team has been starting to grow…

1. Design

I am a big fan of UI/UX design. I respect creativity, the balance is more important. Your MVP doesn’t need to be visually perfect or stunning. It is more important, that the function(s) can be tested by users. When your developer spends 1 hour on building functionality and 5 hours customizing built-in elements, your MVP most probably will be never finished but you will have a pixel-perfect mirror of the design file on your mobile. Obviously, no design change during MVP development and ask developers for shooting on moving targets. Despite the temptations, keep the MVP design simple and practical.

2. MVP

As the name shows “Minimum Viable Product”. Considering 80% of the total functionality is not MVP at all. During the first beta testing, most of the developers are shocked when users think differently about functionality than them. They sometimes face massive redesign and rewriting to fulfil users’ expectations. MVP must be small and flexible. Add functionality by users’ requests or by beta testing experiments.

3. Deadline

One of the most sensitive issues is the deadline. Changing the deadline gives the impression that the project is not important and that everyone has unlimited time to finish their tasks. Besides that, the team is losing motivation and momentum as well. If your project is behind the plan, you need to allocate more resources or identify the root cause of the delay.

4. Documentation

I know, a waste of your precious time. Maybe. If you are a solo developer and you remember everything, what and why you did or are smart enough to figure it out within seconds by reading your old code. I am not. Not smart for sure. I need to take notes and comments to remember later. As soon as you start working in a team, it changes because it is hard to read others’ minds. I wrote a bunch of reusable components and added comments and documentation on how to use them in the code. (Not)Surprisingly the new team members were able to use them without a single question. When they changed or created components never wrote a single line of comments, they copied/pasted mine, which was irrelevant. Documentation is an important part of the code base and a form of communication within the team. Take time and effort to create and keep up-to-date.

5. Communication

Regular and open communication among the team members is essential, especially if they work remotely. While the design team held weekly meetings and presented the updated design to developers, within the developer team never happened any meetings, only very delayed communication on Slack. So developers could feel that they had to cope with all the issues alone. In long term, it kills team spirit and motivation as well. Communicate regularly, not necessarily in long, unproductive meetings. Keep team members up-to-date and offer them your support.

6. Leadership/ownership

When two or more people start working together, you have to nominate someone, who will take the lead, be responsible and will make decisions. Everybody likes the feeling to be important and be asked about decisions, but hardly anyone likes taking responsibility. Someone in your team needs to play the unpopular role of the leader/owner, who chases others about the deadlines, frequently communicates among the team and with other teams, fixes errors or helps in fixing errors. It will be still a team effort/success. As an orchestra needs a conductor, every team needs a leader. We call it team, because everyone has the same vision and works towards that goal. Team leadership is about making sure visions are shared and goals are achieved.

7. Motivation

Normally, different people have different motivations. We are different in many things, so why our motivations should be the same? When a team works on a project, it is crucial to maintain spirit and motivation. It is a tough job, because naturally with time motivation decreases, and team members can easily lose focus. Frequent communication, making your team remember the goal and recognition are all easy and free ways to keep motivation up and push the team toward the end goal.

8. Failures

It is part of life and until we learn from our failures and mistakes, they help us grow. Implementing a feature or a test can fail even the complete project, but the courage to move forward is essential. What doesn’t kill you makes you stronger, difficult times are a good opportunity to grow and make the team stronger.

Conclusion

It is not enough to know the “rules”, you need to follow them. Discipline and consistency are keys in everything, especially building or creating something new.

Any comments, feedbacks and experiences are warmly welcome.