Matvii Hodovaniuk Notes

A Pragmatic Approach

The Evils of Duplication #

The problem arises when you need to change a representation of things that are across all the code base.
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

DRY—Don't Repeat Yourself

Types of duplication:

Make it easy to reuse

Orthogonality #

Two or more things are orthogonal if changes in one do not affect any of the others. Also called cohesion.
Write "shy" code.

Eliminate Effects Between Unrelated Things

Benefits:

Reversibility #

Be prepared for changes.

There are no Final Decisions.

Tracer Bullets #

In new projects your users requirements may be vague. Use of new algorithms, techniques, languages, or libraries unknowns will come. And environment will change over time before you are done.
We're looking for something that gets us from a requirement to some aspect of the final system quickly, visibly, and repeatably.

Use Tracer Bullets to Find the Target

Advantages:

Tracer Bullets Don't Always Hit Their Target #

Tracer bullets show what you're hitting. This may not always be the target. You then adjust your aim until they're on target. That's the point.

Tracer Code versus Prototyping #

With a prototype, you're aiming to explore specific aspects of the final system.
Tracer code is used to know how the application as a whole hangs together.

Prototyping generates disposable code.
Tracer code is lean but complete, and forms part of the skeleton of the final system.

Prototypes and Post-it Notes #

We build software prototypes to analyze and expose risk, and to offer chances for correction at a greatly reduced cost.

Prototype anything that:

Samples:

Prototype to Learn

Avoid details:

Prototyping Architecture:

Never deploy the prototype

Domain Languages #

Program Close to the Problem domain

Estimating #

Estimate to Avoid Surprises

How Accurate Is Accurate Enough? #

First: Do they need high accuracy, or are they looking for a ballpark figure?

Second: Scale time estimates properly

Duration Quote estimate in
1-15 days days
3-8 weeks weeks
8-30 weeks months
30+ weeks think hard before giving an estimate

Where Do Estimates Come From? #

Ask someone who's been in a similar situation in the past.

Estimating Project Schedules #

The only way to determine the timetable for a project is by gaining experience on that same project.
Practice incremental development, repeating the following steps:

The refinement and confidence in the schedule gets better and better each iteration

Iterate the Schedule with the Code

What to Say When Asked for an Estimate #

"I'll get back to you."

Challenges #

Start keeping a log of your estimates. For each, track how accurate you turned out to be. If your error was greater than 50%, try to find out where your estimate went wrong.

← Home