Craig Pardey

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:

The question of location comes up a lot in software consulting. Will the work be done on the client’s premises, or the consultant’s? There’s no right answer. Some clients don’t have the office space to accommodate an entire development team. Others already have a large IT department and want the consultancy’s team co-located with their existing staff.

Working at the consultancy’s office may afford certain perks like a relaxed dress code and flexible hours (are there still inflexible hours?). At the client’s site, the developers will have greater access to the people they need to talk to.

A thread appeared on Hacker News recently about how successful people operate. The comment below really struck a chord with me.

• Don’t waste time.
• Be mission/vision focused.
• Be polite to everyone always.
• Be helpful whenever possible.
• Be insanely organized.
• Seek and respond to constructive feedback on your work.
• Do the shit work without whining.

All of this will build human capital with other people in the organization, which will both practically give you more resources of help from others to draw on in your work requirements, but also increases your visibility with people who aren’t on the front lines doing the work (e.g. Management). That visibility gives you the means to move in whatever direction you might desire. It also (for want of a better way to put it) usually tends to help make you layoff-proof because people know you are competent, professional, and have some flexibility to work as part of a team.

[Read More]