Taking the god View in Software Development
I started programming for money in 1987. Granted programming was a small part of my job in 1987, but by 1990 I had started my consulting business and was programming 60 to 80 hours a week for the better part of twenty years after that. On top of that I began writing books on programming another 30 to 40 hours a week. (The secret is to this much productivity is to leave the television off.)
The most common problem that still sticks out today is perspective. Teams get too emotionally involved, including customers and managers, in the nitty-gritty and lose perspective. Perspective is everything. In video games there is often a mode referred to as the god view where the player can see everything, the big picture. By seeing the big picture you can plan an overall strategy to win the game. An overall strategy is what is missing from a lot of software projects. Too much time is spent on details like code reviews and standards, individual bugs, heroic effort, one off utilities that someone gets attached to, project schedules, and random acts of opinion. Many of these elements are useful in their way, but each does not offer the god view that is necessary to coalesce an overall winning strategy.
A big picture objective is essential to success. From the 10,000 foot view, from an overarching perspective, the critical element of success is what is the core nature and functionality of the solution we must deliver. Maybe it is five, ten, or fifty core features delivered and you have a solution. Step back and figure out what perspective will help you see the core value items of what you must deliver and focus everyone's energies on those things, build those first. Real deliverables are seldom, look and feel, components, coding standards, rules, project schedules, and all of the miscellaneous elements that are somewhat desirable but never the software. Build your team's goals around the core features of the software, design and implement those and then build out once the core business solution is functioning.
Here is the rub: many, many teams change players so often that team building, rules of the road, and how people work together is always in flux. From the ten thousand foot perspective accept this. Make sure everyone understands we are building the core out and everything else is a distant second to that objective.
Several things will happen if you follow this approach: as the core features begin to function everyone will smell success and jump on board because everyone wants to be part of a winning initiative, especially since so many projects go astray. Your team must be comprised of those who will eventually march to the same core-feature drum, everyone else is dispensable.
Build your team out accordingly too. Only invite people essential to the core features first because everyone else including, testers, GUI designers, documentation people, and too many user-constituencies will distract your team from the core objectives. Once the core is constructed at a workable level start bringing in other players. You will ultimately start with smaller teams, make more progress, avoid distractions, spend less money early, and people will happily migrate to a winning strategy and team.
To summarize, start with a small group of essential people, including a single manager, builders and a key designer. Define the core functionality by decomposing the problem and composing a solution made up of essential objectives; build those first. Bring in designers, testers, the art team, and a few other experts later after buy in of the core has been achieved. Don't skip design, but don't get bogged down in UML either. If you can buy parts of the core solution, use design patterns, and Refactor then a lot of bits of your software already have ";documentation";; that is, what you buy has been designed by the other party you purchased it from and design patterns are already well documented. Window dressing, documentation, end-user testing, and all of that other stuff can be incorporated once the effort has momentum and the critical features are working.
The god view is not playing god or being a know it all. It is about letting go of small details, taking a long distance view of core features, assembling as much as you can from existing code-we do this any way with the millions of lines of framework code we all use now-using existing design patterns, and literally only designing the trickiest bits of essential features in any formal way as you race to the core features. The core features need to be carefully articulated, but not every feature. Once your core features work and are tested-preferably first by the people that wrote the code, add on the window dressing elements like documentation, help, GUIs, and formal user testing.The god view is not about playing god or being a know it all. It is about perspective, figuring out what is essential for basic, core functioning of a solution, and getting there with all of your energies and efforts first. Everything else is secondary.