The Java Specialists' Newsletter
Review: The Secrets of Consultingby Dr. Heinz M. KabutzAbstract:
How much do your customers love you? How should you give and receive advice? In this excellent book, we learn why it is so important to understand your customer. I use the principles daily in my work with code reviews, performance tuning and dealing with customers or clients.
Welcome to the 48th edition of The Java(tm) Specialists' Newsletter, sent to 3661 Java experts in over
In this newsletter you are not a number, you are more than that.
Yes, every one of my subscribers is an email address ;-) This
week's newsletter is again rather philosophical - please excuse
me, all my life I wanted to be a Philosopher :-)
After my traffic saga at the beginning of this year, I had the
pleasure this morning of sorting out the shrapnel. I had sent a
cheque to the provincial traffic department listed on the fine.
One month later (I kid you not), the cheque was processed by the
department and they discovered that the cheque was not bank
guaranteed (as if I would try and rip off the police by sending
a cheque that was not covered?!). Instead of writing a letter
telling me about it, they sent me a registered letter two and a
half months later, which I received this morning, telling me that
I had missed my court appearance. The disturbing thing about it
is that this letter was sent more than 100 days after I had sent
the original cheque. So, my fine has now been tripled because I
now also have a "contempt of court" fine. This morning I had to
pick up the pieces, waiting for about 20 minutes to get through
to the accounts department of the court. When I finally got
through, I was told that they cannot give me my account status as
they do not have a computer, but I could
gladly make an appointment to come in and speak to the
magistrate. This morning was spent writing a letter of protest
and getting a bank guaranteed cheque from the bank, so I hope
that I will not hear from them again.
Please see our new "Extreme Java" course, combining
concurrency, a little bit of performance and Java 8.
Extreme Java - Concurrency & Performance for Java 8.
A Guide to Giving & Getting Advice Successfully
The book that I want to write about this week is not really a
Java book. Infact, it was written about ten years before Java
was first released. However, this is a fantastic book on giving
advice, receiving advice and getting your advice accepted. I
have mentioned this book to many people, but no-one that I have
spoken to had heard of it. I therefore have to conclude that the
gems contained in this book truly are still "secrets".
write to me if you have read the book.
Why would I even bother talking about books that have absolutely
no relation to Java? The reason is simple: I have asked some
of you what problems relating to Java occur in your companies. The majority of
problems occur because of people, rather than technology. You
might be highly enthusiastic about Kent Beck's ideas in
eXtreme Programming Explained, but
your colleagues and manager are more interested in "getting the
job done" than in fancy new agile methodologies. (Not that the
ideas are new, many of them were described in
The Psychology of Computer Programming
in 1971, the year in which I was born. Actually, the majority of
our newsletter authors were born in 1971 - a good crop ;-)
You might want to promote Java, but your colleagues are stuck
with C++. Perhaps you think that Design Patterns are the way to
go, but you are the only one in the company who thinks that.
This book is going to help you. It is going to help you to
effectively give advice to your colleagues, managers and
customers. I discovered this book by accident. About two years
ago, Amazon recommended the book to me (the way they usually
recommend irrelevant books). I would love to say that I
immediately bought it, but I waited, and by the time I got to
wanting to purchase the book, Amazon had no more stock.
After much trouble, I eventually got my hands on a copy, and
believe me, only my very best friends get to read it. I usually
require their cars as deposit so that I will get the book back ;-)
What is really great about this book is that Weinberg presents
his advice with stories, so each advice has a name that is very
easy to remember. Here are some extracts from the book,
shortened to save space. All quotes are in italics:
Prescott's Pickle Principle
"... My grandpappy used to tell a story about a stubborn
cucumber. When he put it in the barrel, it looked around at the
other cukes and was revolted by what had happened to them.
'Dadgum it,' he cursed. 'What's the matter with you guys? Have
you no pride? No self-respecting cucumber would let himself get
pickled without putting up a fight.'
"'But what can we do?' they'd ask. 'You can resist, that's what
you can do. That's what I'm gonna do. No brine is going to get
under my skin.'
Then grandpappy would stop, and I would always ask him, 'What
happened to the stubborn cucumber?'"
"And what did he say?" I asked.
"He said, 'Don't be foolish, boy. If you stay in the brine long
enough, you become a pickle.'"
i.e. Cucumbers get more pickled than brine gets cucumbered.
i.e. A small system that tries to change a big system through
long and continued contact is more likely to be changed itself.
I like this advice. It tells me that if I hang around too much
as a consultant within a company, I will not be effective
anymore. It tells me that if I am in a situation which is much
bigger than me, chances are that I will be changed myself. I
felt that happen to me when I was a permanent employee. With my
first paycheque, I was very enthusiastic. However, as I stayed
longer, I felt that I was changing. I was starting to bicker and
moan about company policies. I was no longer researching
new technologies, because "the company" was supposed to send me
on training. As with all companies, when it came to
actually going on courses, there was either no time or no money in
the training budget.
I am not suggesting that leaving your company is the right step
for you. Being an independent contractor is only for people with
a specific mindset. Only do it if you don't like sleeping, or if
you cannot live unless you are completely stressed out. For some
interesting insights about various roles that we fulfill in life,
have a look at Robert Kiyosaki's Cashflow
How about another one:
The Law of the Hammer
"The Child who receives a hammer for Christmas will
discover that everything needs pounding."
How often have you been in the situation where a company had
decided to use Rational Unified Process / UML / XP / whatever,
and this single fact would sort out all their problems? No
matter how much you tell your boss that Java is not a good idea
for the next generation of Quake, he just will not listen. He
is holding the Java hammer. I am not saying that any of the
methodologies I mentioned are bad, I'm just saying that you have
to apply them in the correct context.
I find the term "Software Factory" extremely amusing. My father
runs a drinking straw factory (yes, someone has to make them).
On the one side of the process you have an extruder which pushes
out hot plastic and on the other side the straws come out,
hygienically wrapped in plastic film. Having spent many hours
working in factories, I am quite aware of how a factory works,
and for the life of me cannot visualise software being produced
the way that a factory produces straws. OK, besides the heap of
scrap plastic that gets generated every month, that is possibly
Weinberg gives us some laws about consulting that make a lot of
sense. They seem quite controversial, especially the third one,
but if you think about it a while, you'll realise he's telling
the truth. In his book he also goes into a lot more detail of
why his rules work.
Laws of Consulting
The First Law of Consulting: In spite of what your
client may tell you, there's always a problem.
The Second Law of Consulting: No matter how it looks at
first, it's always a people problem.
The Third Law of Consulting: Never forget they're
paying you by the hour, not by the solution.
The Fourth Law of Consulting: If they didn't hire you,
don't solve their problem.
Don't bother asking me if you can borrow my copy of this book.
This is one fantastic book for anyone who uses consultants, or for someone who gives advice. Amazon's
customer have rated this book with an average of more than 4.5
stars. As I said earlier, this book has nothing to do with Java,
but it has everything to do with people. The problems you will
find most of the time are directly related to people problems,
rather than Java. Just remember this the next time you are told
that your multi-billion dollar company cannot afford to pay for
a license of a profiler to help solve your memory leak problems.
One last one, that I found very valuable: Clients always know
how to solve their problems, and always tell the solution in the
first five minutes. Try it out next time.
For those of you who like to purchase books via Amazon, you can
get there directly via this link.
Book Review Articles
Related Java Course