Development Management & Practices

We're deeply concerned with fast development. We pay attention to development effort when designing information security, enterprise architecture (persistence, security, management, etc.), user interfaces, or whatever. If it can't be realized within time and budget constraints, then a design is useless.

We also note that all time is not equal. Efficient and effective development processes multiply development capacity of everyone on the team. Effective team development management practices similarly reduce the effort it takes to complete a task - by keeping every team member focus on what needs to be done to complete the project.

Through experience, we've compiled a set of development practices that increases developer efficiency. Each practice attempts to either automate a time-consuming task or avoid it. Concentrating on common, time-consuming tasks by reducing the associated effort necessarily reduces development time. Some of the development practices each member of the team can use to work more efficiently include:

• Source code repository + ANT. Being able to share code and components is key to co-operative development. A repository alone is not enough: an automated build and deployment process is needed to share re-usable components. The Apache ANT tool is the best build and deploy toolkit for general developers we've found thus far.
• Use different development tools for different tasks. Some tools are really great at helping to build UIs, while others help with XML development, and still others really speed things up when doing general-purpose development. Use the right tool for the right job, obviously. A key correllary: avoid forcing each developer on the team to use the same development environment.
• Prototype and build tests. A throwaway proof-of-concept piece will help you build the final version. The proof-of-concept class or component should be thrown together in the simplest way possible to help you prove you assumptions, and flesh-out required behavior. A repeatable, automated test will guarantee your finished product fulfills the same requirements.
• Comment and document. Every non-trivial method and callable interface needs to have a detailed behavioral description, with pre-conditions and post-conditions if appropriate. The code is not the documentation, despite what some people say. The documentation is the documentation, and it defines what the code is supposed to do.
• Re-use existing code and components. Its amazing how many developers will spend weeks of effort in order to save themselves hours of research. Only build a new class when no existing one can do an adequate job.

We have found that an iterative development cycle, with short iterations and regular reviews from interested "stakeholders" leads to the most efficient development practices. Development team members meet regularly to summarize and review tasks to be completed within a short iteration. Tasks themselves are defined by a team of business/executive members, business analysts, QA team members and the development team. This task-defining team is called the "customer team".

A key practise is to ensure the customer team, QA team and development team share a common vocabilary for both the user interface and the internal entities of the system. We maintain this common vocabulary by having the customer team, not the development team, define the abstract business domain model. Surprisingly, having the customer team define the shared business domain model shortens development and acceptance test times more than any other practice.

Short, frequent iterations leads to more accurate project estimation and planning. We rely on individual developer assessments of task development time. And shorter tasks are always estimated more accurately than longer tasks. By relying on task-based development estimates, we accurately predict project timelines, and can see the impact of issues and risks far ahead of time.