My Addiction

I’m addicted to TED talks. There have been many nights where I’ve stayed up way too late watching them. For those who are unaware, TED is a yearly conference where world leaders and thinkers gather to share their ideas and spread their passions and work. I’m someone who gets fired up listening to outher people’s passions. I love hearing about what gets other people excited, what makes them tick, what makes them want to share with the world.

One of the more interesting talks I’ve listened to recently is by Tim Brown at the Serious Play conference of 2008. Tim talks about how the elements of play can improve creativity and productivity in our workplace and life. I found the lessons learned from this talk something that can be very directly applied to software development, and taking some of these nuggets of teaching can help me be a better thinker and worker.

Playing a Game

The first exercise Tim does is to play a game with the audience. It’s quite a
sophisticated adult thing to stand up on a stage and spend 20 minutes talking
about play, but it’s another thing entirely to actually do it. Brown has the
audience perform several games. One of them: Drawing a picture of your neighbor
in 30 seconds. He does this primarily to demonstrate how adults are cultured to
shy away from play. After all, a civilized adult does not seriously use crayons
and markers to do any real work right? After this exercise he talks about how
when this test is given to adults, they often apologize to their neighbor, feel
embarassed, or otherwise don’t enjoy the play at all. When the same test is
given to a group of children, they don’t complain or apologize: They simply do
it and have fun with it. This teaches us a valuable lesson about how our
culture is geared toward play. When we’re younger we go from schools that look
like this:

photo credit: LizMarie

And slowly we evolve to workplaces that look like this:

photo credit: Wyscan

This reminds me of the game that my colleague Michael Walkden played at Agile
Conference 2009. Participants are asked to build a building out of LEGOS, and
through this play, they discover some of the benefits of working with Agile
methods. When Michael was telling me more about his experiences playing this
game with audiences one of the questions I asked him was, “Don’t you think if
we did this exercise with a client it’d be hard to convince them to take
playing a game seriously? Most people would see it as childish.” To which he
responded yes, sometimes it can be difficult to convince a client to play and
‘get into it’. There’s a certain level of discomfort for play that we can have
as adults. We fear looking stupid, making a fool of ourselves, or getting too
caught up in what we think is the business of children. Michael went on to tell
me that once a client gains a certain level of comfort with playing, the value
gained from doing these kinds of exercises is enormous.

Modeling a Problem

Brown goes on to talk about the benefits of rapidly building a physical model
for a problem.  When we were children we learned by touching and doing.  This doesn’t change when we are adults.  No matter how good we are at thinking abstractly as humans,
there’s something about having a tangible model to work with that makes
us feel more connected to the work we’re doing. Something to touch, feel
and hold brings great benefits to our creativity and imagination. This
reminds me of a neat talk I watched by Damien Katz, the creator of CouchDB. Among other things, Damien talks about when he switched to have CouchDB use HTTP and JSON what he felt like for the first time he could ‘touch the data’:

“I was so excited when I first started testing it out. Because a big
goal with CouchDB was that you would be able to feel like you could touch
your data, like it was right there in your hand. There’re certain tools
where you have this responsiveness and you don’t feel like there’s all these
layers between you that are obfuscating what you’re trying to get
at.”

Isn’t this something we should set as a design goal for all of our software
projects? Shouldn’t we strive to have our users feel like they’re in control of
the computer, and not the other way around? When we use tools that allow us to
quickly and easily touch our ideas, we reap the benefits of not only enjoying
our work more, but being able to flesh it out more quickly and productively.

In Brown’s talk, he tells a story about how a group of surgeons were trying to
come up with a solution for a new surgical tool. They spent a good amount of time saying something like, “It’s sort of like this tool, combined with this other one, but it also has some elements of this tool.” Finally, one of the surgeons went away for a few minutes, and came back with a white-board marker taped to a handle and said, “Is it something like this?”, to which everyone agreed, “Yeah, that’s exactly what we need!”. We see this often with software. “It’s kind of like Facebook with a mixture of
Wikipedia, but it focuses around people who study animals professionally.”
Wouldn’t it be more powerful to have a working prototype to show what it is? To
let people play with it, to let them touch it and experience it rather than
spend hours in meetings talking about what it? When you’re stuck in a waterfall
process, it can be easy to get lost in the weeds of abstraction and
uncertainty. Spending months designing specs and not making anything
‘touchable’ can be a long death march that leaves all parties unfulfilled and
unsatisfied. Let’s spend our time making things that are fun to touch and play
with instead.

Moving Forward

So I throw this out as a question to everyone. What do you think about the
current state of play in the software industry? We’ve seen the power of play,
experimentation and fun in the free software world. Do you think it’s relevant
in commercial software industry? If so, how can we break down barriers of
discomfort in order to encourage our teams to grow and play?

Related Services:
Agile Development, Custom Software Development

Share/Bookmark

photo credit: Rennett Stowe

For a developer who’s new to pair programming, it can be overwhelming and
difficult to adapt to pair programming practices. As developers, often the natural
tendency is to hole away and solve our problems on our own: we thrive on the
thrill of achieving the solution. The satisfaction of arriving at that solution
on your own can make you feel good, but it has other costs. If you’re new to
pair programming and feeling initially discouraged about the dynamics of
pairing: Don’t give up! Pairing is a skill that must be developed and honed just
like any other one.

Arranging your brain

One of the interesting things about pair programming is how it exercises
different parts of the brain. Suddenly you are required to manage the social
dynamics and conversation of another person while you are working on the
problem. A solo developer can shut down that ‘communication’ side of their
brain, put the blinders on and go (Something that can affect the quality of your
code). If you’re finding yourself mentally drained at the end of a pairing
filled day, don’t be discouraged – these are things that I wrestled with when
learning how to pair. When working solo it’s much easier to take those 2 minute
breaks to check the latest news headlines or your favorite blogs… Something
that doesn’t really happen when you’re pairing. It’s so much easier to stay
focused when working with someone else on the problem. As you do it more your
mind will become more comfortable working for those longer stretches of time
(Just don’t forget to take breaks every once in awhile!).

Giving up control

As a programmer, I get great satisfaction out of being the ‘master of my
universe’. I design the objects, the methods, the properties and make the whole
thing fit together. This is all fine and dandy when you’re developing something
in your basement in your free time, but doesn’t work so well in a fast paced
business environment. Pairing breaks down the barriers of code ownership and
knowledge hoarding. A poorly designed module or class becomes significantly
harder to rewrite when the functional knowledge of that module is possessed by
only one person. On top of that, the developer is much more likely to feel
resentment about having all of their precious work thrown away even if it is in
the name of better design principles and progress. If you’re new to pairing you
may feel frustrated by this. The satisfaction of your paired work is often
harder to see if you’re used to developing solo. Trust me when I say that the
longer you spend pairing, the greater satisfaction you will find from the
ability to tackle tougher problems with the wielded power of two minds working
in unison. That entire database model refactor won’t seem as daunting or
annoying if you’ve got somebody to share the ride with.

Pairing styles

One thing that’s neat about pairing with another person is it opens up many
insights into different workflows and ways to tackle problems. People have
different ways to approach a problem, and the knowledge transfer between the two
developers is huge when working as a pair. People also have different styles of
pairing; Some people are more explicit about their thought process and can
articulate very easily what they’re thinking. Others may need to a little
encouragement to share their thought processes and bring you up to speed.
Keeping on the same page can be difficult at first, especially if you’re
learning a new framework or programming language. You don’t want to look like an
ignorant or unknowledgable person. Having the courage to speak up and say, “You
lost me there, can you go over your thought process one more time?” is hugely
important. If you’re getting left behind during a pairing session and not doing
anything about it, it can nullify the goals of pair programming entirely.
Learning how to manage different pairing styles and how to switch mental gears
quickly and easily can pay large dividends when you master it.

Final thoughts

As someone who is new to pair programming, there have been growing pains I have
gone through in order to gain a higher level of development productivity. I’m
still going through them as I learn new things each day. If you’re newly
switched to pair programming as a development practice and having trouble
getting used to it right out of the door, be patient. The product of your work
will be much more satisfying if you can share the success of that work with your
fellow developers.

Related Services: Agile Development, Full Life Cycle Software Development

Share/Bookmark

Intro

Head First Rails by David Griffiths is one of the newer additions to the Head First series by O’Reilly. It provides an excellent introduction to Web Application development using Rails as the underlying framework. Head First books take a much different approach to learning development subjects than most texts. The pages are filled with humorous drawings, novel dialogs, and funny diagrams to keep your brain stimulated (and entertained). This being the first book I’ve read in the Head First series, I much enjoyed the conversational style and approach David Griffiths took to teaching.

Starting Off

The book presents it’s projects as sets of real world problems. For example, the first problem Griffiths gives you is conveyed as an email from a friend who needs help developing a basic ticketing application for his company. The features and requirements are basic CRUD, and lend themselves to learning about Rails scaffolding. Griffiths covers setting up your rails application, getting your database up and running, models, migrations and other basic essentials.

As the book continues, and as new problems are presented to the user – Griffiths slowly removes the scaffolding and teaches you the internals and structure of a given Rails application. My favorite parts of the book are titled, “There are no Dumb Questions”. This is the kind of section that I would love to see in all programming books I read; especially introductory ones. Many authors tend to take for granted some of the subtleties and ‘gotchas’ when teaching a new topic, and this section lends itself quite well to those questions that are often easily skipped. Chapter reviews and short quizzes are also given in several different formats, with the philosophy that everyone has a different learning style – Quite appropriate if you ask me.

Dealing with Obstacles

One of the big hurdles of people who are new to Rails is usually figuring out where everything goes. After starting a new Rails project, it’s easy to be overwhelmed by all the new files and folders if you’re not familiar with the directory structure and layout of the framework. Griffiths does an excellent job along the way clarifying what part of the project each item should go in (model, view, controller or otherwise). Coupled with this, he also does an excellent job diagraming the framework execution process as it passes from the user action to routing, controller, model and view (and possibly other intermediate stops). At it’s core, he’s trying to teach an understanding of the entire process rather than teaching memorization – something that resonates much better with me.

Advanced Topics

The book finishes by touching on some of the more advanced topics of Ajax requests, XML and REST. Although these might seem like daunting topics for an introductory book, Griffiths does a wonderful job keeping things simple, and giving the reader an excellent taste of some of the more powerful avenues of web application development. The focus here is doing something cool: He’s trying to interest the user’s imagination and get them excited.

One criticism I have for Head First Rails is it’s lack of unit and functional testing. It’s quite possible that a new user might have no interest in learning testing, and thus it might come as an obstacle to enjoying Rails. But seeing as how it’s a main header on the official Rails Guide, I would say that it’s at least worth a mention. Quoting David Griffith’s interview about the book:

“So really the whole book is about how to do cool things. Like build a custom web application in two minutes. Or manage multiple data sets in a single interface. Or create a mashup with Google maps. Or using Ajax in really practical ways, not just for eye-candy. Cool is really just another word for powerful and I want people to finish this book armed with practical skills that they can apply from the get-go.”

Perhaps this is why testing has been excluded from the book. But again, I would have liked to see it touched on – if only briefly.

Is Head First Rails worth reading?

If you’re looking for a detailed technical manual or API reference, this is definitely not the book you’re looking for. If you have never done any web application development, and want to try Rails as a way to get started – This book is for you. Head First Rails assumes you:

• Are comftorable with HTML
• Have experience in another programming language like Java, C#, or PHP

Head First Rails provides a clear and easy to follow jump into Rails and works as a great gateway down other web development roads.

Share/Bookmark