Posts

Stumbling on Happiness

Book Review-Stumbling on Happiness

What makes you happy?  Are you happy?  I’ve personally spent my life time trying to find “happy” much to my dismay it’s illusive like a pot of gold at the end of the rainbow.  (Hint: The rainbow moves.)  I certainly have a lot to be happy about – and I am generally speaking happy.

I have few regrets; I enjoy what I do for a living, and so on.  But to be honest, I don’t know why I’m happy.  Why do I care why I’m happy?  Well how do I remain happy?  How do I become happier?  How do I help my wife or my son become happier?  They are hard questions to answer if you can’t describe what makes you happy in the first place.

While I won’t say that Daniel Gilbert’s book Stumbling on Happiness has all the answers.  Clearly it doesn’t or everyone would have read it by now – while sitting next to their money tree and sipping their favorite beverage.  However, even without all of the answers there are more than a handful of salient points.

I knew my ability to estimate how happy I will be from something is bad but I didn’t know how bad – or why.  I have enough gadgets that I realize that gadgets don’t make you happy.  (I’m still going to get more.)  However, I didn’t realize that everyone else was equally bad at it.  (OK, most people are equally bad at it.)  Gilbert helps to enumerate some of the reasons why the estimating is so bad and offers a hint or two about what to do about it.  (It’s one hint and you likely won’t take his advice, but it’s there.)

It also crystallized for me the idea of a psychological immune system.  That is, succinctly, a psychological system that keeps us “ok.”  Perhaps better said in the context of the book, enables us to be more happy than not.  This is important in part because I picked up the book as my flight was cancelled in New York’s LaGuardia airport.  My rerouting will take more than 24 hours, involves me not getting enough sleep, and sitting in Regan National Airport in Washington, DC for more than 9 hours.

Yet, honestly, I’m not that miffed at the whole deal.  I suppose I should be but I’m not.  What I would call coping skills kicked in and coerced me into making the best of it.  It gave me time to read the book – which I wouldn’t have been able to do without the delay.  It also gave me time to work on some projects that were late (or almost late).   To be frank, I wouldn’t have traded the time with my family for these things – but all in all it wasn’t a total loss.

This is even more striking because I witnessed another passenger nearly “loose it” when her flight was cancelled.  I’m sorry that her psychological immune system was not stronger.  Whether I call it coping skills, adaptability (as I’m sometimes apt to do), or a psychological immune system – it’s interesting to better understand how to cope with disappointment.

I won’t say that Stumbling on Happiness will help you find happiness – however, it might make it a little easier to understand it when you do.  It’s more than worth a read.

Oh and “You’re fine, how am I?”

The Long Tail: Why the Future of Business is Selling Less of More

Book Review-The Long Tail

The world is changing.  That’s no news flash.  The real question is how is it changing and what do those changes mean for you?  One of the changes is a gradual migration away from runaway hits, blockbusters, and phenomena.  Instead lower cost to store, lower cost to distribute, and better findability are changing economy so that we can all have the individuality we crave.

A few centuries ago we as humans possessed relatively little.  The tables we owned were crude, the dishes in ornate, and our clothes drab and expressionless when compared to today.  We were in an age of craftsmen.  A craftsmen’s work took time and was therefore expensive.  As a result we couldn’t afford much.

We moved from there to assembly lines and mass production where you could have nicer things – as long as you were willing to have the same nicer things as your neighbor.  As a result of mass production, producers had to find the things that would sell well to a large number of people.  The more people you could convince to buy the product you were making the more money you made.

The problem with mass production is that it required that a few items be produced in large quantities.  We needed to have one kind of car (Ford’s Model T – in any color as long as it’s black).  The costs of producing, inventorying, and distributing variations were too expensive to be cost effective.  The economics of mass variation weren’t cost effective.

However, today we’re living in a different world.  We live in a world of electrons not protons (bits and atoms as the book would describe it.)  Electrons move from one spot to another at lightning speed thus eliminating distribution costs.   Electrons don’t take up nearly as much space as protons … the result is the virtual elimination of storage costs.  Electrons flow through computers in a seemingly infinite number of ways resulting in a lower cost to produce the variation that customers want.

We live in the world of $0.99 music downloads, print-on-demand books, and streaming video.  In short we already experience the ability to purchase bits not protons – or at least the electrons are converted to protons at the last moment.  We don’t buy tapes or CDs as often as we once did.  Instead we purchase the music – and occasionally convert the electrons into protons  when we burn a CD to play in the car.  We order books which exist solely electronically and they are converted into printed form without our even knowing.  Sometimes we don’t even bother to have them converted as we buy eBooks.  Instead of a single one-size-fits-all video from the network affiliate we are increasingly a society that watches our video from the Internet.  We watch 3-5 minute clips of the news stories that we want to watch rather than 30 minute news broadcasts.

The Long Tail explores this idea – the changes that have been happening – and what it means for you and me.  If you’re trying to understand how to make money in an increasingly competitive world, it’s worth a read.

Wikinomics: How Mass Collaboration Changes Everything

Book Review-Wikinomics: How Mass Collaboration Changes Everything

I have to let you in on a secret. I don’t do this blog for you.  Not that anyone could honestly say that they do a blog for one specific person other than themselves.  You see while I’m happy that you (hopefully) find value in this blog.  That isn’t the real reason why I do it.  I do it because I am forgetful.  I need to remember stuff and frankly my memory doesn’t cut it anymore.  So I blog solutions, I collect information, and that way I can find it again – and my friends and clients can find it by searching.  (I’ve told many a client to search my blog for their answers.)

That isn’t to say that some posts aren’t really for you.  There are some that definitely are.  There are posts that exist because there was a client that wanted or needed something documented and they said it was OK to put it on the blog.  There are some intensely altruistic moments when I do truly do things for you – whoever you are – but mostly I don’t.

That’s why Wikinomics is so scary.  What do I mean by scary?  Well, I mean that I still don’t get the social networking animal.  Lawrence Liu has been patiently tutoring me, but still, I’m not 100% in the groove with it.  I still haven’t told you why Wikinomics is so scary … it shows real examples of how the power of social networking has brought about dramatic shifts in the way that we do business.

Everyone reading this blog probably has heard of Linux.  Most folks probably know it is open source.  It’s one of those examples people lay out when they talk about the new way that we’re working.  However, to let you in on a secret, it’s not really all about social networking – Linux is about many things not the least of which is a way for non-Microsoft organizations to make money.

Perhaps the most powerful mass market example – from my perspective – is Wikipedia.  Want to know about something?  Go to Wikipedia.  As long as someone like Stephen Colbert hasn’t been mucking with the pages you can generally get some good information on a variety of topics – for free.  There’s information there that I didn’t even know existed.  For fun, go to Wikipedia and query for your favorite corporation.

After a book full of examples of popular and less than popular examples of how the power of large numbers of people can change the world, I’m wondering what changes are coming that we’re not even seeing yet.  I must admit that I was genuinely concerned when I read the book – but then I became excited.

The real exiting part is what happens when the masses… the millions of productive human beings who work their 9 to 5 shift decide to start interacting with the rest of the world without the barriers of physical space limitations?  What if the tool and die maker comes home and does CAD projects off of a site like Mechanical Turk?  Why?  Not for money, the pay isn’t necessarily all that great but instead for the fun of it.

I know that there are some coding problems that are fun for me to solve, even if the reward isn’t that great.  (Don’t believe me?  How many of you know that I have half a dozen products that I sell – but don’t market?)  What happens when we change our culture from one where we “veg out” into a culture where we “turn on” our brains and start doing productive – or semi-productive work?

If I’ve got you the least bit intrigued, pickup the book Wikinomics: How Mass Collaboration Changes Everything and see what I mean.

Linked: How Everything is Connected to Everything Else and What It Means for Business, Science, and Everyday Life

Book Review-Linked

Some things come easy to me.  I see patterns.  I make connections that not everyone makes.  However, there are many more things that are more difficult.  I struggle to understand the idea of social networking, blogging, wikis, and forums.  They mystify me.  That doesn’t mean that I don’t try my hand at it to learn, it just means it doesn’t make that much sense.  I keep trying new things, new approaches, and start new conversations all seeking to figure out how it all works together.

So while I’m still reading software development titles because the journey that I’m on to be a better software developer – despite a decreasing amount of my time being spent that way – is a never ending journey.  However, I’m also beginning to inject social networking, long-tail marketing, and similar topics in an attempt, no matter how feeble to GROK it.

Linked is one of those books that I picked up upon the recommendation of a trusted colleague.  The book’s primary focus is networked thinking.  In other words, there is not one answer that drives everything.  It’s a series of complex interactions between all of the players that creates the play.  As someone who does a lot of IT work I’ve gotten quite familiar with a binary view of the world.  The code is either right or wrong.  The answer is either yes or no.  The hypothesis is either true or false.

However, the binary world of ones and zeros isn’t enough to explain the group dynamics of a user group.  Nor can it illuminate the reasons why a community thrives when another doesn’t.  It doesn’t well expose the single cause for success – probably because there isn’t one.

One of the great things about Linked was that it provides a great deal of information about a wide variety of subjects and pulls it all back to a central theme that many things are networks where one change impacts every other.  From eco-systems where animals are returned to a state of balance, to cancer, and to other far flung ideas a model emerges that things are connected to one another.

As an author and editor, I’ve read and written more than my fair share of material.  However, to be honest I’ve never liked reading academic papers.  I felt like the objective was to make the information harder to understand – to prove that the author is smarter than the reader.  The sacrifice I’ve made in this is that sometimes information that is quite good and relevant never makes it to me because I can’t coerce myself into reading the academic papers that the information is buried in.

This too was an interesting thing about Linked.  There were lots of very critical and strangely useful details buried in its pages and in very few occasions did I feel like it got to be too academic. (This is high praise if anyone’s trying to sort out what I mean.)  I felt like the author repeated his points from different angles without being overly repetitive.  He exposed some fairly advanced mathematical topics without wandering off into places that the reader couldn’t follow.

The short is that Linked helps you to understand how things are connected in every discipline, in every country, and in our every day.  If you’re struggling to understand how marketing works, how large systems function, or how coincidences happen, it’s definitely worth a read.

Software Craftsmanship: The New Imperative

Book Review-Software Craftsmanship: The New Imperative

I struggle to find the right way to express how to make software development right.  I can’t say that I subscribe to every idea that is put forth by Software Engineering.  The Software Engineering Institute does drive software development forward.  However, having had the opportunity to listen to a few of the speakers that work for the SEI, I can’t say that I feel like they’re in touch with reality.

The appealing thing about this book, Software Craftsmanship- the New Imperative, is the opportunity to take a different perspective towards software development.  I’ve always felt in some ways that building software was about getting a feel for the users, the technology and making them come together.  The idea that you don’t build software you craft it is certainly appealing.

The whole book puts forth the idea that we think about software wrong.  We take the few examples of large projects and expect that the experiences gained there will apply to every software project.  There have been numerous observations that the software development practices that we know, from these observations, lead to better software are routinely ignored or not followed.  Although there are many reasons for this, the reality is that we don’t do what we are taught to do.

The other end of the spectrum is the apprenticeship model that’s practiced in many other professions either from a formal structure or informally. Most trade professions have some sort of a process from taking apprentices and making them into professionals.  This is an approach that the author proposes we should be doing with Software Development.

In my own experience, I can say that both are needed – and the idea of software as a craft is widely under discussed in professional articles and books.  Despite this it’s the primary way that I teach, and learn, about software development and how to make it better.  As a coach and mentor I train developers to remember to watch error handling, to test, to think about boundary conditions, to care about the resulting code, and all of the things that make up good software.

They learn not through the one time reading and single verbalization of these ideas but through the continual reinforcement of the ideas and the continued application of the ideas to their work.

I learn through work with my colleagues.  They teach me their approach and I teach them mine.  Whether I alter my approach or they alter their approaches, we’re both better for the exchange.

The book is somewhat repetitive in places and over the top in others, however, it’s a good read if you can put aside the details and focus on the core message and evaluating it against the way that you do software development today.

Dynamics of Software Development

Book Review-Dynamics of Software Development

More than 10 years ago Jim McCarthy wrote the first edition of Dynamics of Software Development.  At that time it was a great book.  It helped identify specific behavior patterns that software development teams fall into.  Perhaps the most familiar behavior pattern is flipping the “Bozo bit” – in other words writing someone off as not a valuable member on the team.  Small nuggets of insight like this one are woven together into a tapestry of the behaviors you don’t want to see in your team.

But that’s where the 1995 edition of the book stopped.  You knew what you didn’t want to see and had sign posts to alert you that they were coming.  However, there was very little in the way of support for creating the right kind of behaviors and exterminating those behaviors that you had been warned about.

The 2006 edition in addition to the 1995 content has content designed to support your transition from a team where these behavior patterns are the norm to one where you’re looking for the rare case where there’s some bad patterns emerging.

The “Core System” as Jim and Michele McCarthy describe it is a set of patterns, antipatterns, and “Core Protocols.”  The “Core Protocols” are as set of specific behaviors which support the proper working of a software development team and inhibit the growth of some of the other patterns that are not so favorable.

Dynamics is a book that every development leader should read.  More than that — it is a book that should be used as content for team meetings.  By dissecting one of the 57 rules included in the book you can generate a few minutes worth of discussion on a single, important software development project so that you can move the team forward, one sound byte at a time.

Agile Software Development: The Cooperative Game

Book Review-Agile Software Development

With all of the books with “Agile” in their title today why would anyone want to single out Agile Software Development in particular?  My reason was the author Alistair Cockburn.  Alistair has been a part of the agile movement being both an original signatory on the Agile Manifesto and the proponent of the Crystal Clear methodology.  In other words, the resume isn’t bad.

Agile Software Development is both interesting and unique because it’s unlike other books about agile development that you might read.  First, it’s in some ways more of an extension of Peopleware and The Psychology of Computer Programming.  It talks about why developers behave the way they do without condemnation or excuse.  It speaks about the way things are and what you can do to get better results.  Alistair’s understanding of the dynamics of communication can help you construct solutions that allow your team to communicate more effectively.  Either its “rearranging the furniture” or “vandalizing the walls” there is an understanding into the psychology of how things work – and why they work that can be effective whether you’re deciding to adopt an agile methodology or not.  (“rearranging the furniture” and “vandalizing the walls” aren’t his terms – their my colorful summaries of things like evaluating communications like the dispersion of heat or a gas and a concept that Alistair refers to as information radiators.)

On the topic of methodology there’s a lot to be had as well.  I’m preparing for a web cast titled Defining Your Own Software Development Methodology.  In that web cast we’ll be talking about how to create – or more appropriately tailor – a methodology for your organization.  In addition to having some great “sound bites” for that discussion, the model that Alistair uses to talk about methodology creation has influenced some of the web cast material.  Coverage of the characteristics of a methodology, the way to approach usage, and the impact of lighter and heavier methodologies have all been positively impacted.

I’ve always respected the simplicity and usefulness of Alistair’s breakdown of projects based on size and criticality.  The breakdown of criticality into Loss of comfort (C), loss of discretionary monies (D), loss of essential monies (E), and loss of life (L) has been quoted many places.  The reason I appreciate it so much is that it simplifies the task of speaking of the size and characteristics of a software development effort into something that can be quickly understood by all.

As both a word of caution and one of praise, Agile Software Development doesn’t take a formulaic approach to delivering the content.  Instead it gives you all of the components you need to understand how things work and leaves the exercise of making it work to you.  While I find this approach very appealing because I am looking for different views and perspectives which I can add to my toolbox, it may be frustrating for readers who want someone to tell them what “the answer is.”

I leave you with one of my favorite sound bites from the book (p71):

“Although heroes who work overtime may be needed to save poorly run projects, there is a much more interesting phenomenon to observe: ordinary people doing their work with a sense of pride and community and in doing that work noticing something wrong, passing information to someone who can fix the problem, or stepping out of their job descriptions to handle it themselves.  This is an indicator of a community in action, not an indicator of a poor development process.”

Agile Software Development with Scrum

Book Review-Agile Software Development with Scrum

If you regularly read this blog then you know that I’ve been doing a lot of reading and reviewing of agile methodology books. (Agile & Iterative Development: A Manager’s Guide, Balancing Agility and Discipline: A Guide for the Perplexed, etc.)  It’s a curiosity of mine both in terms of looking for things that can help with current methodologies and how one might do the best implementation of an agile method in a project.  I’ve also been reviewing more traditional software development titles to see how they might be useful in making projects more successful (The Security Development Lifecycle, The Psychology of Computer Programming, Peopleware, The Rational Unified Process Made Easy: A Practitioner’s guide to RUP, etc.)

One of the challenges is finding a book that talks about real world experience with agile methodologies.  Agile Software Development with Scrum is that book.  While Ken Schwaber and Mike Beedle are careful to include the fundamental psychology that makes Scrum work, they also share many personal experiences with how projects have succeeded or failed – and what factored into those successes and failures.

While the book won’t make you a good Scrum Master right out of the gate, it does go farther than other books in explaining the psychological underpinnings of Scrum ideas so that you can adapt the methods to suit your needs – most Agile proponents and books advocate a “no changes” sort of policy.  While this book doesn’t directly encourage making changes it takes a much softer line on the issue than previous agile development books.

Whether you’re looking for the practical details of how to implement scrum or the background to understand why scrum works, you’ll find an answer in Agile Software Development with Scrum

Blink: The Power of Thinking without Thinking

Book Review-Blink

Back in January I read (and reviewed) Malcom Gladwell’s book The Tipping Point.   I liked it so much that Malcolm’s next book, Blink, quickly made my reading list.  I don’t read many books that don’t have some sort of technology tie-in so Blink was a good change of pace.

The basic overview of Blink is a walkthrough of how we make snap decisions (quick decisions), why they’re mostly right, how that works, and how to make better use of the unconscious thinking that goes into  those quick decisions.

The subtitle “The power of thinking without thinking” is appropriate because it exposes how our unconscious mind is always thinking about the situations around us even when our conscious mind is not.

It’s a great exploration of the topic – particularly since I’m fascinated by the change that takes place from the first time you do it vs. when you’re proficient at it.  Flying for instance.  The first time I flew a plane it was way too much information.  I couldn’t do things fast enough.  I couldn’t evaluate all the variables faster than the plane was flying.  Now I don’t even consciously think about the variables involved in landing a plane.

If you’re interested in how you make snap decisions, why they’re right more often than not, and what to do about the situations where you’re not right, Blink is a book you should read.

The Security Development Lifecycle

Book Review-The Security Development Lifecycle

The need for a higher level of attention to security in applications is something that we must unfortunately deal with.  Finding a set of developers with an intrinsic knowledge of security is much like looking for a taxi cab when it’s raining.  You know they exist but you don’t know where to find them.  That’s why you need a framework for creating the right kinds of security awareness, knowledge, and discipline.

If you wanted to find an example of an organization who clearly exemplified the problem a few years ago and one which had made great advancements in the area of security, the best example may be Microsoft.  Microsoft was once the favorite target for hackers and the media, Microsoft is making progress towards becoming the most secure products available.

The Security Development Lifecycle is a look at how Microsoft has made this transformation with specific guidance on what to do, how to do it, and what the impacts are.  Asides within the text highlight items that worked well for Microsoft but may not work well for your organization – and techniques that were expected to be greatly helpful but were not.

The book is amazingly insightful in terms of its view of the problem.  There’s no bravado about having all the answers nor is there any concrete feel to these are the only answers.  It’s a good discussion about what has worked in practice.  The authors clearly believe that new types of security vulnerabilities raise their heads as new attempts are taken by security researchers to break the software that we produce.

While the details of individual lines of code are not thoroughly covered, the core concepts are explained well and with enough detail that you can develop your own coding practices which are inline with the overall security strategy.

This is a must read for architects and development team leaders who are concerned with the security of their code.  It’s a great read for those developers who have an interest in leading a development team at some point.