Software Development Practices

12/26/2011

This post is part of a series on IT consulting.

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 has a number of benefits. First and foremost, communication within the team will be excellent, and the communication gaps inherent in Waterfall go away. Next, 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

.

Home | Blog | Photos | Contact | About

Wittenburg.co.uk and all content copyright 1995-2018 by Michael Wittenburg, unless otherwise stated.
All content on this site is licensed under the Creative Commons license, unless otherwise stated.

Wittenburg.co.uk uses a single session cookie because it's required by the tech underlying the site (Microsoft ASP.NET). The cookie stores no information and seves no functional purpose.