Large Monolithic Applications Must Go...

There's simply no way that a single team of analysts, architects, program managers, designers, engineers, programmers, testers, and users can produce a large monolithic application from scratch without incurring a tremendous expense of resources. Moreover, there is a huge amount of history and effort buried into every single mainstream application that would cost a fortune to replace. The pace of development of such applications must inexorably grind down to a halt. Large monolithic applications are about as agile as molasses.

So... don't build monolithic applications!

Monolithic applications are characterised by their attempt to control the whole state of the world. They generally suffer from the inner platform problem as they try to unite objects, actions, preferences, views, controls, tools, and affordances under a common shell. This way lies madness!

Pretty much every monolithic application ends up going this way. Architects agonize over nuisance details involving how to abstract component interactions into the shell. Large refactoring efforts and attempts at pluggable architectures only forestay the inevitable for so long. Eventually we end up with an entire tool-chain, perhaps even software factories, all wrapped up in and around the problem of managing an exponentially increasing number of component interactions. An enormous investment of engineering resources is poured top-down into the shell!

This approach is incredibly wasteful! By and large, software teams around the world are tackling the same problems, encountering the same road-blocks, making the same mistakes, and never quite getting all the way there. There's too much micro-management and too little reuse. Why should anyone ever be forced to design a new plugin component model, dynamically populated toolbars, key binding management, system preferences storage, software updaters and all of the other bits and pieces you need in a real large scale application? This stuff has been done 100 times. Look at Eclipse for example.

Monolithic applications must go! Consider dynamically assembled interoperable object-centric or service-centric models instead. Why should you even need to care that you're working inside an "application" when you're really just trying to perform some task. Don't expect future UIs to look or work at all like the walled gardens we have today!

I firmly believe today's development model is broken and unsustainable.