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!

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 www.oneseat.eu 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.

The YAGNI development assistent

From xp.c2.com:
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 ...

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 www.construx.com). 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.

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.

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

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

Usability testing with Children

Usability testing with children is similar in many respects to usability testing with adults.
But in order to get the most out of the sessions, and ensure the child is comfortable and happy, there are a few differences that you need to be aware of.

(Read about in on Tim Fidgeon's Feature: Usability testing with Children)

Among the differences that drew my attention were the importance of non-verbal cues, because

• Children might be too shy
• Children might not want to say the wrong thing and displease an adult
• Children might say things they don't believe just to please the adult

So its very important to be sensitive to children's non-verbal cues, such as:

• Sighs
• Smiles
• Frowns
• Yawns
• Fidgeting
• Laughing
• Swaying
• Body angle and posture

I personally think the whole article applies equally well to Usability testing with Older people.

Postings: Analysis and Design

Analysis and Design
Moving on and making place ...

Patterns & Patterns

Sixty-three Habits

Dilbert on doing Requirements before Design

The waterfall process is back!

Some OOP and Design Pattern Resources

Feature Driven Development

The 8 Types of Navigation Pages

Value-Centered Design

**LOTS*** of resources for web design

Understanding the limited value of Wireframes

Good Designer Redesign, Great Designers Realign

Bang.Head.On.Desk

The value of breadcrumbs

Do's and don’ts for Technical Leads

Traceability Management through Use Cases

A quick introduction to LINQ by Anders Hejlsberg

Just because you aren't at PDC, doesn't mean you can't get the slides.

How to create a user-friendly website for the typical web visitor

Cross-Browser Compatibility Checking

User Interface Design - some (very) bad designs

User Interface Patterns and Techniques

Oracle's design patterns make Sahil Malik say YUCK!

Gartner Magic Quadrant for Web Services Platforms, 2005

Modeling service-oriented solutions with RUP

Crossing the chasm

Tips and examples for artifact types used for (Agile) Modeling

Best practice: code talking!

Do we need design specs anyway?

Tools with UML 2 support

Stu Nicholls can learn you *a lot* on css

Grady Booch on Rational's development strategy and the competition from Microsoft

Thin, Thick and Smart clients - what's the difference

Chris Anderson - Video of this architect explaining the Avalon architecture

wireframing or prototyping

Currently there are lots of discussions on the use of wireframing with tools such as Dreamweaver of Visio or Powerpoint. Some argue that we should move away from wireframing altogether start prototyping.

In Your Designs are Modular, but are your Artifacts? Nathan Curtis elaborates on ways to improve reuse in wireframing.

None of the errors found

Lidor Wyssocky (yes the same as in my previous post) runs a Blog on Optimizing Software Development.

Lidor warns about using test coverage metrics as they may create the illusion you are doing well, when you are not.

Problem is that test coverage metrics are always related to what's in the code, the problem is that lots of bugs are caused by what is NOT in the code.

This reminds me of a fine compiler we used at the Nijmegen university some 20 years ago.
If a program compiled fine, the program would show the message:

"None of the errors found" ...

The Five-Step Program For Overcoming Management Lies

Lidor Wyssocky posted a five-step program for overcoming the Management Lies Kathy Sierra posted about. Nice reading.

He included a step in case you risk becoming a manager yourself in the future ...