🚀 go-pugleaf

The Art of OOP&D (in C++)
(in a big company, team programming environment)
by John Maling

PART I (If this is favourably received there will be additional parts,
otherwise this is it.)

as inspired by...
SUN TZU ON THE ART OF WAR as Translated from the Chinese
By LIONEL GILES, M.A. (1910) (in the Public Domain)

Let the Project Manager heed my words and be victorious
-------------------------------------------------------
The Art of Object Oriented Design and Programming (OOD&P) is of vital
importance. It is a matter of the life or death of software, a road to
safety or to ruin. Hence it is a subject which can on no account be
neglected. The art of OOD&P, then, is governed by five constant factors,
to be taken into account in one's deliberations, when seeking to determine
the conditions obtaining in the specification.

These are: (1) The Moral Law; (2) Heaven; (3) Earth; (4) The Project
Manager; (5) Method and Discipline.

The Moral Law causes objects to be in complete accord with their messages,
so they will follow them regardless of their own state, undismayed by any
danger.

Heaven signifies programming day and night to meet a deadline, hot and
cold sweats, compile times and seasonal office parties.

Earth comprises distance to the coffee machine, java and expresso;
consultancy Vs tenure; public classes and private classes; the chances of
life and death.

The Project Manager stands for the virtues of wisdom, sincerely,
benevolence, courage and strictness......err......well...... the last one
anyway.

By method and discipline are to be understood the marshalling of the
classes in their proper groupings, the graduations of inheritance among
the classes, the maintenance of pathways by which messages may reach the
classes, and the control of CPU cycle expenditure.

These five heads should be familiar to every Project Manger: he who knows
them will be victorious; he who knows them not will fail. Therefore, in
your deliberations, when seeking to determine which Team should be given a
project, let them be made the basis of a comparison, in this wise: 

(1) Which of the two Teams is imbued with the Moral law? 
(2) Which of the Teams classes has the most re-useability? 
(3) With whom lie the advantages derived from Heaven and Earth?
(4) On which side is abstraction most rigorously enforced?
(5) Which army of programmers is the more powerful?
(6) On which system are lead programmers and code hacks more highly trained? 
(7) Which Lead Programmer holds the greater constancy both in reward and
punishment?

By means of these seven considerations I can forecast victory or defeat.

The Project Manager that hearkens to my counsel and acts upon it, will
conquer: let such a one be retained! The Manager that hearkens not to my
counsel nor acts upon it, will suffer defeat: let such a one be dismissed!

Let now the Lowly Hack hear my words and gain wisdom by them
------------------------------------------------------------
Heed the profit of my counsel, oh Hack!, avail yourself also of any
helpful circumstances over and beyond the ordinary rules, like paid
lunches.

According as circumstances are favourable, one should modify one's control
models.

All programming is based on planning, and the deception of both the Lead
Programmer and Project Manager.

Hence, when able to program, we must seem unable; when using our classes,
we must seem inactive; when we are near to a solution, we must make them
believe we are far away; when far away, we must make them believe we are
near.

Hold out baits to entice the Marketing Department. Feign disorder, and
crush them with the news the product has not made Beta.

If the Project Manager is a programmer, be prepared for him. If he is a
GOOD programmer, evade him.

If the Lead Programmer is of choleric temper, seek to irritate him with
complex Boochian design notations. Pretend to be witless, that he may grow
arrogant. Then take the real designs to the Project Manager and complain
about your superior, that you may win his position.

If he is taking his lunch break, give him no rest. If he is in a briefing
with the Manager, interrupt them.

Attack him where he is unprepared, appear where you are not expected
(confront him in the toilet with your 'breakthrough' state transition
diagram)

These programming devices, leading to victory, must not be divulged beforehand.

Now the hack who writes great software makes many calculations in his
temple ere the program is written. The hack who writes buggy software
makes but few calculations beforehand. Thus do many calculations lead to
victory, and few calculations to defeat: how much more no calculation at
all! It is by attention to this point that I can foresee who is likely to
be able to debug their code.

Thus we may know that there are five essentials for victory: (1) He will
win who knows when to code and when not to code. (2) He will win who knows
how to handle both the Method and the Message. (3) He will win whose
design is consistent. (4) He will win who, prepared himself, waits to take
the Lead Programmer and Project Manager unprepared. (5) He will win who
has CPU capacity and is not interfered with by Upper Management.

Hence the saying: If you know the code and know yourself, you need not
fear to write a hundred programs. If you know yourself but not the code,
for every great program you will also write a pile of crap. If you know
neither the code nor yourself, you will soon be out of a job....

Let the Finance Department hear my words that they may better profit
---------------------------------------------------------------------
John Maling said: In the operations of programming, where there are in the
field a thousand derived classes, as many bloated functions, and a hundred
thousand mail-clad data structures, with message demands enough to absorb
a thousand CPU cycles, the expenditure on the mainframe and at the
terminal, including entertainment of guests, small items such as glue and
paint, and sums spent on chariots and armour, will reach the total of a
thousand ounces of silver per day. Such is the cost of writing a program
exceeding 1,000,000 lines of code.

When a team engages in programming, if completion of the project is long
in coming, their wits will grow dull and their ardour will be damped. If
they must lay siege to old source code, they will exhaust their strength. 

Again, if code maintenance is protracted, the resources of the Company
Programmers will not be equal to the strain.

Now, when their wits are dulled, their ardour damped, their strength
exhausted and your treasure spent, external contract programmers will
spring up to take advantage of your extremity. Then no man, however wise,
will be able to avert the consequences that must ensue.

Thus, though we have heard of stupid haste in bringing products to market,
cleverness has never been seen associated with long delays.

There is no instance of a company having profited from vaporware (at least
in no way the Finance Department can calculate!)

Poverty of the local branch office causes a team of hacks to be maintained
by contributions from head office. Contributing to maintain a team at a
distance causes the company to be impoverished because of their long lunch
breaks.

Let the Lead Programmer heed my words and be enriched!
------------------------------------------------------
It is only one who is thoroughly acquainted with the evils of structured
programming that can thoroughly understand the profitable path of OOD&P.

The skilful programmer does not duplicate class functionality, neither are
his messages dispatched more than once.

Bring classes with you from your own library, but forage on existing
classes. Thus the design will have classes enough for its needs.

On the other hand, the demands of creating new classes and reworking the
dynamic model cause anguish to increase; and anguish causes the
programmers substance to be drained away.

When a programmers substance is drained away, he will be afflicted by
heavy exactions.

With this loss of substance and exhaustion of strength, the offices of the
programmers will be stripped bare, and three-tenths of their income will
be dissipated; while the departments expenses for broken chariots,
worn-out horses, breast-plates and helmets, bows and arrows, spears and
shields, protective mantles, draught-oxen and heavy wagons, will amount to
four-tenths of its total revenue.

Then will the Demons of Finance grow restless, and earthquakes shake your abode.

As a torch can be spent, so can your programmers, pity the Team Leader
whose programmers burn out in a cave!

The acrid scent of burning hacks is an invocation to the Gods of Upper
Management, the Overseers whose visages are rarely seen save at times of
calamity or change.

The sane man in no wise invites Their attention.

Hence a wise Leader makes a point of foraging on existing classes. One
cartload of another's classes is equivalent to twenty of one's own, and
likewise a single object of his provender is equivalent to twenty from
one's own store.

Now in order to re-use classes, our programmers must be roused to anger;
and that there may be advantage for finding them, they must have their
rewards.

Therefore in searching for class re-use, when ten or more classes have
been found, those should be rewarded who found the first. Our own messages
should be substituted for those of the original code, and the objects
mingled and used in conjunction with ours. The captured classes should be
kindly treated and kept.

This is called, re-using classes to augment one's own program.

In all programming, then, let your great task be completion, not lengthy
feature lists.

Thus it may be known that the Lead Programmer is the arbiter of the
projects fate, and the manager on whom it depends whether the project
shall be in peace or in peril.

John Maling said: In the practical art of Object Oriented Design and
Programming the best thing of all is to take the enemy's program whole and
intact; to modify it is not so good. So, too, it is better to reuse a
whole class group than to separate it, to capture an abstract class, a
superclass or a derived class entire than to destroy them.

Hence to hack your way into another's code is not supreme excellence;
supreme excellence consists in entering the enemy's code without breaking
it in the process. This is the Greatest Purpose of OOD&P.

Thus the highest form of C++ is to use only the enemy's interfaces; the
next best is to use his class groups; the next in order is to isolate his
classes; and the worst policy of all is to besiege a mountain of source
code.

The rule is not to besiege source code if it can possibly be avoided. The
preparation of mantlets, movable shelters, and various implements of war,
will take up three whole months; and the drinking of coffee over endless
printouts will take three months more.

Yet, before a mountain of printout the greatness of OOD manifests itself,
while the Structured Programmer is cast down in confusion.

The foolish C Team Leader, unable to control his irritation, will launch
his programmers to the assault like swarming ants, with the result that
one-third of them are slain, while the code still remains
incomprehensible. Such are the disastrous effects of C.

The skilful C++ Team Leader subdues the enemies code without any fighting;
he captures their classes without laying siege to them; he uses their
functionality without lengthy operations inside the class methods. With
his forces intact he will dispute the mastery of the Project, and thus,
without losing a single hack, his triumph will be complete. This is the
method of attacking programming through OOD&P.

Let Senior Management now profit from my counsel
------------------------------------------------
It is the rule in Company battle, if our assets are ten to the enemy's
one, to purchase him; if five to one, to attack him in the marketplace; if
twice as numerous, to split off a new company.

If equally matched, we can offer battle; if slightly inferior in size, we
can avoid his best selling products; if quite unequal in every way, we can
flee from him into niche markets.

Though an obstinate fight may be made by a small company, in the end it
must be captured by the larger company.

Now Upper Management is the bulwark of the Company; if the bulwark is
complete at all points; the Company will be strong; if the bulwark is
defective, the Company will be weak.

There are three ways in which Senior Management can bring misfortune upon
its programmers: 

(1) By commanding the hacks to write an application before conceiving the
Dynamic Model, being ignorant of the fact that they cannot obey. This is
called hobbling the programmers.

(2) By attempting to govern hacks in the same way as they administer
Marketing, being ignorant of the conditions which obtain amongst the
hacks. This causes restlessness in the programmers minds.

(3) By employing Project Managers without discrimination, through
ignorance of the Hacks principle of Creative Anarchy. This shakes the
confidence of the programmers.

And when the programmers are restless and distrustful, trouble is sure to
come from other software companies. This is simply bringing anarchy into
the Company, and flinging victory away.

END Part I
----------
This lot was conceived out of a dreamy mix of four hours per day of train
travel, during which time I read 'The Art of War' by Sun Tzu and
'Designing Object-Oriented C++ Applications Using the Booch Method' by
Robert C. Martin.

After three days without programming life becomes meaningless. <unknown>