Welcome to the 48th edition of The Java(tm) Specialists' Newsletter, sent to 3661 Java experts in over 82 countries. 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.
We have revised our "Advanced Topics" course, covering Reflection, Java NIO, Data Structures, Memory Management and several other useful topics for Java experts to master. 2 days of extreme fun and learning. Extreme Java - Advanced Topics.
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". Please 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:
"... 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 Quadrant.
How about another one:
"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 relevant.
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.
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.
Would you like to receive our monthly Java newsletter, with lots of interesting tips and tricks that will make you a better Java programmer?