|
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.
|
|
|
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.
|
|
|
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.
|
|