Magnolia Turns Ten: 7 Tips for Creating Long-Lived Software

Once upon a time... we were a family-sized team working from a garage. Today, Magnolia is a company with subsidiaries that span the globe. As someone who was with Magnolia when the project just started to take off, I’m using this opportunity to sit down on a metaphorical bench and look back on the past decade like a wise old man.

I remember the joy when we sold the first license. Today, I lead about 25 developers and we have a base of 180 customers. What a shift! The cosiness was nice, but having a Mojito in Miami or getting ready for our US conference feels good, too.

I’ve been doing my job here for almost 9 years. In the course of this almost-decade, I learned some valuable lessons on how to successfully manage long-lived software projects. Making a nice piece of software is quite an achievement already, but continuously improving it for 10 years without getting stalled or irrelevant is even more of a challenge. Here are 7 tips that might help you tackle and succeed in similar challenges.

1. It’s the potential, not the features
You need features to close the deal. You need a catchy message to market the product. But the value of a software project lies in its potential. Often, we create a hook and ship a basic default implementation. For example, we once added a language detection mechanism. Once this was done, different approaches were added to projects. Later, we worked in some of them into the product. If you are sure that there is more you can do with the product, you can be sure that you will be able to innovate if needed. And: the people using your software will most likely find a way to solve their problems. This might make them happier and more loyal than you think.

2. Remove obstacles to make space for that potential
The best way to create potential is to remove obstacles. For instance, we once added a hook to configure custom renders, which let others support other languages. In another case, we streamlined the codebase for JSP and Freemarker support, so we had to care less about maintenance. Sometimes, it’s even enough to make a class extendable by changing a method’s visibility from private to protected. The things that are blocking you are likely blocking others, too. So removing obstacles is as important for increasing the potential of a software as creating new catchy features. I experienced that once the obstacles were removed, new ideas came up immediately. It frees the project and opens up many paths.

3. Evolution beats revolution
You start out with big, lofty ideas. Unfortunately, you won't change the world right away. In this initial frustration, it might be tempting to start over, to change everything. However, never underestimate the negative side effects of a revolution. There are many who won't follow you. There will be customers who won't update and developers who resists to learn. Plus: if your project has been running long enough, you will have a pile of things that you have to migrate, too. Is this a vote for keeping everything as is? Absolutely not! This might be the end of your project. However, you should evolve step by step, incrementally. Verify if the new approaches result in success. Learn what you have to do differently next time. If you consistently remove obstacles and care about the potential of the software, you can be sure to not need a revolution to change things. If it’s not the right time for a great idea, it’s not a great idea yet!

4. Quality requires more effort
I had to learn that quality is not a side effect of virtuous developer skills. As soon as you are more than a one man show, you need to make sure that what is created by different minds fits together in reality, too. Today, we have so many commits - only automated testing and integration testing guarantees a stable and shippable piece of software. To build this up, you need time and steady improvements. Make sure you continuously add enough test related improvements to your backlog. Developers will not write tests if it is too cumbersome or if the effort seems to outweigh the benefits.

5. Decentralise through ownership
Over the years, code which is not owned by anybody is turning into orphan code. And guess what - this fact contradicts with the evolutionary and obstacle driven approach I describe above. I strongly believe that organizations work best if they are decentralised. Owners will maintain the code in their very own interest. We have more than 30 modules today and no one could possibly have an overview of what needs to happen where and when. Owners solve that problem.

6. Always ship
If you don't ship, your best idea might die an instant death. If you wait too long or if you want too much, it will get more and more difficult to finish. Sometimes, it’s better to have a smaller and maybe less satisfying release than to risk waiting for too long. Only then can you properly move forward and readjust your priorities and your planning. When people start using what you created, they will give you the feedback you need to make it better.

7. Retrospection is everything
Your methods should change as you move along. What was a good approach for a long time might not work once you add one more developer to the team or a new feature to the software. It’s critical to have a retrospection meeting after each milestone. This will help you adapt your approach and guarantees that you are not moving into the wrong direction for too long. If there is no adaptive management, there won't be any agile software development in the end.

If you keep these points in mind, your long running project won't become stalled or irrelevant, and you’ll be able to surprise again and again. I’m convinced that Magnolia 5 has the potential to let impressive innovation evolve it for many more decades!

When we were still cute and young ;-) Philipp, Boris and Greg in Berlin