Robert Lemke

Managing a big project

Published on 09.03.2010 by Robert 4 comments
Filed under: TYPO3

Over the last years TYPO3 Phoenix – and in the meantime also its sub projects FLOW3 and Fluid – have become huge and complex projects. Most of us surely underestimated the effort which needs to go in such a venture. On the other hand it doesn't come by surprise that creating a CMS from scratch which aims to excel the current TYPO3 in function, user experience, technology and code quality isn't a walk in the park.

The management of such a project is a challenge even under ideal conditions: new technologies and techniques everywhere, no paid employees with a predictable availability, distributed teams without an opportunity to meet regularly in person. However, we don't have ideal conditions. In a perfect world we'd have a dedicated project manager (or better: a product owner and a scrum master) who keeps an eye on the feature set, resources and timeline. But our budget doesn't allow such a position, so we need to be more creative and disciplined to manage ourselves. On the flip side there's a great community which supports us with contribution of ideas, work power, money and certainly not at least with motivating words.

Naturally there is a conflict if a developer sets his own goals. He usually chooses what's most interesting technically and has just the right amount of challenge – documentation and boring bug fixes are neglected. Although we surely ran into one or the other trap, we have a simple principle for creating and assigning the tasks to ourselves: the shortest way. We ask ourselves: what do we need technically to display the content section of the TYPO3 backend and allow an editor to create a new page? Well, we need a lot of code for that simple task, especially if we also consider the architectural whislist we have summed up through the years of using and developing with TYPO3 3 and 4. But still, it's possible to analyze this epic requirement and cut it into smaller pieces: How to eat an elephant? Slice-by-slice!

So we created (and updated ever since) a list of key features and technologies we imagine for TYPO3 5.0: concerning the content model, localization, templating, resource management, TypoScript, package management, setup, performance, security, content access control, web services, user experience and much more. With the blog example (and other applications which are currently in the works) we set ourselves a closer, intermediate goal which allows us to test the concepts and actual code under realistic conditions.

If you look at the features FLOW3 provides today, you'll recognize that they are all providing the low level infrastructure for TYPO3's key features. Of course we can't deny the special attention we put on clean code and a certain luxury for future FLOW3 and TYPO3 developers (and yes, there's possibly one or the other curlycue here and there). But this doesn't come without a reason: first a CMS like we are working on is a huge beast which needs all possible support by the framework to tackle its complexity. And secondly extensions and extension developers play an important role in the TYPO3 ecosystem – we'll enable them to write clean, fast and secure code which will get rid of the problems we face today with thousands of unreviewed extensions.

All this said I do think that we can improve. Communication is certainly an issue: whenever I buck up to write some lines or shoot a podcast I'm worried about the time I'll be missing in development (like now, with the difference that I'm missing dinner ;-)). I frequently ask myself: should I develop? organize? communicate? write documentation? speak at more conferences? In these situations I need to get a clear overview of the options and then decide. The principles formulated by Steven Covey are a great help for me to decide what to do next ("The 7 Habits of Highly Effective people" was a book Kasper recommended me years ago, a very good advice).

Last week I had the urge again to get a clearer view on the open tasks. Karsten and I are using Merlin since January for planning the development and release of FLOW3 and TYPO3 Phoenix. It's a classic project management software but with the nice look and simplicity you're used to from Mac applications. But although it provided us with a much better overview on the different projects and their schedule, an important piece was missing: the issues we manage at forge.typo3.org.

So, yesterday I sat down and did two things: Learn AppleScript and develop a Redmine to Merlin connector. I'm very happy that I succeeded: with one click I can now synchronize all issues of all FLOW3 releases with Merlin. The script not only creates and updates activities, it also sets the estimated work time, start date, completion status and assignments. I hope that this better overview will help us to make better estimates and take more effective decisions on when to develop which feature.

But of course this story doesn't end here. We are in touch with several individuals and companies of the TYPO3 community and together we are seeking new ways to adapt techniques and tools for making the TYPO3 and FLOW3 projects more transparent and more effective. And we need to modify them and be creative – because most of them were designed for ideal conditions ...

Robert is TYPO3 5.0 and FLOW3 founding dev, espresso lover, hopeless optimist and proud father.

Recent Posts

• TYPO3 Phoenix, Aloha and the AGPL license
• Session Handling and Object Serialization
• Paper Selection Process for T3CON10
• MacBook Pro in den USA kaufen?
• TypoScript in TYPO3 Phoenix