Work

Software Development Practices

Home > Work > IT Consulting \ Good Practices

Both Waterfall and agile methodologies are steeped in good and bad practices, dogma, and myth. Most successful projects succeed in spite of their chosen methodology, rather than because of it. The point of this post is to list some useful practices regardless of any methodology you might use.

Change board
Cross-functional teams
Daily builds
Design for change
Evolutionary delivery
Evolutionary protyping
Goal setting
Measurement
Milestone-based
Planning
Principled negotiation
Reviews
Risk management
Staged delivery
Stakeholder management
Throw-away prototyping

Plan

Begin with the end in mind. Jumping into code on the first day is tempting (I often do), but make a plan. If you’re handling credit card data, you’ll encounter the Payment Card Industry Data Security Standard (PCI DSS). If you’re writing an application that’s subject to legislative constraints, you’ll encounter change when the legislation changes. If you want to view orders by customers and products by sales volumes, you’re going to encounter relational issues that aren’t suited to document databases. You don’t need to spend weeks at it, but it helps to know what "finished" looks like (even though finished at the start will inevitably not resemble finished at the end).

Cross-Functional Teams

A cross-functional team is one in which all roles are committed to the project from start to finish. This means team members participate in all phases of a project, from envisioning to close-out/the post-project review. It comes with a number of benefits - first and foremost, communication within the team will be excellent, and the communication gaps inherent in Waterfall go away. Also if for example the user experience role is available throughout the project, it becomes easier to refine the user interface later in the project.

Late-stage course changes won't cost an arm and a leg.

Prototype

Building a prototype means creating a model of the final system. It’s not the system, but something that resembles it. It may not contain the performance, security or operational aspects of the final solution, but it might well provide an indication of its function. The prototype can be used to validate requirements – in fact, it can be used to completely replace the requirements gathering phase of a Waterfall model. Prototypes can be discarded in favour of a new production solution, or they can be evolved to become the production solution.

Prove Concepts

A proof of concept is a small project (no more than a single, short iteration) in which a design decision is proven. Good candidates of a proof of concept are any aspect the team is unsure about, or hasn’t done before. Proof of concepts are typically used to validate technical design decisions. They’re usually discarded, but their teachings are applied to the solution being built.

Design for Change

Change happens. It happens with the tedious inevitability of puberty. Anticipate it.

< Back to IT Consulting | ^ Back to top