Iterating Towards Excellence – Series Introduction

Software developers are an interesting group of people. One of the most common laments I have heard over the course of my career is that after a period of time people become dissatisfied at work. Strangely enough, a root cause of this dissatisfaction typically has more to do with developers feeling like they don’t know what to do in order to improve upon their skills.

This post is an introduction to a series of practices that technical teams can employ in order to continually improve the way they work. Before we discuss these topics, let’s spend time looking at how we got to our current state.

Where We Were

People in the technical industry, particularly in software development, have the great privilege of assisting others in solving challenging problems using specialized tools, but general approaches. In the past, the general approaches were very appropriate and easily applicable. Software construction was likened to hardware construction or physical construction. The general approach to software construction consisted of the following six phases:

1. Discover and document all of the requirements for the system being constructed

2. Design the software so it fulfills all of the documented requirements

3. Build the software

4. Test the software

5. Release the software into the production environment

6. Maintain the software while it is in production

Each phase would be undertaken in sequence with subsequent phases beginning only after the preceding phase was fully completed. This approach is commonly referred to as the “waterfall methodology” since the work progresses steadily “downstream” over the course of the project.

As the business environment changed, however, a group of software craftsmen were frustrated by their inability to respond to change and add value in a timely manner. They realized there was another way to approach software development and came together to form the Agile Manifesto. With the authoring of this set of ideals and principles, a new era began in software development – one that embraced change.

Change is difficult. In general, humans are creatures of habit and enjoy predictable routine. At Credera, many of our clients have the desire to change the way they think about problems or do business, but don’t know how to approach those changes. Given a pragmatic approach to change, where improvements are made in small increments over the course of a reasonable timeframe, we find that lasting change can be achieved.

Where We Want To Go

From the perspective of the software developer and team, these observations are also true. Most of the software developers I know want to improve their craft, but don’t know where or how to begin. Thankfully, there are some relatively straightforward practices (see below) that individual members and teams can collectively do to make incremental changes towards improving their craft.

• Test-driven development – automated testing using a RED/GREEN/REFACTOR approach

• Continuous integration – the whole team commits often to minimize the cost of integration

• Collective code ownership/pair programming – code belongs to the team as a whole, not to any particular team member

• High coding standards – code should be written for people to read and incidentally for machines to execute

If you or your team does not currently engage in these four practices, then you have the opportunity to become incrementally better. One practice at a time, you will be able to improve your personal and team productivity, as well as, the quality of the work you produce.

Stay tuned for future blogs in this series where we will cover each of the above four topics in detail. In the meantime, be sure to follow @CrederaMSFT to stay abreast of the latest happenings in Microsoft and/or leave a comment for us!

• Microsoft
• Agile
• Agile Manifesto
• Iterating