Brian On Software

A couple of weeks ago, some guys from work invited me to participate in a video contest for our region.  Little did I know was a $1000 cash prize to be won…which we did won, ladies and gentlemen!  So the four of us equally divided the prize which allowed us to earn $250 each for a half an hour activity.  Not bad!  I was wondering what I could do with that easy earned money.  Invest it in a retirement funds? Nah.  Give half to my wife? Nah. Since I’m an avid reader of books, I thought that it would be nice to get a hold of some good books on software development.  Even though I’ve got over thirty books on software development and engineering, I wanted to get some dealing with patterns and principles in software design because those kind of books transcend time and technology.

Here are the books I bought with the easiest and fastest $250 earned in my life:

• Agile Principles, Patterns, and Practices in C# by Robert C. Martin
• Working Effectively with Legacy Code by Michael Feathers
• Refactoring to Patterns by Joshua Kerievsky
• xUnit Test Patterns by Gerarld Meszaros
• Object Thinking by David West

I’ve actually started reading one of them, “Object Thinking“, and I have to tell you that it’s by far one of the best book I’ve read on object design.  What books would you have bought had you be given a similar amount of easy money?

After reading The Dip: A Little Book That Teaches You When to Quit (and When to Stick) from best-seller author, marketing guru and prolific blogger Seth Godin, I couldn’t wait but to read another one of his writings.  This time I settled for The Big Moo, a collection of over thirty essays focused on showing you how and why you and your organization should thrive to be remarkable.  In Seth Godin’s words: "Stop trying to be perfect and start being remarkable".  At first, I was hit by the book’s title, but after reading a few pages, it all made sense.  Here’s what the front cover has to say about what the big moo is all about:

As Seth Godin said in his widely quoted best-seller Purple Cow, first you need to stop being a brown cow - in a field of hundreds of other brown cows - and dare to be purple.  But after a while, that’s not enough.  You need a big moo, an extreme purple cow, an innovation that completely changes the game.

With the collaboration of "33 of the world’s smartest business thinkers", including Malcolm Gladwell, Tom Peters, Guy Kawasaki, Marc Benioff, etc., this book is truly a collection of 21st-century wisdom for any organization that’s looking for a way or a purpose to reach a higher plateau in the way business is done with people.  As stated in the back cover:

The Big Moo tells their stories.  Stories that will stick to your ribs, light your fire, and give you flashes of inspiration.  Stories about memorable customer service, amazing dedication, daring design standards, and legendary leadership.  The Big Moo will help you drive growth and change in your organization, from the mail room to the boardroom to the front lines.

No doubt that being remarkable (in the eye of the customer) will give you an edge over your competition that’s simply doing business.  But The Big Moo is not just for growing and differentiating organizations.  It’s also a valuable asset to help YOU grow both on a personal and professional level too!  In case you haven’t noticed, you are also in competition with other people when it comes to signing a contract for a job, a music record, a part in the school’s play, etc. 

I don’t want to say too much about this 177-pages book because I rather let you discover its fruits on your own.  While reading it daily on my way to work and back home, I realized that each single essay had something inspiring and concrete that could easily apply to my personal and professional life.  Speaking of essays, you never know which collaborator wrote an essay because each one of them is anonymous…neat, huh?  Also, we are recommended to share some of these essays publicly without any legal constraints.  Therefore, I will share with you three essays that struck me profoundly in further posts so that you can get a better taste of what the book has to offer.  So stay tuned! 

Meanwhile, I highly recommend anyone in your organization that has a role of leadership to get a copy of The Big Moo and share the stories with the rest of the organization.  Even better…Get some people in your organization to participate in writing their own remarkable stories and publish them either on your intranet or on the Web.  Let the "purple cow" in you run free from any boundary!

In the July 2008 issue of IEEE Spectrum magazine, Newsweek senior editor Steven Levy writes about the “10 Great Tech Books”.  If you’ve read my posts on how to become a more valuable software professional and how to improve as both a professional and an individual through reading, you’ll pretty much guess that I’m a book fanatic.  I praise God that he gave us two little instruments between our nose that can “deserialize” whatever is in front of us so we can visualize it through our brain.  They’re just so wonderfully made and useful that it’s a shame that we don’t exploit them more conveniently through reading, especially us in the tech business.  Therefore, I think it proves right to share with you this list of tech books you might want to ask for Christmas or get a hold of somehow. 

I was very surprised to realize that none of these books were registered in my brain…in fact I’ve never heard of them neither at university nor at work.  That little point alone should suffice to encourage you (especially if you’re a student) to become a member of the IEEE Computer Society in order to receive valuable information related to technology and business that you might not necessarily get through academia or at the job.  All right, enough ranting.  Here’s the list of the 10 great tech books according to Steven Levy, which he starts off with the following thought:

Any great nonfiction book combines education with entertainment.  In drafting my A-list of general-interest books about technology, I considered impact and significance but gave still more weight to the reading experience.  This is a collection where lay readers can appreciate each entry – and engineers, programmers, and other tech professionals can’t afford to miss a single one.

• The Pencil: A History of Design and Circumstance by Henry Petroski (Knopf, 1989)

From Amazon’s editorial review:

Like most other human artifacts, the common pencil, made and sold today by the millions, has a long and complex history. Henry Petroski, who combines a talent for fine writing with a deep knowledge of engineering and technological history, examines the story of the pencil, considering it not only as a thing in itself, but also as an exemplar of all things that are designed and manufactured.

Petroski ranges widely in time, discussing the writing technologies of antiquity. But his story really begins in the early modern period, when, in 1565, a Swiss naturalist first described the properties of the mineral that became known as graphite. Petroski traces the evolution of the pencil through the Industrial Revolution, when machine manufacture replaced earlier handwork. Along the way, he looks at some of pencil making’s great innovators–including Henry David Thoreau, the famed writer, who worked in his father’s pencil factory, inventing techniques for grinding graphite and experimenting with blends of lead, clay, and other ingredients to yield pencils of varying hardness and darkness. Petroski closes with a look at how pencils are made today–a still-imperfect technology that may yet evolve with new advances in materials and design. –Gregory McNamee

• Mirror Worlds; or, The Day Software Puts the Universe in a Showbox…How It Will Happen and What It Will Mean by David Gelernter (Oxford University Press, 1991)

From Amazon’s editorial review:

With evangelical fervor, Gelernter’s book-length essay paints a future where software technology, now isolating people, brings them into impersonal proximity through "mirror worlds." These computer models of reality let users descend to greater depths of detail at will, meet other explorers, and generally get the "big picture" of what’s going on. However, Gelernter’s own appraisal of the value of computers seems inconsistent and extreme: he claims they are valuable just sitting unused on the coffee table but then insists that the uninitiated will be forced to "sink or swim" (i.e., learn to use computers) in the information sea computers create. His casual style gives the book the feel of a lecture transcript, and his metaphors (e.g., "jettisoned floating landscapes in tuple space") demand considerable hardware and software knowledge to link them with reality. For collections emphasizing computer science.

• A New Kind of Science by Stephen Wolfram (Wolfram Media, 2002)

From Amazon’s editorial review:

Physics and computer science genius Stephen Wolfram, whose Mathematica computer language launched a multimillion-dollar company, now sets his sights on a more daunting goal: understanding the universe. Wolfram lets the world see his work in A New Kind of Science, a gorgeous, 1,280-page tome more than a decade in the making. With patience, insight, and self-confidence to spare, Wolfram outlines a fundamental new way of modeling complex systems.

On the frontier of complexity science since he was a boy, Wolfram is a champion of cellular automata–256 "programs" governed by simple nonmathematical rules. He points out that even the most complex equations fail to accurately model biological systems, but the simplest cellular automata can produce results straight out of nature–tree branches, stream eddies, and leopard spots, for instance. The graphics in A New Kind of Science show striking resemblance to the patterns we see in nature every day.

Wolfram wrote the book in a distinct style meant to make it easy to read, even for nontechies; a basic familiarity with logic is helpful but not essential. Readers will find themselves swept away by the elegant simplicity of Wolfram’s ideas and the accidental artistry of the cellular automaton models. Whether or not Wolfram’s revolution ultimately gives us the keys to the universe, his new science is absolutely awe-inspiring. –Therese Littleton

• Gödel, Escher, Bach: An Eternal Golden Braid by Douglas R. Hofstadter (Basic Books, 1979)

From Amazon’s editorial review:

Twenty years after it topped the bestseller charts, Douglas R. Hofstadter’s Gödel, Escher, Bach: An Eternal Golden Braid is still something of a marvel. Besides being a profound and entertaining meditation on human thought and creativity, this book looks at the surprising points of contact between the music of Bach, the artwork of Escher, and the mathematics of Gödel. It also looks at the prospects for computers and artificial intelligence (AI) for mimicking human thought. For the general reader and the computer techie alike, this book still sets a standard for thinking about the future of computers and their relation to the way we think.

Hofstadter’s great achievement in Gödel, Escher, Bach was making abstruse mathematical topics (like undecidability, recursion, and ’strange loops’) accessible and remarkably entertaining. Borrowing a page from Lewis Carroll (who might well have been a fan of this book), each chapter presents dialogue between the Tortoise and Achilles, as well as other characters who dramatize concepts discussed later in more detail. Allusions to Bach’s music (centering on his Musical Offering) and Escher’s continually paradoxical artwork are plentiful here. This more approachable material lets the author delve into serious number theory (concentrating on the ramifications of Gödel’s Theorem of Incompleteness) while stopping along the way to ponder the work of a host of other mathematicians, artists, and thinkers.

The world has moved on since 1979, of course. The book predicted that computers probably won’t ever beat humans in chess, though Deep Blue beat Garry Kasparov in 1997. And the vinyl record, which serves for some of Hofstadter’s best analogies, is now left to collectors. Sections on recursion and the graphs of certain functions from physics look tantalizing, like the fractals of recent chaos theory. And AI has moved on, of course, with mixed results. Yet Gödel, Escher, Bach remains a remarkable achievement. Its intellectual range and ability to let us visualize difficult mathematical concepts help make it one of this century’s best for anyone who’s interested in computers and their potential for real intelligence. –Richard Dragan

• Hackers & Painters: Big Ideas from the Computer Age by Paul Graham (O’Reilly, 2004)

From Amazon’s editorial review:

"The computer world is like an intellectual Wild West, in which you can shoot anyone you wish with your ideas, if you’re willing to risk the consequences." –from "Hackers & Painters: Big Ideas from the Computer Age," by Paul Graham We are living in the computer age, in a world increasingly designed and engineered by computer programmers and software designers, by people who call themselves hackers. Who are these people, what motivates them, and why should you care? Consider these facts: Everything around us is turning into computers. Your typewriter is gone, replaced by a computer. Your phone has turned into a computer. So has your camera. Soon your TV will. Your car was not only designed on computers, but has more processing power in it than a room-sized mainframe did in 1970. Letters, encyclopedias, newspapers, and even your local store are being replaced by the Internet. "Hackers & Painters: Big Ideas from the Computer Age," by Paul Graham, explains this world and the motivations of the people who occupy it. In clear, thoughtful prose that draws on illuminating historical examples, Graham takes readers on an unflinching exploration into what he calls "an intellectual Wild West." The ideas discussed in this book will have a powerful and lasting impact on how we think, how we work, how we develop technology, and how we live. Topics include the importance of beauty in software design, how to make wealth, heresy and free speech, the programming language renaissance, the open-source movement, digital design, internet startups, and more. And here’s a taste of what you’ll find in "Hackers & Painters": "In most fields the great work is done early on. The paintings made between 1430 and1500 are still unsurpassed. Shakespeare appeared just as professional theater was being born, and pushed the medium so far that every playwright since has had to live in his shadow. Albrecht Durer did the same thing with engraving, and Jane Austen with the novel. Over and over we see the same pattern. A new medium appears, and people are so excited about it that they explore most of its possibilities in the first couple generations. Hacking seems to be in this phase now. Painting was not, in Leonardo’s time, as cool as his work helped make it. How cool hacking turns out to be will depend on what we can do with this new medium." Andy Hertzfeld, co-creator of the Macintosh computer, says about "Hackers & Painters": "Paul Graham is a hacker, painter and a terrific writer. His lucid, humorous prose is brimming with contrarian insight and practical wisdom on writing great code at the intersection of art, science and commerce." Paul Graham, designer of the new Arc language, was the creator of Yahoo Store, the first web-based application. In addition to his PhD in Computer Science from Harvard, Graham also studied painting at the Rhode Island School of Design and the Accademia di Belle Arti in Florence.

• The Design of Everyday Things by Donald A. Norman (Basic Books, 1988; paperback reprint, 2002)

From Amazon’s editorial review:

With the many recent advances in technology, it seems, there has followed a diminution of quality. Electronic books have several advantages over their print counterparts, for instance. But for the time being, they’re hard to use and unattractive to boot. Computers, which are supposed to make our lives easier, are commonly sources of frustration and wasted time. Movies are wondrously chock-a-block with special effects–but someone forgot the story. And so on.

Donald Norman, a retired professor of cognitive science, is bothered to no end by the fact that grappling with unfriendly objects now takes up so many of our hours. Over the course of several books, of which The Psychology of Everyday Things was the first, he has railed against bad design. He scrutinizes a range of artifacts that are supposed to make our daily living a little easier, and he finds most of them wanting. Why, he asks, does a door need instructions that say "push" or "pull"? A well-designed object, he argues, is self-explanatory. But well-designed objects are increasingly rare, for the present culture places a higher value on aesthetics than utility, even with such items as cordless screwdrivers, dresser drawers, and kitchen cabinets. In their concern for creating "art," many designers don’t seem to consider what people actually do with things. Such disregard, Norman suggests, leads to few objects being standardized: think of all the different kinds of unsynchronized clocks that lurk in microwave ovens, VCRs, coffee makers, and the like–and of all the different kinds of batteries needed to drive them. Why, he wonders, must we reset all those clocks whenever the power goes off? Some designer somewhere, he ventures, ought to develop a master clock that communicates with all other electric clocks in a home–one that, when reset, synchronizes its slave units.

You don’t need to be especially interested in technological matters to enjoy Norman’s arguments. The book’s underlying question is aimed at a global audience: will the design of everyday things improve? If this entertaining and, yes, well-designed book changes even a few minds, perhaps it will.

• The Soul of a New Machine by Tracy Kidder (Little, Brown, 1981)

From Amazon’s editorial review:

The computer revolution brought with it new methods of getting work done–just look at today’s news for reports of hard-driven, highly-motivated young software and online commerce developers who sacrifice evenings and weekends to meet impossible deadlines. Tracy Kidder got a preview of this world in the late 1970s when he observed the engineers of Data General design and build a new 32-bit minicomputer in just one year. His thoughtful, prescient book, The Soul of a New Machine, tells stories of 35-year-old "veteran" engineers hiring recent college graduates and encouraging them to work harder and faster on complex and difficult projects, exploiting the youngsters’ ignorance of normal scheduling processes while engendering a new kind of work ethic.

These days, we are used to the "total commitment" philosophy of managing technical creation, but Kidder was surprised and even a little alarmed at the obsessions and compulsions he found. From in-house political struggles to workers being permitted to tease management to marathon 24-hour work sessions, The Soul of a New Machine explores concepts that already seem familiar, even old-hat, less than 20 years later. Kidder plainly admires his subjects; while he admits to hopeless confusion about their work, he finds their dedication heroic. The reader wonders, though, what will become of it all, now and in the future.

• The Codebreakers: The Story of Secret Writing by David Kahn (Macmillan, 1967; revised edition, Scribner, 1996)

From Amazon’s editorial review:

"Few false ideas have more firmly gripped the minds of so many intelligent men than the one that, if they just tried, they could invent a cipher that no one could break," writes David Kahn in this massive (almost 1,200 pages) volume. Most of The Codebreakers focuses on the 20th century, especially World War II. But its reach is long. Kahn traces cryptology’s origins to the advent of writing. It seems that as soon as people learned how to record their thoughts, they tried to figure out ways of keeping them hidden. Kahn covers everything from the theory of ciphering to the search for "messages" from outer space. He concludes with a few thoughts about encryption on the Internet.

• Longitude: The True Story of a Lone Genius Who Solved the Greatest Scientific Problem of His Time by Dava Sobel (Walker, 1995)

From Amazon’s editorial review:

Anyone alive in the eighteenth century would have known that “the longitude problem” was the thorniest scientific dilemma of the day—and had been for centuries.  Lacking the ability to measure their longitude, sailors throughout the great ages of exploration had been literally lost at sea as soon as they lost sight of land.  Thousands of lives and the increasing fortunes of nations hung on a resolution.  One man, John Harrison, in complete opposition to the scientific community, dared to imagine a mechanical solution—a clock that would keep precise time at sea, something no clock had ever been able to do on land.  Longitude is the dramatic human story of an epic scientific quest and of Harrison’s forty-year obsession with building his perfect timekeeper, known today as the chronometer.  Full of heroism and chicanery, it is also a fascinating brief history of astronomy, navigation, and clockmaking, and opens a new window on our world.

• The Making of the Atomic Bomb by Richard Rhodes (Simon & Schuster, 1986)

From Amazon’s editorial review:

If the first 270 pages of this book had been published separately, they would have made up a lively, insightful, beautifully written history of theoretical physics and the men and women who plumbed the mysteries of the atom. Along with the following 600 pages, they become a sweeping epic, filled with terror and pity, of the ultimate scientific quest: the development of the ultimate weapon. Rhodes is a peerless explainer of difficult concepts; he is even better at chronicling the personalities who made the discoveries that led to the Bomb. Niels Bohr dominates the first half of the book as J. Robert Oppenheimer does the second; both men were gifted philosophers of science as well as brilliant physicists. The central irony of this book, which won a National Book Critics Circle Award, is that the greatest minds of the century contributed to the greatest destructive force in history.

So there they are.  What do you think of this list or of any of these books?  Have you read any of these books already?  Which ones would you recommend to add into this list?  I have a few in my head, but I’ll add them below so to keep this post as it is.

A while back, my pastor lend me a small little orange book written by Andy Stanley, founder and senior pastor at North Point Community Church in Atlanta, Georgia.  “Making Vision Stick” is a 74-page book that deals about ways to successfully make your vision a reality.  Even though the author uses examples from the church ministry, you’ll find the concepts and ideas to be compatible in business, at work, in the family, etc.

From the back cover, we can read the following:

Your vision is the lifeblood of your organization.

It should be coursing through the minds and hearts of those you lead, focusing their creativity and galvanizing their efforts.  Together, you and your team will strive to make your vision a reality.

But in order for that to happen, you’ve got to make your vision stick.  That’s your responsibility as the leader.

And that’s what this book is all about.  The examples used by the author throughout the book are simple and concrete.  His ideas are very well explained and I like the fact that he managed to deliver his message in a concise manner without babbling too much or going on tangents.

Without giving you all the details on how to make your vision stick, the following is the process used by the author to help you in making your vision a reality:

1. State your vision simply
2. Cast it convincingly
3. Repeat it regularly
4. Celebrate it systematically
5. Embrace it personally

I recommend this book to anyone who is a position of leadership and is looking for simple ways to apply and nurture a vision to a team or organization.

NOTE: Okay, I can imagine some of you thinking “What does this has to do with software development?”. Well, take for example an architectural design or a software process you’d like to implement within your team or organization.  That’s your vision.  Now you need to make that vision a reality.  How would you go about it?  This little book provides some meaningful ideas to not only get buy-in for our vision, but also how to make your vision stick in the long run.

What a great joy I had reading, this morning on my way to church, “The Dip: A Little Book That Teaches You When to Quit (and When to Stick)“, an 80-pages book written by prolific blogger and marketing guru Seth Godin.  The author has an unique writing style that I enjoy very much because he delivers his message in many ways by using simple terms, concrete examples, proven facts, and sound statistics.  In a nutshell, the basic idea of his book is that whether you aspire to succeed in your personal and professional life (who doesn’t?), or whether you want to be the best in the world at what you do (you being yourself, your team, your company, etc.) or whether you want to achieve your goals on time, you should accept this little fact: sometimes quitting is a winning strategy.  That being said, it’s more important to know what to quit, when to quit, why to quit and how to quit something (a relationship, a job, a project, an education, etc.).  The author does a great job at describing sound strategies you can choose whenever you’re in that moment in life and need to take proper action: should I continue or should I stop?  In software development, we are more often than not forced to make this kind of decision:

• Should we continue using this process to build our software?  Or should we perhaps stop and decide to change it or replace it because it’s not getting us very far?  And what if we’re in the middle of an iteration?
• Should we continue developing this application?  Or should we perhaps stop and decide to buy one from a third party?
• Should we continue putting our resources in the development of this feature?  Or should we perhaps cancel this feature and concentrate our resources on other more important features?
• Should we continue with this process improvement methodology or should we stop and rethink our strategy?

I could go on and on…

So what exactly is this ‘Dip’?  As it is written in the book’s back cover:

It’s the fifth job interview where they never even call you back.

It’s the garage band playing to an empty club in the middle of nowhere.

It’s the seventh time you fall on your butt while learning to snowboard.

It’s the middle of the marathon, when the excitement of the starting gun is a dim memory, and the joy of the finish line is a distant dream.

It’s any rough patch you have to get through before achieving your big goal…if in fact you’re chasing the right goal.

What else?

Oh yeah, it’s also the key to your career, your company’s future, and maybe your ultimate happiness.

I’m often in situations where I need to ask myself this same question when developing software.  For example, should I continue building my application with the initial design or should I pause for a moment and perhaps modify the initial design to reflect some changes?  Should I really invest my time in learning this new tool, this new technology or this new language?  Should I continue working on this open source project that I started a year ago?  Should I invest in this hardware to support my software?  Why? Why not?   There’s always a tradeoff when you take a decision.  Knowing what the tradeoffs are and knowing what strategies you have at your disposal is essential to adapt to the situation and successfully reach your goals. 

I strongly encourage software developers to extend their knowledge beyond ‘just software’.  See what you can learn from other cultures, leadership, team work, continuous self-improvement, etc.  I believe that the real foundation of a software is neither the tools nor the technologies, but the people (at least 95% of the time).  And since people’s behaviours change more often than requirements, it’s important to know how to adapt at any moment.  Sometimes quitting something you were working on can be the best long-term strategy you could have chosen to successfully reach your goals.

As another quote from the author,

Whether you’re a graphic designer, a sales rep, an athlete, or an aspiring CEO, this fun little book will help you figure out if you’re in a Dip that’s worthy of your time, effort, and talents. If you are, The Dip will inspire you to hang tough. If not, it will help you find the courage to quit-so you can be number one at something else.

I won’t tell you more about the book, because I think you’ll do yourself a better favour in investing a couple of hours to read it on your own. 

Meanwhile, I’ll invite you to read Guy Kawasaki’s interview with Seth Godin on The Big Dip: Ten Questions with Seth Godin, and also take a look at Kevin Donaldson’s review on the book.

I’ve been a fan of John C. Maxwell ever since reading his excellent book on leadership The 21 Irrefutable Laws of Leadership, so it was without hesitation that I decided to read one of his other books on leadership and human potential.  Regardless of being just 120 pages, "Dare To Dream…Then Do It: What Successful People Know And Do" is a personal treasure that will ignite you to maximize your potential by helping you realizing your dreams.  What kind of dreams are we talking about?  YOUR dreams.  Whether it is to be a successful pioneer in your field of work, a better leader in your family and organization, an achiever of what some people might characterize of "impossible victories", rediscover or reveal your inner self, contributing your talent, wisdom and life to a worthy cause, or anything else for that matter, this book is truly an eye-opener to one’s heart.

One reason that makes this book so good to read is that it is filled with words and stories from highly successful leaders, innovators and creative thinkers all throughout history.   Take for example the following immortal and inspiring words from such people which you can cherish in this book:

• "Far better it is to dare mighty things, to win glorious triumphs, even though checkered by failure, than to rank with those poor spirits who neither enjoy much nor suffer much, because they live in the gray twilight that knows neither victory nor defeat" - U.S. President Theodore Roosevelt
• "Keep your eyes on the stars, but remember to keep your feet on the ground" - U.S. President Theodore Roosevelt
• "Don’t let someone else create your world, for when they do they will create it too small" - Edwin Louis Cole, founder of Christian Men’s Network.
• "Never measure the height of a mountain until you have reached the top.  Then you will see how low it was" - Dag Hammarskjold, Swedish diplomat
• "Whatever things are true, whatever things are noble, whatever things are just, whatever things are pure, whatever things are lovely, whatever things are of good report, if there is any virtue and if there is anything praiseworthy — meditate on these things" - Apostle Paul writing to the Philippians (Philippians 4:8)
• "Early in life, I decided that I would not be overcome by events.   My philosophy has been that regardless of the circumstances, I shall not be vanquished, but will try to be happy.  Life is not easy for any of us.  But it is a continual challenge, and it is up to us to be cheerful — and to be strong, so that those who depend on us may draw strength from our example." - Rose Kennedy
• "Thought is the original source of all wealth, all success, all material gain, all great discoveries and inventions, and all achievement." - Claude M. Bristol, U.S. author
• "If you have built castles in the air, your work need not be lost; there is where they should be.  Now put foundations under them." - Henry David Thoreau, essayist
• "The time is always right to do what is right" - Martin Luther King, Jr., civil rights leader
• "At the Day of Judgment, we shall not be asked what we have read, but what we have done." - Thomas Kempis, German monk"
• "The most important single ingredient in the formula for success is knowing how to get along with people." - U.S. President Theodore Roosevelt
• "Treat a man as he appears to be and you make him worse.  But treat a man as if he already were what he potentially could be, and you make him what he should be." - Johann Wolfgang Von Goethe, German poet
• "If a man has talent and cannot use it, he has failed.  If he has a talent and uses only half of it, he has partly failed.  If he has talent and learns somehow to use the whole of it, he has gloriously succeeded, and won a satisfaction and a triumph few men will ever know." - Thomas Wolfe, U.S. novelist
• "Every man must at last accept himself for his portion, and learn to do his work with the tools and talents with which he has been endowed.  That some are more richly endowed that others should cause no concern, for in the final analysis it may appear that the mighty oak is of less importance than the tiny violet which blooms in humble obscurity at its feet." - Charles A. Hawley
• "Great works are performed, not by strength, but by perseverance.  He that shall walk, with vigor, three hours a day, will pass, in seven years, a space equal to the circumference of the globe." - Charles Johnson
• "So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable" - Christopher Reeve, actor

As for the stories, I learned so many things which I had no idea were actual inspiring acts.  For instance, I didn’t know that:

• Andres Segovia revolutionized the music industry by pursuing his dream about perfecting the art of playing the classical guitar and establishing that musical instrument as a key tool in the concert hall.  As John Maxwell justly writes about Segovia’s work, "When people discover their dreams and commit to them, there’s no telling what kind of impact they will make."
• Arnold Palmer, one of the greatest golfers of all times and a man which was named Sports Illustrated’s Sportsman of the Year in 1960 and Athlete of the Decade by an Associated Press poll, screwed up a "par five ninth hole" in a 1961 tournament.  And because of that single result, a bronze plaque was made and hung on that same golf course which states that Arnold Palmer, which was voted as the best sportsman the year before, took a 12 on that hole.  He really screwed up that shot.  Nevertheless, that didn’t stop Arnold Palmer to continue his passion for the game and winning more golf tournaments.
• In their first professional baseball debut, two NBL rookies were playing against each other that day.  Jim Greengrass who was playing for the Cincinnati Reds helped his team win with a score of 9-8 by hitting four doubles.  In the other hand, Hank Aaron, who was playing for the Milwaukee Braves, went 0 for 5.  I don’t know much about baseball, and I certainly don’t know who Jim Greengrass is,  but I have heard a lot about Hank Aaron and what he has accomplished simply because he didn’t let failure win over his dreams and achievements.  So next time you’re banging your head on the desk because your software design shows too much coupling between classes and its complexity is too high to make any significant change on the spot, don’t let it stop you from trying harder and imagining further solutions to your problem.

In essence, the spirit of the book can be summarized with these words by the author:

Successful people know and do things differently than unsuccessful people.  That is a fact.  If you have experienced a measure of success, you know this to be true.  It starts with the way you think and dream, and it continues with how you live.

Most revolutions throughout human history started out with a dream.  What kind of revolution do you want to live your life for?  I know some people who dream dreams, but then summarize their lives as a nightmare and a sad reality because they simply didn’t take that extra step to "instantiate" (hey, this is a blog about software development anyways, right?) that dream.

So, whether you’re a software developer, scholar, consultant or manager, what can the ideas from this book bring to you and your team?  For starters, if you’re a software development manager, the principles of this book will whisper in your heart that you should foremost trust your team and help your team members to grow both at a personal level and at a professional level, so that they can become who (not what, for the who defines the what in life) they’re really meant to be.  You want another challenge?  Help them to become better than yourself at what you’re doing, and if possible help them to achieve greater things that you have achieved in your life and career.  At the end, you will benefit more from it.  If you’re a software developer, a consultant or a student of the field, don’t be shy to step out of your comfort zone and share what you know (your experience) with others.  Offer to give a talk or a presentation at your next user group’s meeting.  Don’t be reluctant to write something you have in mind if it can help a couple of people (blogs are so easy to start nowadays).  Don’t regret writing that piece of software that could greatly contribute to the field or, even better, to the rest of the world.  Don’t be afraid to learn new things and to embrace failure while trying new stuff…as long as you’re willing to learn from it.  As stated by the author,

People will never be what they ought to be until they are doing what they ought to be doing.

There are so many other inspiring stories throughout this book that I’m voluntarily omitting from writing in this post, because I rather wish you read them on your own.  What you have read so far in this post is not even half of the rich content that John Maxwell has wrote in this book.  In closing words, I’ll mention it again: never stop dreaming big in life.  I love writing software and working with people with different skills, but whether I stay in this field all my life or not, one thing is for sure, I’ll never stop dreaming.

Think about your dreams.  Does it inspire you to work hard?  Does it motivate to take smart risks?  Does it build you up?  Will it benefit others around you?  As you move closer to fulfilling it, will it bring you closer to who you were born to be?  Those are all hallmarks of a healthy daring dream!

This is my second technical review for a book belonging to the "Head First" series from O’Reilly.  After reading and reviewing the excellent "Head First Design Patterns", it was hard not to push further my curiosity to read another Head First book.  I must say that since writing the review for "Head First Design Patterns", a friendly editor from O’Reilly offered me the opportunity to read and review any book I desire from the publisher, which I have accepted since reading about the field is one of my principles about becoming a key professional software developer.  That being said, I also need to point out that my reviews on any O’Reilly book will be purely objective, therefore I will write about my thoughts on the book, as well as what I liked and disliked about it, independently of my status as a reviewer for the publisher. All right, here we go…

Written by professional software developers Dan Pilone and Russ Miles, "Head First Software Development" brings the most important ideas and principles on software engineering today.  Instead of just dealing with one phase of the software development lifecycle (SDLC), it actually covers ALL the phases of the SDLC from gathering requirements, planning the different steps in a project, and dealing with user stories, to knowing how to manage your software process with continuous integration and test-driven development with mock objects.  The best part of it all is that it is written with the same unique, intelligent and sublime style of any other Head First book.

I was remembering my years as a software engineering undergrad, and all those classes that we had to attend weekly, while reading this book one night.  In fact, I realized that this book presents all the most important practices and principles a professional software engineer should be acquainted with in order to design, develop and deliver successful and higher quality software today.  Even though the book targets Java as the programming language for its examples, JUnit for its unit tests scenarios, Ant as its build engine tool, CruiseControl as its continuous integration server, you will find no problem at all to follow and understand the main ideas shared in this  book.  As an example, I’m more of a .NET developer that rather prefers to use other tools like NUnit, TypeMock, MSBuild and TeamCity instead.  In other words, it’s not the tool that makes the difference in your work, but rather the knowledge you have of the tool.  And since knowledge is universal, you will be very comfortable in following the main ideas behind each chapter even if you haven’t programmed with Java. 

Without stating it explicitly, Head First Software Development uses various key ideas from Scrum and XP, such as daily standup meetings, planning an iteration by playing planning poker, calculating and using a team’s velocity to better manage a project’s estimates, writing customer-focused user stories to gather requirements and manage requirements priorities, using a burn-down chart to view a project’s status within each iteration, driving the coding activity by writing tests first and applying refactoring, encourage and improve team communication with continuous integration, as well as customer communication by keeping her informed of the project’s "health status".  In a few words, the book can be summarized as a simple collection of various activities, ideas, guidance and principles to deliver software on time, on budget and on track with what the customer asked for.

Like all the other Head First series, this book also contains the popular "There are no dumb questions" sections which provide helpful answers and tips to various questions most customers and software developers ask or have being asked.  One such question/answer that forced me to get up from my seat and get a yellow highlighter was this one:

Question: What is you don’t have a next iteration? What if you’re already on the last iteration, and then a top priority feature comes in from the customer?

Answer: If a crucial feature comes in late to your project and you can’t fit it into the last iteration, then the first thing to do is explain to the customer why the feature won’t fit.  Be honest and show them you iteration plan and explain why, with the resources you have, the work threatens your ability to deliver what they need by the due date.

I was amazed by this answer, because I remembered a student once asking a similar question to a teacher at university and he couldn’t give the student a straight simple answer, but then again maybe because the professor was lacking real-world experience.  Anyhow, the answer given by the authors truly demonstrates that communication isn’t just a link between developers alone but that in fact that link must also include customer(s).  It’s their project(s) after all!  Now this is just one example of a Q&A you will find in this book…and there are a lot of them!

Another positive outcome of reading this book is that you don’t have to read all the continuous integration, test-driven development and user stories books available in the market to get up and going with these practices.  In fact, Head First Software Development successfully presents a good and thorough overview of all these practices for you to be able to understand the concepts and principles behind them, but most importantly, to be able to apply them within your own organization.  Then if you want to go more in depth about a particular practice, you can go ahead with a more specific book on the subject and not be lost in your reading.

I highly recommend this book to be part of a software engineering curriculum at both the undergraduate and graduate level.  I also think that this book will be a great plus for software development managers who want to improve their software development process by using sound, concrete, and realistic practices within their own organization.  Software consultants will no doubt also greatly benefit from this book, especially if they need to implement or recommend a proper solution in regards to a client’s software development process.  Being a software development trainer myself, I was very grateful to have had the opportunity to read Head First Software Development for the simple reason that I got to learn more than a few things in which I haven’t had much knowledge in.  Now, I can hardly wait to share what I’ve learned from this book with my students in the classroom!

The following is the Table of Contents for this book:

1. Great software development: Pleasing your customer
2. Gathering requirements: Knowing what the customer wants
3. Project planning: Planning for success
4. User stories and tasks: Getting to the real work
5. Good-enough design: Getting it done with great design
6. Version control: Defensive development
7. Building your code: Insert a tab into slot b…
8. Testing and continuous integration: Things fall apart
9. Test-driven development: Holding your code accountable
10. Ending an iteration: It’s all coming together…
11. The next iteration: If it ain’t broke…you still better fix it
12. Bugs: Squashing bugs like a pro
13. The real world: Having a process in life

Written by Marc Benioff, chairman and CEO of SalesForce.com, “The Business of Changing the World” is a wonderful and inspiring collection of twenty essays written by great leaders on strategic corporate philanthropy. Amongst these leaders who each wrote their essays, we find Michael Dell and Kevin Rollins of Dell Craig Barrett of Intel Marc Benioff of SalesForce.com Steve Burd of Safeway Steve Case of Revolution Jim Donald of Starbucks Mike Eskew of UPS Larry Fish of Citizen Bank Peter Gabriel of WITNESS Jean-Pierre Garnier of GlaxoSmithKline Alan Hassenfeld of Hasbro Akinobu Kanasugi of NEC Phil Marineau of Levi Strauss & Co. Micheal Milken of The Milken Institute John Morgridge of Cisco Systems Marilyn Carlson Nelson of Carlson Companies Laura Scher of Working Assets Klaus Schwab of The World Economic Forum Jeffrey Swartz of Timberland

The main idea behind the novel is that major corporations are doing well because they’re doing good. Even though I only knew maybe half of these organizations (remember that I live in Canada and most of these companies are from the U.S.), it was nevertheless challenging to read how each of these leaders once asked themselves if there was something they could do to give back to society, because society once helped them at some point in their lives. Of course not all major organizations, such as Google and Microsoft, are included in the book. That’s fine because it’s not hard to learn about their philanthropic whereabouts and activities, given that they’re so big and popular. Therefore, the book actually presents what other small, medium, and large companies are doing to help back those who’ve helped them at some point in time.

It wasn’t easy to let the book down once I finished reading an essay, because I felt like reading what the next organization had to say about its own vision and plan towards philanthropy. Another neat thing about the book is that each essay is divided in two parts. The first part discusses about the founder or the CEO of a given company, and how that company came to be. Therefore you get a little history lesson behind some of these big names that are so well known nowadays. The second part deals with the different approaches and activities adopted and supported by the companies and their employees towards philanthropy. It’s brilliant because you also get to know some possible (and very realistic) ways that you can adopt within your own organization in order to give back to society, whether it’s time, money, education, etc. Every essay also presents statistics and facts that compare a company’s overall performance before and after adopting a mindset of doing well by doing good. Therefore you can compare yourself with those organizations if you want, but more importantly it gives you a concrete sense of the real power behind these acts. This is a book that I will read over and over again, and share with my friends and people who want to make a positive difference in their own society and hopefully on a worldwide scale. Living in North America, it’s sometimes easy to forget how blessed we are (financially, materialistically, academically, etc.), and be blind to other communities and nations who are more in need than the rest of us. I believe we have more than the necessary to help each other within our local communities, as well at the international level. I’m glad this book is out because I also believe that we’re going to see more corporate philanthropists in action in the near future, and this time their business will be to change the world.

For this review, I decided to target a technical book which I think should be on every software enthusiast bookshelf. Whether you’re a computer science or software engineering student, a software professional, manager, consultant or trainer, you will NOT regret reading Head First Design Patterns by Eric and Elisabeth Freeman, from O’Reilly. I think you can guess what this book is about (I admit it wasn’t a hard guess…), but you’re right! It’s a book about software patterns, and by far the book I mostly recommended on the subject. Using the Java programming language and UML diagrams, this book deals with all the original patterns from GoF and presents them with a unique sense of humour, simplicity and fun! It doesn’t matter if you’re a first time learner on the subject or if you’re an expert. Head First Design Patterns will surely teach you more than one thing about software patterns for sure.

What fascinates me the most about Head First Design Patterns is its style of writing, because the approach taken by the authors to present each patterns is simple and easy to grasp. For instance, each pattern is presented in an intelligent and smooth context via a little story. The story starts with a problem between some characters or a witty situation, such as a one-on-one interview with a pattern (seriously, have you ever heard a Singleton being interviewed? It’s awesome!) It then continues by providing different solutions (I do mean solutions in plural, as it tackles the problem domain using different solutions via the same pattern) and testing your knowledge on the pattern via questions and answers, crosswords related to the particular pattern, how the pattern relates to other patterns, tips and tricks, etc.

The picture on the right side shows a sample of the unique style of the Head First series.  In this page, the authors are writing about a key object-oriented programming principle: Single Responsibility.  You can also read a limited preview version of this book on Google Book Search.

As written on the back cover, Head First Design Patterns will show you

• The patterns that matter
• When to use them, and why
• How to apply them to your own designs, right now
• When not to use them (how to avoid pattern fever)
• OO design principles on which patterns are based

Erich Gamma and Richard Helm, coauthors of the original Design Patterns book, as well as Ward Cunningham, wrote praises for this book. It is smartly written, fun to read, challenges you at regular intervals, and makes you appreciate the fundamentals behind software patterns. I wish more technical books were written in the same style as this one. I highly recommend it, especially if you’re teaching software patterns to individuals.

The following is the Table of Contents for this book:

1. Welcome to Design Patterns: an introduction
2. Keeping your Objects in the know: the Observer Pattern
3. Decorating Objects: the Decorator Pattern
4. Baking with OO goodness: the Factory Pattern
5. One of a Kind Objects: the Singleton Pattern
6. Encapsulating Invocation: the Command Pattern
7. Being Adaptive: the Adapter and Facade Patterns
8. Encapsulating Algorithm: the Template Method Pattern
9. Well-managed Collections: the Iterator and Composite Patterns
10. The State of Things: the State Pattern
11. Controlling Object Access: the Proxy Pattern
12. Patterns of Patterns: Compound Patterns
13. Patterns in the Real World: Better Living with Patterns
14. Appendix: Leftover Patterns

The Strategy pattern is described in chapter 1, whereas the Model-View-Controller pattern is described in chapter 12.

The Appendix covers the following patterns:

• Bridge
• Builder
• Chain of Responsibility
• Flyweight
• Interpreter
• Mediator
• Memento
• Prototype
• Visitor

If you have the original Design Patterns book by Erich Gamma et al., Head First Design Patterns will be a great complement to fill in the gaps you might have on some software patterns.

This review is for Leadership and Self-Deception, from the good folks at The Arbinger Institute. It was actually my pastor who lend me this book following a talk I had with him about leadership in life and business; and if you know something about church ministries, you’d know that if it’s good enough for a pastor (i.e. a leader), then it’s certainly good enough for you. So anyways, I took the book home, and one week later, my life has improved in both a personal and professional level. This book is about 170 pages long, and it is very easy to read, in other words, you won’t need a dictionary to lookup every fifth word.

In short, the story is written as a narration of a young and new manager at a world-renowned and respected corporation. This company, Zagrum, is the best in its market, because its results are driven by people who are themselves driven by other people, instead of being driven by their own ego. The concept of self-deception is portrayed as "being in the box". You get "in the box", when you betray yourself. In other words, self-betrayal gives you a free ride to self-deception. What this means is that once you’re in the box, you have trouble seeing the real problem (such as lack of communication, trust, respect, commitment, etc.) at hand, and even more trouble in finding a solution to fix it, because you are blind to see that the problem is not the other people, but yourself. How do you know this? The answer is simple: you see other people as objects, instead of people. And as you probably know, it’s hard to understand, speak to, listen to and learn from objects. People have needs, cares, fears and hopes. How to manage and influence people is at the core of leadership, and at the end of it all, your heart is the foundation of leadership.

Just to give you a glimpse of the material you’ll learn through this book, I’m including an excerpt that I found very helpful.

Here, Bud, an executive manager at the company teaches Tom, the new manager, that there is a difference between knowing the material and living the material (the material being knowing the truth between being in the box and out of the box):

Knowing the material

• Self-betrayal leads to self-deception and "the box."
• When you’re in the box, you can’t focus on results.
• Your influence and success will depend on being out of the box.
• You get out of the box as you cease resisting other people.

Living the material

• Don’t try to be perfect. Do try to be better.
• Don’t use the vocabulary - "the box" and so on - with people who don’t already know it. Do use the principles in your life.
• Don’t look for others’ boxes. Do look for your own.
• Don’t accuse others of being in the box. Do try to stay out of the box yourself.
• Don’t give up on yourself when you discover you’ve been in the box. Do keep trying.
• Don’t deny you’ve been in the box when you have been. Do apologize, then just keep marching forward, trying to be more helpful to others in the future.
• Don’t focus on what others are doing wrong. Do focus on what you can do right to help.
• Don’t worry whether others are helping you. Do worry whether you are helping others.

And finally, I had to include a powerful, yet so true message that I believe people in organizations (doesn’t matter their position, rank or title) should understand and remember daily:

"Tom," he said, putting his hands on my shoulders. "The thing that divides fathers from sons, husbands from wives, neighbour from neighbours - the same thing divides coworkers from coworkers as well. Companies fail for the same reason families do. And why should we be surprised to discover that it’s so? For those coworkers I’m resisting are themselves fathers, mothers, sons, daughters, brothers, sisters. A family, a company - both are organizations of people. That’s what we know and live by at Zagrum" (Page 168).

I am not a pro at writing book reviews, so the approach I’m taking is the same one I would expect someone to convince me to read a book. And since I’m a simple person, I am expecting simple results. So I hope this book review was simple enough to convince you to get this book from a public library, a book store or a friend’s desk. Trust me, you won’t regret it!

"No one can disparage the ability to write good code. At its highest levels, it is an art." Such is a quote that can be read on the back cover of Mike Gunderloy’s book, "Coder to Developer" from Sybex . I got this copy from the library thinking that I would learn something new, something deep about software development. In all of its 295 pages, I can say that this book is not geared towards the intermediate to advanced software developers, but rather to those who are beginning the road to become professional software developers. The main idea behind the book is that "software development" is more than just coding and compiling a software project. There are various activities, principles and practices to set up and to follow in order to design, implement, ship and support a software product. Although Mike’s book is targeting the .NET Framework and the Windows platform, there is no doubt that his point can be shared across other technologies, tools and environments. Joel Spolsky wrote the foreword, and I must say that it was a delight to read it. Here’s an excerpt of what he wrote that pushed me further in reading this book:

"We don’t really know what software development is all about until we have a concept, put in place a team, set up state of the art development processes, design a software product, the right software product, and produce it. That’s not all…it must serve a real need of its users and be accompanied by a web page, a setup program, tests cases, multilingual versions, etc."

I think one reason that I didn’t put this book in my top reading list of all-time favorites is because most of its content, if not all of it, can be found today on blogs and with the help of Google. As a matter of fact, the book was published in 2004, therefore most of the tools that are mentioned in the book are nowadays outdated, unsupported or altogether abandoned. Have I read this book back in 2004, it would have been a great source of insights, but now that we have the power of search in our hands, I don’t really see the pertinence of authors writing any more technical books tackling such a broad field with the support of different tools. Nevertheless, the ideas and principles covered in this book were concepts preached by advocates of software engineering for a long time and are still relevant today. For example, how many organizations today have an established automated continuous integration process? How many independent consultants know how to write a solid contract before embarking on a project?

The author defines a coder and a developer in these terms, which I think is well put:

A coder knows the syntax and semantics of a computer language, whereas a developer can apply that knowledge to turning out a working application with all the necessary supporting details.

I also like the preliminary questions that each developer should ask himself or herself before jumping in the adventure of creating a software:

Ask yourself these fundamental questions before starting to write your software:

1. What are you writing?

2. When do you want to finish writing it?

3. Where do you expect it will be used?

4. Why are you writing this software?

5. How will you write the software?

Someone willing to advance in this profession should be able to answer all these basic questions before engaging a new project. I like the way that these questions don’t depend on implementation or technology.

Mike also presents various ideas to keep in mind before starting to code. Two of my favorites are the concept of the Elevator Pitch and the checklist of eliciting requirements:

Write a good elevator pitch for your software before starting to code it. Keep in mind the following:

1. Short is better than long. A long and rambling elevator pitch probably means you haven’t really decided what you’re building yet.

2. Functionality trumps technology. Potential customers care about what your software will do. They usually don’t care how your software does it.

3. Solve a problem. If you can’t explain what problem your application will solve, customers won’t know why they should buy it.

4. Pitch the benefits, not yourself. Customers won’t be buying you, your superior knowledge, or your development team. They’ll be buying the software.

5. Figure out what’s important to your audience, and make sure you address that. Are the people buying your product most interested in cost, innovation, features, compatibility, or something else entirely?

Eleciting Requirements Checklist (if working with an external customer)

1. Talk to the actual end users of the software. Ask them what they expect the software to do.

2. Watch how the end users perform their job now. Make sure you understand how the software will change things.

3. Write a vision and scope document, explaining what’s a part of the project and (equally important) what is not. Make sure the customer agrees with you.

4. Hold an informal group discussion with the users over lunch or a night out. People will speak up in a group of their peers even when they won’t tell you things one on one.

5. Document the requirements in plain English, and then check with the users to see if they make sense.

6. If you’re replacing existing software, find out what’s wrong with the current system. Your requirements will often boil down to fixing the problems.

7. Arrange the requirements in priority order and make sure the customer agrees on the priority.

At the end of the requirements elicitation process, you should know what the software will do. Just as important, the customer should have confidence that you understand their requirements.

I was delighted to see that the author mentioned two other types of documentation that should be written whether we’re developing in solo or in teams. These are the development log and the postmortem. It is the first time I encountered the existence of these two documents, which proves that you always learn something new, even when you think you know it all (note to self…). In a development log, we tend to ask and answer the following questions:

• What the overall architecture of the application is, and why that architecture was chosen over alternatives
• Who’s responsible for each part of the application or for each function on the team
• Where key pieces of the network are located: Which server handles source code control? Which one is the build machine?
• What tricky problems came up, and how they were solved

This development log can easily be maintained in a wiki, a blog, a SharePoint site, etc. I believe this artefact to be very useful for new team members.

The second type of document that should be written is the postmortem. In this document, we tend to include the following:

• Overall description of the project
• Who was involved on the team
• How the project’s scope and features changed from initial design to final ship
• A list of things that were done well during the project
• A list of things that could have been done better
• A list of tools used, along with an evaluation of their quality
• A list of tools that team members wish they had had available
• A list of important project documents with their locations
• Recommendations for the next project: How can things be done better?

Whether you’re a student of computer science or software engineering, or someone making the shift to the software development field and looking for ways to advance as a professional, I’ll recommend you to read this book without hesitation. On the other hand, if you have "been there and done that" for a while and you’re looking to polish your skills, I’ll suggest you to keep looking around because chances are that you will learn more by reading what’s in the blogosphere.

In all, I think that Sybex has published a good resource for the newcomers in this field. Here are the topics covered in this book as stated on the back cover:

• Choosing and using a source code control system
• Code generation tools – when and why
• Preventing bugs with unit testing (and mock objects)
• Tracking, fixing, and learning from bugs
• Application activity logging (using various tools, including the Logging Application Block from Enterprise Library)
• Streamlining and systematizing the build process
• Traditional installations and alternative approaches
• Creating software documentation for users and stakeholders

On a final note, these are the contents at a glance:

• Chapter 1: Planning Your Project
• Chapter 2: Organizing Your Project
• Chapter 3: Using Source Code Control Effectively
• Chapter 4: Coding Defensively
• Chapter 5: Preventing Bugs with Unit Testing
• Chapter 6: Pumping Up the IDE
• Chapter 7: Digging Into Source Code
• Chapter 8: Generating Code
• Chapter 9: Tracking and Squashing Bugs
• Chapter 10: Logging Application Activity
• Chapter 11: Working with Small Teams
• Chapter 12: Creating Documentation
• Chapter 13: Mastering the Build Process
• Chapter 14: Protecting Your Intellectual Property
• Chapter 15: Delivering the Application

Verdict: 3/5. It’s a book aimed at beginners who have at heart the need to improve the way they work, as well as their sense of professionalism in the field. The intermediate and more advanced developers would gain more insights by reading what other experts are writing in their blogs and articles. Since the book is heavily dependent on various tools and technologies supported by the 2003 release of the .NET Framework and the Windows platform, most of the content can seem to be outdated and maybe completely irrelevant in a couple of years. Especially for those of us who don’t target the .NET CLR and the Windows platform.

Happy reading!