Software is not made of Bricks

Raganwald dissects the misguided metaphor from a software process perspective. I have come to believe that these kinds of problems are even more prevalent in the web development world than in general software development. Despite the lessons from the Mythical Man Month having been around for more than 30 years, we are still forced to tolerate dominant management conceptions that really do treat projects as if "there are so many bricks to pile and then you're done".

This notion of "completeness" is very problematic to me - experience shows that rarely, if ever can a website be considered finished or complete, no matter if at a high level it meets the specification of features defined in a project. Even a small website has a long list of potential axes of change and improvement, most of which are discovered in the process of design and development. The difference between a good website and a great website is often the improvements made based on usability testing as the site audience responds critically to the original design assumptions. A sad fact of the design industry is that we often work from fixed price budgets or fixed schedules which demand finality and sign-off, not customer satisfaction, as the arbiter of completion. We can't respond to customer or audience requests because once it's out the door, it's done, it's invoiced, we move onto the next thing.

We can't make websites to the high level of quality we would like, mostly because as I have described above, we are not allowed to. Many web agencies in New Zealand are totally ill equipped to manage projects in an agile way, and in some cases are even resistant and hostile to this kind of approach. Others claim to be agile, while in reality their process is more akin to a waterfall-feature with token XP ornaments cemented on the side. It's hard to foist the blame on individual companies so much as a collective delusion of project management dogma, a hangover from the days before Google, before PHP4 even, when we didn't have fluent software frameworks like Rails and Django driving innovation and rapid development in the web space. Your company can either brace for impact with every single project, or adopt an approach which actually embraces change and uses it to make better products for your customers. Rapid prototyping and refactoring are possibly the single most important tools you can use to manage software change, but my experience has led me to suspect that prototyping especially is far more effective when developing backend architectures rather than frontend designs.

Furthermore, from a programming perspective, our research on Understanding the Shape of Java Software suggests very strongly that there is no inherent scale for software components to be. Larger systems simply have larger objects. There is no common brick reduction of complexity that can be used for reusable composition. Using class and package units as an overarching design constraint tends to blunt the effectiveness and conciseness of code in large software systems, leading to execution in the kingdom of nouns.

Methodologically and theoretically, software designers are left with a dilemma. We want software to be like Lego, but it is clearly not. Do we need to simply stop thinking in terms of reusability and objects as block units, or do we continue trying to refine our current approach to object oriented design?