Thoughts....

The Problem

Software Development is hard with a capital H. Software costs too much. It takes too much time to build. Software frequently does not meet the needs of the user, and when it does it is often full of bugs. Unfortunately, this is the current state of affairs for too many of us. There must be a better way!

So how do we build better software? As a community we are consistently struggling with these issues. As an individual within our community I am also looking for a better way to build software.

Ideas to Consider

So I don't have the solution. I have, however, found better ways to develop better software.

Agile Software Development

By focusing on the software development team, the way they work together, and the structure of the software itself - in that order - we can build software faster, cheaper and with many fewer bugs than before. This, however, is putting the cart before the horse. What about the tiny little problem of writing software that actually addresses the end-users of the system find useful?! Before we go about solving the problem right, we must first understand the problem so that we can solve the right problem. By bringing the actual users of the system into the development process and by giving them running software often they can provide invaluable feedback on what actually works for them and solves their problems.

The Agile Software Development Community claims that these statements above are true. It is my personal experience and the experience of thousands of other software practitioners on hundreds of projects that agile software development is a significantly better way to build software.

Agile Practice Adoption

Are you thinking of adopting one or more agile practices? Consider the agile practice patterns website as a starting point.

Measurements To Encourage Productive Behavior

Measurement is sometimes seen as a dirty word in Agile Development. Yet for us to claim that we are drastically improving software development we must show this somehow. What measurements make sense to determine whether the adoption of agile software practices are improving our software?

Measurement, whether we like it or not, affects what is being measured. The Uncertainty Principle applies to people on software projects also. By measuring something and making that measurement visible to the team it directly affects the way that they act. What measurements do we want to introduce - if any - to help our team successfully build software?

Design and Architecture within Agile Software Development Projects

One of the most common questions I am asked when introducing agile practices is "where is the Design?"

Equally, what is the role of an Architect on on Agile development team?