Software is complex. The complexity of many common information systems is way beyond that of any physical system. Operating systems, search engines, automotive systems, missile guidance systems, navigation systems, game engines,…and I can go on ad infinitum. And the list is growing rapidly since ‘software is eating the world’. This is problematic since the number of humans it takes to develop, expand and maintain an information system grows exponentially with its complexity. Sooner or later we will run out of humans. Another unfortunate consequence is that an increase in humans increases the likelihood of errors. In my experience exponentially as well, but I can’t back that up with hard numbers. This deserves a separate post, though, so I will skip it for now. The logical conclusion is that if we want more, more sophisticated, safer, and more reliable information systems we should keep the number required developers as low as possible. In my opinion the efficiency of a software team increases up to 10. Beyond that scale every other member has less added value for the end product. Most experience software professionals have in some point in their career worked for a large cooperation and wondered how they even managed to make any money. A counter argument could be that this is impossible for domains and processes that are inherently complex. I think there are two ways to attack that problem. First of all you should split up complex systems into separate domains and develop information systems for each domain. And split up the organisation along the same lines. Secondly I am convinced that the introduction of the next abstraction level in information system development will enable smaller teams to build complex information systems. The top-down approach mentioned in previous posts is a great contender in my humble opinion, but there are likely others. We should work on methods and tools that enable smaller teams for developing information systems.