Programming Pearls

Source Unknown

A useful comment explains WHY, uncovering the reasoning behind a specific decision.

The Mythical Man Month

By Frederick P. Brooks, Jr.

The challenge and the mission are to find real solutions to real problems on actual schedules with available resources.

Fostering a total-system, user-oriented attitude may well be the most important function of the programming manager.

Since [a manager’s] fundamental job is to keep everybody going in the same direction, his chief daily task will be communication, not decision-making, and his [formal] documents will immensely lighten this load.

The task of the manager is to develop a plan and then to realize it. But only the written plan is precise and communicable.

The programmer delivers satisfaction of a user need rather than any tangible product. And both the actual need and the user’s perception of that need will change as programs are built, tested, and used.

Plan the System for Change. Plan the Organization for Change

From section headings

By documenting a design, the designer exposes himself to the criticism of everyone, and he must be able to defend everything he writes. If the organizational structure is threatening in any way, nothing is going to be documented until it is completely defensible.

A reassignment from the technical ladder to a corresponding level on the manager one should never be accompanied by a raise, and it should be announced always as a “reassignment”, not a promotion. The reverse reassignment should always carry a raise; overcompensating for the cultural forces is necessary.

Managers need to be sent to technical refresher courses, senior technical people to management training.

Whenever talents permit, senior people must be kept technically and emotionally ready to manages groups or to delight in build programs with their own hands. Dong this surely is a lot of work; but it surely is worth it!

12 – Sharp Tools

Sustained concentration reduces thinking time.

Practical Object-Oriented Design: An Agile Primer Using Ruby

by Sandi Metz

1 – Object-Oriented Design

Designs that anticipate specific future requirements almost always end badly. Practical design does not anticipate what will happen to your application; it merely accepts that something will and that, in the present, you cannot know what. It doesn’t guess the future; it preserves your options for accommodating the future. It doesn’t choose; it leaves you room to move.

The purpose of design is to allow you to do design later, and its primary goal is to reduce the cost of change.

How Design Fails

Successful but un-designed applications carry the seeds of their own destruction; they are easy to write but gradually become impossible to change.

[Over-designed applications] apply principles inappropriately and see patterns where none exist.

[Mis-designed applications are ones where their] design is dictated from afar, [and] none of the necessary adjustments can occur and early failures of understanding get cemented into the code. [These are] applications designed by isolated experts.

The Agile experience is that…collaboration produce software that differs from what was initially imagined; the resulting software could not have been anticipated by any other means.

Agile works because it acknowledges that certainty is unattainable in advance of the application’s existence; Agile’s acceptance of this truth allows it to provide strategies to overcome the handicap of developing software while knowing neither the target nor the timeline.

Agile processes guarantee change, and your ability to make these changes depends on your application’s design.

Agile thus does not prohibit design, it requires it. Not only does it require design, it requires really good design. It needs your best work. Its success relies on simple, flexible, and malleable code.

OOD metrics cannot identify designs that do the wrong thing in the right way.

Objects have behavior and may contain data, data to which they alone control access. Objects invoke one another’s behavior by sending each other messages.

Every newly instantiated String implements the same methods and uses the same attribute names, but each contains its own personal data. They share the same methods, so they all behave like Strings; they contain different data, so the represent different ones.

Knowledge of an object’s type(s) therefore lets you have expectations about the messages to which it responds.

Each OO application gradually becomes a unique programming languages that is specifically tailored to your domain.

Whether this language ultimately brings you pleasure or gives you pain is a matter of design.

2 – Designing Classes with a Single Responsibility

Design is more the art of preserving changeability than it is the act of achieving perfection.

3 – Managing Dependencies

Depend on things that change less often than you do.

4 – Creating Flexible Interfaces

[Object-oriented applications are] made up of classes but defined by messages.