definitely a book worth the time of managers with inadequate software development background
Do you view books aimed at helping high-level managers understand your job with grave suspicion? Let me quote a paragraph from the introduction (it will also help you grasp the author's writing style)
On your next coast-to-coast redeye, have the flight attendant pour you a double of your favourite beverage, turn on the overhead light (which, of course, will really tick off the guy trying to sleep in the seat next to you), and dig in. You can finish the whole book before the plane begins its descent. The best part is, by the time you land, you'll know enough to tell that techNOBULLy in your IT department a thing or two about a thing or two. Have at it and have fun! If you have questions or comments about this book, please contact me via...
Scary or what? Do you want to turn your top level managers into know-it-alls? Of course not. But think again, would you like them to have a balanced, realistic view of what you can achieve? Well try this quote and see if it changes your response to the first one.
The most dangerous thing a group that's new to object technology can do is to rush into it and try it out on a major project. There are all kinds of horror stories about outrageously expensive object-oriented software systems that were delivered late, over budget, and dead on arrival. Almost universally these stories are about some organization's first attempt at object-oriented software development. Never, never, never make a mission-critical system your first object-oriented project. You will fail. It doesn't matter how good your people are or how big a deal the consultant is. Unless you plan to fire everybody and start over from scratch with a staff of experts, don't even think about it. Even if you did try the scorched earth approach, you'd probably still fail because the new people won't know enough about your business.
I have every confidence that this book is firmly planted in reality. Managers who read it and take on board what the author says will be better for the company and better for you. The problem is how to get the problematic manager to read it in the first place. There I cannot help you. You will have to apply guile and subtlety but I think it might be worth the effort. Now a sneaky thought flittered through my mind just now; how do you get that fanatic OO enthusiast in your team to read this book and stop making stupid promises to management that the rest of you find yourselves expected to live up to?
This is not a book for programmers, but it might be a book for those who only think they are, and it is definitely a book worth the time of managers with inadequate software development background.
