What I’ve Learned After My Developed Project Was Cancelled?

For me, as for most people, it’s important to leave a legacy. Surely, including my job, taking into account we spend a lot of time working by day and learn how to perform better at night 🏙️

This story is about why you should enjoy and value the final/intermediate results no less than your journey. It might sound like a cliche, but I’d like to share more than just a story. In fact, my experience of how I was working on a dream project. A dream project that eventually got postponed to nowhere and what I’ve learned from this.

Every big step at your pet project, AAA multi-platform SAAS solution, or any other kind of project should be rewarded. Despite most developers getting paid hourly, I’m talking about the mental rewards for the сompleted work.

As the anecdote goes: “When a group of children was asked where their fathers work. The answers were: “my father is a farmer and he produces meat”. “And my father is an engineer and he produces cars”. “And my father is a programmer and he produces nothing”.

Depending on the project type, I always try to set personal goals. So, I know what I'm along with the project is about to achieve. Whether it would be 10k users for the B2C model daily, better performance, or perhaps, my goal would be to solve a problem for B2B in a better way than pre-existing solutions already do.

Nowadays, after a certain number of released projects (including paused, postponed, and canceled ones, which makes finished projects even more valuable), I enjoy checking the state of my work. Thus, I like to review the consumed amount of content for the data aggregator - the project I successfully led a couple of years ago. So, being part of the project and observing Grafana's graph of data processing, it was great to realize that it processes up to 5kk units per hour right now, while overall capacity used only for 30-35 percent. But most of all I like to understand, that I have developed a product, that is being used by other people.

I've been completely frustrated when my first project (developing which I spent nearly a year) have got canceled due to changed market requirements. Despite the fact, I've been paid for the work I did, I thought that in the end, I built nothing. I felt like I was doing meaningless work because the project and my effort was useless for that moment. But thanks to that experience, I've learned a couple of crucial lessons:

1. You should commit to the project’s design

Even more over time. If you work with data, a specific market or a business model you should learn about the details of this business. This will help you as well as your client achieve goals. Plus, you should discuss questionable decisions and always suggest new ones. Of course, you should have some expertise in the market field and this requires a high experience level (but I thought, it best to start from small things).

2. The golden mean

There always should be something between pure MVP and a fully functional system. The MVP is a great strategy to start with. It is a version of the product that has just enough features to stay viable and get the first user feedback. The proof-of-concept will help you to test whether certain ideas about the product can be implemented, while a prototype is a sort of draft of the product. If you know the elements of new product development, you have the chance to improve the product and produce the best version based on your findings and feedback.

3. The common goals

The common goals are the core elements that drive a team to achieve the best results. The goals usually include: 1) meet project requirements, 2) deliver on time, 3) keep the quality high.

4. The level of commitment

The strong belief in the goals and values of the project is a must-have if you want to create a meaningful product. The willingness to engage in the project, solve problems, learn new skills, etc.. defines team members with a high commitment regarding achieving project goals.

5. Self-confidence is essential

You can and should play to your strengths. Competence bears little relationship to confidence. The fact that you do your job extremely well does not, by itself, ensure that you are also confident of your abilities. It is only when you are aware of your competence that you become confident.

🏆 Coming back to the project I mentioned earlier. From time to time we developed different modules for our applications independently to speed up the process. But there is always a downside, and it is the mid-range of a project. The overall picture should look like a precise set of gears, but at that stage, we didn't have it yet.

For me it's the most frustrating moment in independent development. While you don't have proper side modules, you have to use mocked data to simulate realities for modules, you already spent nearly half of the time but nothing is working yet. The key to understanding overall progress and my peace of mind is proper task management and getting to the required minimum of features to claim module MVP.

💥 A separate chapter is long-term projects with precise planning, epics, agile, and stuff, which always needs to be adjusted during the development. The biggest issue of grown systems is the complexity of any sized changes. To avoid spending tons of time you should design a good modular structure, cover the codebase with various tests, and etc.. Better would be to have expertise in the part of the application you are about to update, but this is not always possible. There is no panacea for this, but the adage which states that with great power comes great responsibility applies most appropriately to the case, on my own, I know that my update about to affect lots of people as well as lots of my colleagues work, so this complexity is what I have to accept.

🤓 ☝️ Quite an important part of software development is dev/staging environments. This is relevant for Back-End developers. So, without a properly set side environment, sometimes it is difficult to assess the amount of work you have already completed, but what frustrates me the most is that you don't see features you recently implemented working. With intense development pace, I always plan a features list ahead. But how can I go forward if I don't see my previous effort as a fruitful one? Milestones (is a specific point in time within a project lifecycle used to measure the progress of a project toward its ultimate goal) are an additional source of self-confidence, a good way to assess intermediate results you (your team) achieved.

To sum up, joy from programming can and should be consumed not only from the process but from results as well. Over years, I noticed that I do not receive the same satisfaction working with well-known technologies as years ago, but I still care about new product launches like the first time. The presence of intermediate results makes me feel satisfied, confident in my job, and think positively about tomorrow.