Merce

Processes

  • Coding and testing

    Coding standards We have written-down coding standards which are used for source code control. They also include editor settings to facilitate indentation and block editing.

    Issue tracking We use a web-based issue tracking system for all tasks undertaken by all project team members. No developer is supposed to start any task without its issue being defined first. Updates are expected to current tasks at least 3 times a week, if not daily. All team members are watchers for all tasks in the project, thereby giving a certain visibility to all reported updates.

    Themeability All new projects are designed such that their web UI is completely configurable without having to modify any code or recompile source files. Heavy use of CSS tags every component of the web pages with appropriate classes, so that their layout and appearance can be controlled purely from a single style.css.

    Testing Each developer does his own testing, and test scaffolding is developed and retained with the source repository. Some projects are using JUnit.

    Source code repository All source is checked into a repository which is tied to the issue tracking system. This allows each commit to be tagged against the issue which it addresses. It also allows people to pull out the latest snapshot of the entire project to do test builds of other team members' code with their own.

    Daily reviews Most projects which operate in a single location attempt to do a brief daily review of the work every morning, along the lines of a stand-up meeting. All team members briefly discuss what they've completed and what they intend to do that day. This acts as a very effective sanity check to detect priority drift, scope creep, and dependency bottlenecks within one working day.

  • Tools and frameworks

    We work to standardise on frameworks and tools and then try to use the standardised set of components for every project. We discourage individual project teams from taking their own decisions about packages and versions. As these components mature and morph over time, we review our standard set periodically, typically every 2 years, and make changes.

    For server-side code, we use Apache, Tomcat, and Java STRUTS 2 for the business logic, and the Velocity templating engine for the screens. For browser-side code, we use simple HTML heavily impregnated with CSS class tags, and Javascript for dynamic front-ends. We build screens using static HTML wherever possible instead of adding widgets to the screen dynamically through Javascript calls. We use the Dojo toolkit, currently on v1.7, in preference to raw Javascript code to the extent feasible. We have not yet reached a stage with JUnit where we can add it to our standard toolset.

RELATED READING

  • Case studies

    Work we have done for other customers in various engagement models