The Hack for Surviving the Second-System Syndrome
Our mission was clear: We wanted OutSystems 10 to generate fast mobile apps. The platform generated (server-rendered) web applications, so we had to do a major system redesign, which included changing not only the runtime, but also large parts of the visual programming language, the compiler and the IDE.
We called it “The New Runtime Project.”
We knew it was a massive undertaking, a bet-the-company project that would take almost 2 years. We all hate large projects and their tendency to overstay their welcome, their goodbye, and forever grow larger.
So we were scared. We were terrified. But our customers tell us we’re one of the best R&D departments in the world, so we were pretty sure we had the needed technical skills.
We had learnt a bit of management too, so, to make sure the project wouldn’t get sidetracked, we agreed on a clear set of prioritized goals, and on an ambitious high level plan. We assembled a large team of energized teams that was constantly helping each other. And we had scrums and sprints to make sure everything would go smoothly.
But our technical and management skills alone would not allow us to survive such a risky project.
Why? Because we faced a huge challenge: the second-system syndrome. The second-system syndrome is the tendency of small, elegant, and successful systems to have elephantine, feature-laden monstrosities as their successors due to inflated expectations. (in Wikipedia)
What Saved Us Was a Simple Hack
Soon after we started, we began noticing new stuff creeping up a lot. Clean up of technical debt, improvements to our processes, features that had been often requested, and brilliant ideas that could improve the lives of our users…
The thing about all these requirements was that when people mentioned them, they all started the same way:
- “Since we are doing the new runtime project, how about improving the db layer plugins code that needs a refactoring.”
- “Since we are doing the new runtime project, how about putting a better toolbar on our IDE.”
- “Since we are doing the new runtime project, how about doing Badjoras Driven Development”
Are you seeing a pattern here? We did.
So here’s the genius hack we engendered: Anytime someone started a sentence with “Since we are doing the new runtime project…” he or she would earn a point in our “Since we are doing the new runtime project…” whiteboard.
It was legendary.
Long after we knew it was lame to start a sentence like that and that it would put us up on that wall of shame, we still couldn’t help ourselves. We often heard those words inadvertently come out of our mouths, warning us that whatever we were going to say next, it did not have that much importance.
And we all stopped everything we were doing to mock anyone who added an entry for the first time. But we all ended up there.
Anything that was aligned with the project goals would be discussed, of course, and eventually implemented, although these usually didn’t appear in sentences like the ones above. And to prevent crushing creativity, we had another technique for some of the out-of-this-box ideas — we’ll share it in a future article.
But overall, this simple hack allowed us to control feature creep and achieve our ambitious goals without expensive delays.
Try It Out
So if you are doing a major redesign of a system, you might want to get a large “Since we are doing <this second system>…” wall of shame.
And when that one is all filled up, go get another.
In the end, after you deliver that major version on time, go back to those boards, mine the gold nuggets, and take good care of them.
We have survived, stronger than ever, and are doing it right now.
Tiago Simões believes in making development faster for existing developers, while making it possible for everyone else. That’s his job at OutSystems R&D.
“Since we are keeping your feature creep at bay…” why not help your friends do likewise? Share on LinkedIn | Twitter | Facebook | Email
