Matvii Hodovaniuk Notes

Before the project

The Requirements Pit #

Perfection is achieved, not when there is nothing left to add, but when there is nothing left to take away….

Don't Gather Requirements—Dig for Them

Digging for Requirements #

Policy may end up as metadata in the application.

Gathering requirements in this way naturally leads you to a system that is well factored to support metadata.

Work with a User to Think Like a User

Documenting Requirements #

Use "use cases"

Overspecifying #

Requirements are not architecture. Requirements are not design, nor are they the user interface. Requirements are need.

Seeing Further #

Abstractions Live Longer than Details

Just One More Wafer-Thin Mint… #

What can we do to prevent requirements from creeping up on us?

The key to managing growth of requirements is to point out each new feature's impact on the schedule to the project sponsors.

Maintain a Glossary #

It's very hard to succeed on a project where the users and developers refer to the same thing by different names or, even worse, refer to different things by the same name.

Use a Project Glossary

Get the Word Out #

Publishing project documents to internal Web sites for easy access by all participants.

Solving Impossible Puzzles #

Degrees of Freedom #

The key to solving puzzles is both to recognize the constraints placed on you and to recognize the degrees of freedom you do have, for in those you'll find your solution.

Don't Think Outside the Box—Find the Box

There Must Be an Easier Way! #

If you can not find the solution, step back and ask yourself these questions:

Not Until You're Ready #

If you sit down to start typing and there's some nagging doubt in your mind, heed it.

Listen to Nagging Doubts—Start When You're Ready

Good Judgment or Procrastination? #

Start prototyping. Choose an area that you feel will be difficult and begin producing some kind of proof of concept, and be sure to remember
why you're doing it and that it is a prototype.

The Specification Trap #

Writing a specification is quite a responsibility.

You should know when to stop:

Some Things Are Better Done than Described

Circles and Arrows #

Don't Be a Slave to Formal Methods

Formal methods have some serious shortcomings:

Do Methods Pay Off? #

Never underestimate the cost of adopting new tools and methods.

Should We Use Formal Methods? #

Absolutely but remember that is just one more tool in the toolbox.

Expensive Tools Do Not Produce Better Designs

← Home