Blinded by the Excitement: A Lesson for Small Teams and Companies

When starting a career, and especially in inexperienced teams, it’s easy to digress in a new project, especially when you have new technologies and new ways to build something. It’s like a child giving all of his attention to a new toy.

The story

Have you ever been so excited about improving existing software, with lots of great ideas? Well, who doesn’t, right? I’ll tell you a lesson so you can learn from my mistakes rather than from your own experience.

A few years ago, I was working on software that had existed for more than two decades and had even been translated between different programming languages. It didn’t have unit tests or rules to enforce code quality. Imagine how badly written and suboptimal some parts of the source code were — sometimes it reminded me of spaghetti.

When I joined the project, it had a full hand of products split between hundreds of modules and easily thousands of lines of code. The development team had started introducing browser-based features instead of the functional (it’s very important to mention this), but old desktop design.

At a specific point in time, the IT department was allowed to launch some of the existing desktop features in the web environment. As mentioned, the existing software was untested, tightly coupled, and complex to maintain. A plan to recreate (yes, a fresh start) the project was made. The failure started with this decision.

At the time, I didn’t realize it, but that decision was already starting to smell bad.

I wasn’t a junior developer at that time, but today I know that I had a lesson to learn — and I was about to learn it. The development team started to recreate some of the existing features directly for the web, improving everything possible along the way, introducing new development and management concepts as well (another smell for the failure).

The ”✨✨ 2.0 version ✨✨” would begin with a new database and new management screens — literally starting over with a new database, new repositories, new everything. At the time, I didn’t realize it, but that decision was already starting to smell bad. And I didn’t even mention the database migration process.

Time passed, new technologies were chosen, and the team even digressed into minor aspects like how the model structure would be or the use of inheritance versus composition.

Also, the great desire to build the new system as perfectly as possible led us to choose some technologies that were new and known by only a few developers — causing development delays. Here’s the third source of bad smell.

As time went by, other demands on the IT department and external events (e.g., production incidents and existing bugs to fix) caused the team to split its efforts between maintaining the existing software and the creation of the 2.0 version. The dream of building the perfect software was about to end.

A few months later (not surprisingly), the project was cancelled.

Did it hurt? Yes, no more playing with the new toys — back to the old ones. Lesson learned. But I’ll talk about it in a future article.

Key takeaways:

• Excitement can hide technical debt. Choose what your team knows best, not just the trendiest technology.
• Reinvention often fails when maintenance still depends on legacy systems. If the product is large or already in production, focus on introducing incremental changes.
• Plan a long-term improvement roadmap to prevent cancellations and maintain momentum.
• Study the concepts of project management like Kanban and Scrum. In small teams this is even more important, because usually there is no definition of a Scrum Master to guide the roadmap.