Location: TBA

Course Outline

Location: TBA

Course Outline

Location: TBA

Course Outline

The specifics of the coding standard aren't all that important, just that all team members follow the same standard.

Here are some sample coding standards:

• Java – Code Conventions for the JavaTM Programming Language
• Ruby – The Unofficial Ruby Usage Guide
• C# – Visual Studio Coding Techniques
• C++ – CERN C++ Coding Standard

Agile advocates only working overtime if it is effective, and certainly not for an extended period of time.  The basis for this is to allow Agile teams to work at a pace that can be sustained for the long term without causing burnout. This improves the quality of the work performed, and improves the team's morale.

Of the 4 variables of project management – Resources, Scope, Quality, and Time – Sustainable Pace is intended to improve the control of Quality.

True Continuous Integration occurs when developers use the practice in concert with Test-Driven Development (TDD), integrating their work immediately after writing a unit test and just enough code to make the test pass.  The cycle looks like this:

This leads to developers integrating very small changes very frequently – on the order of 5-10 minutes.  This practice all but eliminates the issues such as complex merges with collisions that teams encounter when they integrate even once per day and certainly when they delay integration for longer periods of time.

There are several tools that assist in Continuous Integration:

• Jenkins
• CruiseControl and CruiseControl.NET
• AntHill
• Gump
• Hudson
  
• Bamboo
  
• Team Foundation Server (TFS)
  

Each of these tools can be configured to poll your code repository for changes, and automatically start the build process when a change is detected. They can also execute unit and accpetance tests, and report the results.

There is also the belief that a tool is overkill for implementing Continuous Integration. James Shore has published a Continuous Integration Checklist, that thoroughly describes the CI process without the use of special tool (excepting a rubber chicken!).

Generalizing Specialists

In order to allow all team members to share in the work, you want to avoid having very narrow specializations as much as possible.  That doesn't preclude having people with some specialization, but the team members should be Generalizing Specialists as much as possible.

Remember, though, this is just a guideline – there will always be instances where very specific specialization is required.  However, in most cases Generalizing Specialists will be more productive.  As Robert Heinlein said in Time Enough For Love:

A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.

There are several ways to achieve this goal:

• Pair Programming
• Peer Programming
• Open Source Committer Model
• Formal Code Reviews

Pair Programming

In Pair Programming, all production code is written in pairs -  two programmers working together at one machine. Pair programming has been shown by several experiments to produce better software at similar or lower cost than programmers working alone.

This is a rather controversial practice – the concept of not working alone is foreign to many programmers. However, Pair Programming acts as a real-time code review, and it has a distinct peer pressure aspect to it.  Programmers are more likely to develop test-first, follow coding standards and refactor their code when there is someone working with them!

Research by Dr. Randall W. Jensen published in 1996 while he was working for the U.S. Air Force spoke of two-person (2P) teams. At the time of the report, 2P teams had been in use since 1975. Initially, there was concern that there would be lost productivity owing to having 2 people work on the same problem. However, the study showed productivity improvements of over 150% at the time scale of a month.

Similar research by Laurie Williams at North Carolina State University has indicated that there is a 15% overhead when programming in pairs, i.e. it takes 15% longer to develop the same code as when it is written by individual programmers. However, the 15% overhead is more than made up for by the reduction in defects and the higher overall design quality of the code. Also notice that the overhead is only 15%, as opposed to the expected 50%. This indicates that two programmers working together are indeed working faster than when they are alone.

Pair Programming, though, depends on total engagement by both people involved.  If one simply acts as a passenger, it is indeed a waste of time.  The social aspects can be uncomfortable for some people, although it can be argued that software development in general is a social exercise and it requires the level of collaboration that pairing provides.

Peer Programming

In this model, developers may work alone but they must have another developer commit their code to source control.  This means that the second developer will perform a quick code review, and work with the first developer if any issues are identified.

This provides the benefit of a second pair of eyes reviewing the code, but doesn't provide the real-time feedback that Pair Programming does.

Open Source Committer Model

Most open source projects have a very small group or even a single person who is authorized to commit code to source control.  There may be many, even hundreds, of people creating code and submitting it for review.  Considering the number of highly successful open source projects, this model does have merit.  For situations where the development people are widely distributed geographically, it can be particularly effective.

The assumption, though, is that the committers have time available to be able to review submissions.  A committer must have the talent and in-depth knowledge of the system to be able to verify that submitted code is able to be committed.  Because committers are reviewing, they aren't able to work on as much production code where that talent and knowledge may be better applied.

Formal Code Reviews

The traditional form of code review involves multiple team members reading selected code line by line to critique the design and style and search for defects.  There are processes and tools available to facilitate the review process, including a number of open source and commercial tools to help ensure adherence to coding standards and static analysis of the code for potential issues.

While this review method is not without merit, it's current use has become generally limited to safetly and life-critical applications, with the other methods increasing in popularity.

Agile development delivers business value sooner by focusing on the key qualities that lead to innovation, productivity, and quality. Every Agile team we work with is different. Your corporate culture, your skills base, your objectives, and even your products come down to one common element – people.

Westboro Systems Agile development, Ottawa combines Agile methodologies and proven experience in Agile training and Agile coaching to bring out the best in government adoption of Agile and enterprise Agile development clients.

If “the best”, for you, means effective communication, decreased attrition, increased productivity, and maximized return on investment, you’ve come to the right place – Westboro Systems is Ottawa’s choice for Agile solutions and project management.

Agile Software Development Training

We have a number of workshops to bring Agile skills to your teams, from introductory Agile training to advanced technical skills workshops. Using a hands-on approach these courses start with the motivations for Agile through to practical examples of using Agile in your teams.

More information…

Agile Coaching

Coaching is an excellent complement to Agile Training. Working closely with your teams we ensure that you use the Agile practices effectively, avoiding  the mistakes that teams new to Agile commonly make. We look at all aspects of delivering the system or product from strategy and business engagement to automated tools and build systems. We can start with kicking-off a new project or work with a project in progress.

More information…