Sustainable Pace

Sustainable Pace

Software developers should rarely be made to work more than 40 hour weeks, and if one week does require overtime, the next one certainly should not.  This helps to maintain programmer welfare and avoid a death march project.
Ubiquitous Language

Ubiquitous Language

All stakeholders on a software application, from users to product managers to developers, should share the same terminology when discussing the elements of the application. Use of a ubiquitous language reduces the risk of miscommunication and the need to translate … Continued
System Metaphor

System Metaphor

A metaphor that everyone (whole team, customers, management, stakeholders) agrees on for how the system works.
Update the Plan

Update the Plan

When you miss a deadline or milestone, don’t just blindly shift the planned deadline back by a day. This is an opportunity to quickly re-assess the project’s status, update the plan, and communicate the new plan to all of the … Continued
Simple Design

Simple Design

Kent Beck created four rules of Simple Design. These are sometimes referred to as The Four Commandments or the XP Simplicity Rules. The rules, in priority order, are that code should: Pass all tests Express the author’s ideas Avoid duplication … Continued
Descriptive Error Messages

Descriptive Error Messages

When something unexpected or exceptional happens in a software application, usually an error message is displayed to the user and/or logged somewhere for a developer to investigate. If the error is something temporary, such as a lack of a network … Continued
Collective Code Ownership

Collective Code Ownership

Collective code ownership breaks down fiefdoms within an application’s codebase. Nobody “owns” a particular part of the code. Everyone on the team is responsible for all of the code.  This enables pair programming and refactoring by the whole team. It … Continued
Common Architectural Vision

Common Architectural Vision

Well-designed software must have a single, well-defined architecture. Virtually all software, regardless of how well-designed one might find it, starts out with a single architecture. Unfortunately, many applications evolve over time, sometimes going through a partial re-architecting process that never … Continued
Rubber Duck Debugging

Rubber Duck Debugging

Sometimes the process of describing a problem, even to an inanimate object, can reveal the solution. Rubber duck debugging refers to the practice of using a small toy, like a rubber duck, as your first assistant when you are faced … Continued