Design Town
Form ever follows function.
The Design Town software project was superficially very similar to the Messy Metropolis. It too was a consumer audio product written in C++, running on a Linux operating system. However, it was built in a very different way, and so the internal structure worked out very differently.
I was involved with the Design Town project from the very start. A brand-new team of capable developers had been assembled to build it from scratch. The team was small (initially four programmers) and, like the Metropolis, the team structure was flat. Fortunately, there was none of the interpersonal rivalry apparent in the Metropolis project, or any vying for positions of power in the team. The members didn’t know each other well beforehand and didn’t know how well we’d work together, but we were all enthused about the project and relished the challenge.
So far, so good.
Linux and C++ were early decisions for the project, and that shaped the team that had been assembled. From the outset the project had clearly defined goals: a particular first product and a roadmap of future functionality that the codebase had to accommodate. This was to be a general-purpose codebase that would be applied in a number of product configurations.
The development process employed was eXtreme Programming (or XP) (Beck and Andres 2004), which many believe eschews design: code from the hip, and don’t think too far ahead. In fact, some observers were shocked at our choice ...
Get Beautiful Architecture now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.