This does not mean that software will hit a place where we can no longer manage it, however, a basic concept of developing software seems to be getting lost. That concept is that you break the tasks down into 'manageable' tasks. Exactly what is a manageable task? That really depends on the manager and the developer, however a good rule of thumb - the one we use at Ibuildings - is that a manageable task is any task that can be completed in two working days or less. The trick is, of course, to be able to not only break your tasks down like this but also to be able to roll them back up into the larger project.

Good project managers keep track of the big pieces and delegate the individual tasks to the developers. Good developers ask enough questions so that they firmly grasp the task they have been assigned and only need to know how it integrates into the next largest piece, not how the whole system will work.

Developers love challenges, the bigger, the better, so naturally, they want to see the big picture and how each moving part fits together. However, in large systems, this is neither feasible nor desirable. Once the decisions have been made - hopefully by the team - about who builds what piece, the big picture should be set aside by all but the project manager and architect.

Once the smaller 'two day' tasks start rolling in, the team lead, along with a good Continuous Integration system will make sure that APIs were followed so that all the pieces fit together. The team lead, together with the project manager, serves as the architectural team for the project. They are the ones that make sure that the small tasks roll up into the bigger pieces, which form coherent modules, which form the system.

From the estimating, through the sprints, through unit testing and to the eventual deployment, increasingly complex systems can be built by managing the pieces instead of the entire puzzle.