|
Avoiding Half-baked Discovery It can be difficult to explain to your customer why cutting half of the features doesn't cut half of the time and cost. Every software project has fixed costs that often get overlooked in project planning—setting up development environments, ramp-up, building frameworks, and setting up configuration management to name a few. Read on for some ideas on how you can position this with your customer.
|
|
|
Feature Injection: Part One 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.
|
|
|
What Software Developers Can Learn from Their Cafeteria Did you know that Starbucks sells a cup size called "short"? It's a small cup that is less expensive than the other cup sizes. They never mention it on their menu; you have to know it exists before you can order one. Why? By having a smaller, cheaper option, they give their budget-conscious customers an opportunity to pay for coffee rather than go without. This kind of thinking has important repercussions to software developers.
|
|
|
Refactoring Doesn’t Mean Rewrite 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 Ghost of a Codebase Past Revisiting your old code can be an enlightening experience. Pete Goodliffe encourages us to look back at our old code to see how our technique has improved, how our programming skills have progressed, and what we can learn from it.
|
|
|
Encapsulation and Vampires Encapsulation is more than just using the "private" keyword when defining a class. You need a boundary that keeps the vampires out.
|
|
|
A Gram of Prevention Following an "I-click-therefore-I-Program" methodology does not lead to quality software. Good code can and should evolve from clear, up-front descriptions of the solution to the problem at hand.
|
|
|
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
|