Craig Pardey

This is a continuation of my post about clean tea, except this time I analysed the offerings from Teavana® (a Starbucks company).

Teavana® by the numbers:

• 101 teas (excluding kits and samplers)
• 70 contain sugar and/or flavourings
• 31 caffeine-free
• 4 had no ingredients listed

So I filtered the list to only show teas with:

• No caffeine
• No sugar
• No flavourings

Only one tea on the Teavana® menu passes my filter for what I would consider to be “clean”. It is … (drum roll) …

I recently weaned myself off coffee. My daily intake levels were well above normal levels, as was my tolerance. The only thing it was doing for me was preventing me from getting a good night’s sleep. So I decided to quit. I spent two weeks cutting back, and then went cold turkey over the Labour Day weekend.

I’m now sleeping much better, and no longer need that morning jolt to get me going.

This is a quick cheat sheet taken from a great little book called “The 22 Immutable Laws of Marketing” by Al Ries & Jack Trout. I highly recommend this book for anyone interested in marketing … even developers!

The Law of Leadership
It’s better to be first than it is to be better.

The Law of the Category
If you can’t be first in a category, set up a new category you can be first in.

Configuring Hubot to work with a self-hosted HipChat server took a bit of tweaking, so here’s a quickstart guide based on what I discovered along the way.

First of all, follow Atlassian’s guide to create a copy of Hubot. This will download the source code including the HipChat adapter.

$ npm install -g yo generator-hubot
$ mkdir myhubot
$ cd myhubot
$ yo hubot --adapter hipchat

Answer the questions, and you’ve got a basic bot config

Me: Why is this report different to the one in production? SysAdmin: Dunno. I guess they must have fixed it production and forgot to check it back into source control.

If I had a dollar for every time I’ve had that conversation I’d be a rich man. It is usually the result of some late-night troubleshooting and finally the system is working as expected and everyone goes to bed. But the next day, nobody remembers what exactly they changed that fixed the problem, nor do they spend the time to figure it out and get it back into source control. Worse yet, they were making untested changes in a live environment - that shouldn’t be possible!.

There’s nothing that beats the feeling of being part of an exceptional team and yet it is strangely difficult to define exactly what makes one team great and another team not-so-great. Google recently set out to learn how to build the perfect team and came up with some interesting, albeit previously discovered, answers.

To summarize their findings, Google’s Project Aristotle concluded that on good teams:

1. All team members spoke roughly the same amount, and
2. Team members were empathetic towards each other

Harvard Business School’s professor Amy Edmondson described this as “a sense of confidence that the team will not embarrass, reject or punish someone for speaking up”. This may seem obvious until you find yourself on a team that crucifies anyone for speaking their mind. I have experienced those teams first hand, and believe me, they’re no fun. Conversations become antagonistic and argumentative and the team dynamic rapidly degrades.

I’ve been pushing large enterprises to adopt agile development practices for years so I was very excited when I began seeing many of them embarking upon ambitious Agile Transformation projects where they attempt to not only change the way they build software, but completely revolutionise the entire IT process from inception, finance, HR, delivery and operations.

But they rarely discuss culture.

“Culture” in this context is used to broadly describe how people behave in the company.

Agile has gained a lot of traction in large enterprises in recent years but I’m concerned about the specifics of how teams are implementing it. I’ve seen everything from traditional eXtreme Programming (XP) practices to Scrum, but nothing scares me more than the teams that self-identify as “agile” but do nothing more than hold a daily team meeting.

Agile means different things to different people, but it doesn’t matter which methodology is used as long as the principles outlined in the Agile Manifesto are adhered to. Holding a daily hour-long meeting does not an agile team make. It’s almost anti-agile.

I have used automated build tools on all my projects since 2000. Back then it was CruiseControl in all its XML-configuration glory. Today it is usually Jenkins, or sometimes TeamCity, and I recently tried out ThoughtWorks Go. The user interfaces have generally improved over time, and now there is probably a “plugin for that” thing you used to script manually, but overall not much has changed in the last 15 years.

In fact, I feel that The Build is actually flakier now than it was then, mostly due to the increased complexity.

Externalizing application configuration values into a properties file is a common pattern in enterprise applications, because it gets the environment-specific settings out of the code and avoids the need for environment-specific builds. Being able to deploy the same binary to multiple environments (Dev, QA, UAT, Production) is a Good Thing.

I came across an interesting quirk in an application recently. I needed to change the port of the application server for one of the app’s components, and the port value was wired up via Spring using some code that looked like this: