|
Passing the Buck One way object-oriented systems address the maintenance problem is by using "implementation hiding." Clients of an object shouldn't be dependent on its inner workings--they should only have to know how to talk to it.
|
|
|
Scaling Agile Processes Agile processes are revolutionizing the software development industry. Projects embracing agile development are expected to be faster and more efficient than traditional software development. Agile processes enable developers to embrace requirement changes during the project, deliver working software in frequent iterations, and focus on the human factors in software development. Unfortunately, most agile processes were designed for small or mid-sized software development projects-bad news for large teams. Having worked with many larger teams transitioning to agile processes, Jutta Eckstein shares her insights into ways to tune your practices as you scale up to larger projects. Harness the adaptability of agile software development for large projects to ensure frequent releases even with several teams working together.
|
Jutta Eckstein, Jutta Eckstein
|
|
Welcome to the Mainstream As agile software development leaves the early adoption stage and moves solidly into the mainstream, Mary Poppendieck reminds us that fads in software development have come and gone before. What makes us think that agile is different? Unless we learn from previous attempts to improve development practices, we are destined to repeat the mistakes of the past. Mary describes three proven paths to failure: (1) Copy what successful companies are doing-You don't get to be world class by chasing after best practices, you get there by inventing them; (2) Force everyone to follow the standard process-The best path to success is leveraging the intelligence of "ordinary" people in the relentless improvement of your current process; and (3) Focus on technical success-Technical success is a euphemism for business failure.
|
Mary Poppendieck, Poppendieck LLC
|
|
Programming with GUTs Because tests are commonly viewed in terms of offering quantitative feedback on the presence or absence of defects in specific situations, Good Unit Tests need to both illustrate and define the behavioral contract of the unit in question. Do you have GUTs?
|
|
|
Software: Use at Your Own Risk Is it really so hard to produce software that works? When was the last time you read a software license agreement? Most are one-sided statements that limit the product developer's liability. It's time to move away from "Use at your own risk" software and be upfront with customers about the true cost of quality.
|
|
|
A Galaxy of Patterns The Gang of Four's design patterns have a special place in many programmers' hearts. But it's time to look beyond the GoF twenty-three and realize they aren't the only patterns in the universe.
|
|
|
How to Fail Less and Enjoy More The shiniest software application in the world, shipped on time and under budget, is a failure if it doesn't make someone's job easier. Failures cost us customers and money. How can we design software that our customers want to use and that will reduce our cost of failure?
|
|
|
A ''D'' in Programming, Part 2 In his final pitch for the D programming language, Chuck brings to "closure" (pun intended) a running example from previous Code Craft articles while exploring some powerful features of the D language.
|
|
|
When to Step Up, When to Step Back Leaders can stifle progress when they unnecessarily interfere with team processes. However, as a leader, you don't want your project to go over the cliff and fail miserably or deliver the wrong results either. There are times when leaders should stand back and let the team work things out for themselves—and other times when leaders should step up and really lead.
|
|
|
The Accidental Complexity of Logic Much code complexity and no small number of program defects can be traced back to confusion over logical expressions and the expression of logic. Find out how you can get that complexity under control.
|
|