This article addresses a process where a team moved from a traditional waterfall model to using agile elements in order to deliver a product to a government agency. It talks about typical problems that come up in a transition to agile, complications from distributed teams, and the advantages and disadvantages of the process for government or nongovernment clients.
In order to be successful in the ring, a sumo wrestler needs to maintain a heavy body weight and at the same time be in peak physical condition. Just as these Japanese athletes have to find the right balance through a well thought-out combination of diet and training regimen, software development organizations need a balanced approach to implementing application architecture on agile projects.
Internationalization isn’t only about dealing with other nationalities and languages. It’s about creating software for a multicultural world. Even if the software you’re testing won’t be translated entirely into another language, it still should meet some basic requirements for international visitors.
Many developers and testers are familiar with test-driven design (TDD), but how can managers use it to drive project implementation? In this article, John Goodpasture offers a guide to TDD design from the project manager’s perspective.
Automated unit tests verify that a component is working as expected. They also serve as a way to understand how code works, though this doesn't always happen by reading tests. Sometimes understanding comes from tweaking the tests to observe new failures, or rewriting the tests themselves.
We are leaving the "last responsible moment" for a while. This month we start a discussion of Feature Injection, an analysis process based on real options and Kolb's circle of learning. The first episode ( of five ) introduces the "Information Arrival Processes.
Peter Schuh writes that it is not a good thing that the use of the term refactoring has grown so common, which makes him cringe every time he hears a business person say the word. Refactoring is meant to be one skill of many that is second-nature to a journeyman programmer.
The step between specifying requirements to working on a system design can be tricky. Fortunately, the basis on which the step is made can be calculated. Paul Reed thoroughly explains how the transition should progress and offers some instructions on how to move properly through this phase.
All code is not created equal. Learn from a master of the craft how to spot bad code and mold it into good. In the first iteration of this regular column, learn why selecting names for classes, methods, and variables is an art you'll want to perfect.