Dogfooding is short for “Eating your own dog food,” which represents the practice of using your own products. For software developers, that means working with, as a real user, the applications you’re building, or at least working closely with people … Continued
Software systems often are broken up into a series of layers. Typically, these are drawn as horizontal boxes, such as in the diagram shown here, and represent different logical components of the system. There is value in separating an application … Continued
Software development is a whole team activity – avoid silos and barriers to communication. Extreme Programming introduced the idea of the Whole Team, which includes business representatives, testers, and of course programmers. These teams work together, ideally within the same … Continued
What is Pain Driven Development (PDD)? It means waiting to apply principles, patterns, and practices to your code until there is some pain the current approach is causing that must be addressed. It’s a variation of YAGNI that ensures you … Continued
A great deal of the time, software developers can mostly figure things out by just trying things, and seeing what fits. Maybe it’s a matter of trying different combinations until the compile error disappears, or maybe it’s a matter of … Continued
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
Never lose sight of the fact that until you ship your product, it is not providing value to anybody. Joel Spolsky put it well when he wrote: A 50%-good solution that people actually have solves more problems and survives longer … Continued
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
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.
A metaphor that everyone (whole team, customers, management, stakeholders) agrees on for how the system works.