Agile developer practices

“Practices of an agile developer” is an interesting book, I began reading it with an buying-time thought: just a dry reading while waiting for the restropective meeting. Well, I have to admit I was completely wrong.

Having read “The pragmatic programmer” before, yet I didn’t expect Andrew Hunt (Andy Hunt) to bring some new insight to this successor book. And it turns out to be a successful successor, IMHO. The most notable difference from the first book is social engineering practices, this book highly focuses on that, whereas the previous is fond of software engineering practices .

Being a software developer, I have seen myself and several other people had some weaknesses in social skills. For example, to have big ego and strong defensive words whenever “my code” being reviewed (or modified). There were some very kind people who helped me aware of “egoless programming” , to know when to suppress the ego, when listening is really a chance to improve. Thanks to that I managed to avoid countless of trouble later on, although I still failed on those ideas sometimes.

Back to the book, I wish I could have read it earlier (first published 2006, FYI). It has some insightful explanation on each practice, somehow like the Ten Commandments of Egoless programming, but even more: real world examples, how one may respond in a negative way (“devil” thought), how one should act in an “Agile” way (“angel” thought), how to be not extreme, and a little programmer humor, too!

The only negative I found in this book is the word ‘Agile’ is a bit over-used. Actually in many context, the word “Agile” can be substitued by “professional” , which in turn implies some other words: accountable, skilled, self-discipline, helpful . But after thinking over again, that is not actually a bad thing, but a smart reason: Agile was a buzzword those days. Personally speaking, this book can be renamed without “Agile” word : “45 practices of highly effective developers” , or “Solid advices for developers to practice everyday” :-)

.

Well, let me extract some of my favourite practices from the book:

+ Work for Outcome + Code in Increments + Keep It Simple + Keep Others Informed + Allow People to Figure It Out  + Criticize Ideas, Not People

.

Work for outcome

Typical situation: A problem arises, and now the team is aware of it.

Non-agile: Address the problem by publishing the person who cause it, i.e. “Finger Pointing” .

==> Making people feel defensive ===> people spending most energy discussing who to blame (“Casting Blame”), or even: taking pleasure in talking about each other’s mistake (“Holding A Grudge”)

Agile developers : Blame doesn’t fix bugs. Instead of pointing fingers, point to possible solutions. It’s the positive outcome that counts.

==> To avoid: inadvertently fuel the problem by saying whatever just popped in the head. ===> To explain: Fixing the problem SHOULD be the top priority, not the credit/blame contest . The agile team should focus on the outcomes (solutions), by either supporting (“OK, what can I do to help you with this?”) or solving (“What can I do to solve this or make it better?“) .

Keeping balance:

Minimum: redirect the conversation away from the negative blame game toward something more neutral (“So, how about the football match yesterday?“)

==> Everyone makes mistake sometimes, and even if that is not a learning opportunity, that does not necessarily become a witch hunt. ===> It’s often quicker to fix a problem than argue about it. “It’s not my fault” is rarely true. “It’s all your fault” is usually equally incorrect. If there is misunderstanding repeatedly, just make sure the whole team is up to the speed on the issue (not in a person, again) .

.

Code in increments

Agile developers : Write code in short edit/build/test cycles. It’s better than coding for an extended period of time. You’ll create code that’s clearer, simpler, and easier to maintain.

Keeping balance:

If the build and test cycle takes too long, you won’t want to do it often enough. Make sure the tests run quickly.

When you take a break, take a real break. Step away from the keyboard.

.

Keep It Simple

Agile developers : Develop the simplest solution that works. Incorporate patterns, principles, and technology only if you have a compelling reason to use them.

Keeping balance:

Keep the goal in mind: simple, readable code. Simple solutions must, of course, be adequate – compromising features for simplicity is merely simplistic.

Code can almost always be refined even further, but at a certain point you won’t be getting any real benefit from continued improvements. Stop and move on before you hit that point.

.

Keep Others Informed

Agile developers : Keep relevant people informed. Publish your status, your ideas and the neat things you’re looking at. Don’t wait for others to ask you the status of your work.

Keeping balance:

Don’t spend more time or effort keeping others informed than actually getting your work done.

When presenting status, make sure the level of detail is appropriate for the audience. For instance, CEOs and business owners don’t care about obscure details of abstract base classes.

.

Allow Others To Figure It Out

Agile developers : Give others a chance to solve problems. Point them in the right direction instead of handing them solutions. Everyone can learn something in the process.

Keeping balance:

If someone is truly stuck, don’t torment them. Show them the answer, and explain why it’s the answer.

If the problem are nearly solved, answer the question with another question that leads in the right direction.

.

Criticize Ideas, Not People

Agile developers : Criticize ideas, not people. Take pride in arriving at a solution rather than proving whose idea is better.

Keeping balance:

Always try to contribute a good idea, but don’t be upset if your ideas don’t make it into the product.

Being unemotional does not mean you blindly accept any and all ideas presented. Choose the right words and reasons to explain why you can’t see the merits of an idea or solution, and ask clarifying questions.

.

.

Thank Mr. Michael for lending me such an inspiring book !

.

./.

Bonus: https://youtu.be/cf_rqQPfMdk