Archive for May, 2006

Lost in code

On Lidor Wyssocky’s Blog on Optimizing Software Development is a post stating that you should not make your successors feel lost in your code.

Lidor uses a metaphoric story about a person being lost in a city, even though he found a map (which just *might* be of that city).

Clue is: A map is no use unless you know where you are!

Lidor concludes that having a high-level annotated map of the code (helping your successors to find out where in the code they are) reduces maintenance costs.

Sound conclusion!


Leave a Comment

one million signatures for one seat

It costs European taxpayers approximately 200 million euros a year to move the European Parliament between Brussels/Belgium and Strasbourg/France. As a citizen of the European Union you can participate in the debate on European issues by signing an online petition on if you want the European Parliament to be located only in Brussels.

One million signatures is what it needs to get this subject on the agenda of the European Commision.

Leave a Comment

The YAGNI development assistent

YouArentGonnaNeedIt (often abbreviated YAGNI, or YagNi on this wiki) is an ExtremeProgramming practice which states:

“Always implement things when you actually need them, never when you just
foresee that you need them.”

Now there is a development assistant available to help you …

Leave a Comment

Getting Software Projects Back on Track

In the last years I read lots of books on software engineering and consumed hundreds of best practices describing how to get a good start and to keep your project on track. Most software engineering books target on keeping your project out of trouble.

A book that I read (more than once) from cover to cover is the Software Project Survival Guide from Steve McConnell, which also deals with staying out of trouble and even includes a thorough test to check the health of your project (the test is available online at As Steve states, this is a difficult test for most projects as many will only score "Fair" and many will score "At Risk".

I recently ran into a book that focusses on getting software projects back on track.

E.M. Bennatan shows how to:

  • Evaluate where your project really stands
  • Align your project’s developers, managers, and customers
  • Define the minimum acceptable project goals that are achievable
  • Replan your project to successfully deliver the new minimum goals
  • Identify risks in your revised project and create effective contingency plans
  • Install an “early warning system” to keep your rescued project from slipping back toward catastrophe

A sample chapter of the book is available.

Leave a Comment

Open Source Requirements Management Tool

Recently a free open source Requirements Management Tool was released. It's a release 1.0 version.

Open Source Requirements Management Tool is designed to achieve full SDLC traceability for features, requirements, design, implementation, and testing. It has a UI for requirements derivation, version control, and common or custom attributes (rationale, source, risk, effort, etc.). It is suitable for product managers, developers, and analysts to collaborate with flexibility and scalability.

I did not have time to install an try it, but I definitely will.

Leave a Comment

Making your software process leaner

Mary Poppendieck had a keynote session on Star East ('The Greatest Software Testing Conference on Earth) with an attention-drawing title:

"Your Development and Testing Processes Are Defective"

Mary offered four suggestions (summerized here by The Braidy Tester who attended) for putting your software development process on a diet:

  1. Eliminate waste. Focus on what adds value for your customers and drop everything else.
  2. Don't tolerate defects. Inspect to prevent defects, not to find them. Don't just log bugs but rather fix them as soon as you find them.
  3. Don't batch and queue. Don't leave bugs lying around; either fix them or Won't Fix them the moment they come in. If you have requirements churn then you are specifying too early, and if you have test-and-fix cycles you're testing too late.
  4. Optimize the whole. Optimize the whole product, which is not just software but a comprehensive solution that solves a customer problem. Optimize your whole team: Dev and Test and Program Management, not just Dev or Test or PM. Optimizing for point productivity drags down overall productivity. Counterintuitive though it may be, letting one group go idle for awhile will often speed up overall throughput.

Mary Poppendieck elaborated on similar points in publications on her site

Leave a Comment

More Usability Publications and Guidelines

Microsoft has lots of Published Materials from Microsoft's usability community.

Among these also Hanna, Risden & Alexander's Guidelines for usability testing with children.
Even thought it is an older publication (1997), Tim Fidgeon (from my previous post) definitely read this part:

Gauge how much children like a program by observing signs of
engagement such as smiles and laughs or leaning forward to
try things, and signs of disengagement such as frowns, sighs,
yawns, or turning away from the computer.
These behavioral signs are much more reliable
than children’s responses to questions about whether or
not they like something

Leave a Comment

Older Posts »