Harry Bailey

Harry Bailey works directly with agency leaders to improve how delivery works — helping them understand what's driving overruns, rework, and delivery friction, prioritise what to tackle first, and build the habits and ownership that make improvements stick. With more than twenty years in project delivery, agency leadership, and operational change, he brings hands-on support to the people and practices at the heart of how growing agencies deliver.

Quick and dirty export of AWS Elastic Beanstalk Environmental Variables

A very quick and dirty way to export key and value pairs from web console of elastic beanstalk environments config page.

While viewing the elastic beanstalk config page containing the variable inputs paste the following into your browser console.

var strs = [], inputs = $('.properties-table input');
$.each(inputs, function(key, input){
  if(!((key+1)%2)){
    strs.push(inputs[(key-1)].value + ' = ' + inputs[key].value);
  }
})
console.log(strs.join("\n"));

Moving the default Bitnami AWS Lightsail document root

When you set up an Apache or LAMP Lightsail instance on Amazon Web Services, the default document root is /home/bitnami/htdocs/

If you are migrating to Lightsail already use something other than htdocs as your root folder, for example public_html, then you might want to update this.

Although you could creating a new app on the server to hand it, here is a simpler option which leaves the default folders and setup in place:

In /opt/bitnami/apache2/conf/bitnami/bitnami.conf add your own document root to the end of every location that htdocs is mentioned.

Then

sudo chown -R bitnami:daemon /home/bitnami/htdocs/*
sudo chmod -R g+w /home/bitnami/htdocs
sudo /opt/bitnami/ctlscript.sh restart apache

And you should be good to go.

Onboarding through pair programming

pair programmers looking at screen together

There was a manager I worked with recently who was having serious trouble with their onboarding process.

Working with several teams of between 5 and 8 developers, the business was growing fast and recruiting at all levels. Some of the recruited developers were straight out of a code academy, with minimal experience of working in a team, on a regular release schedule, or with production code.

These less experienced developers were their primary challenge. The one they thought could release most value. But how do you get a developer enough experience to graduate them to being part of a team? How many of these developers can you put into a 5 to 8 person team and the team support their learning and progression so they might become independent? How do you introduce them to the team? What does the average day look like for one of these developers while they learn the ropes?

Continue reading

False Heroes in Software Delivery Teams

We’ve all worked with developers who prefers to get on with their coding alone. They’ll assign themselves a large set of tasks, tell everybody they’ve got loads to be getting on with, put their headphones in and you won’t hear from them for several days.

They might pin their name to a key change or issue, make all the required decisions alone and get it ready for deployment in record time. They may even be able to resolve complex issues with infrastructure or libraries, but not have the time to share those processes.

You likely know these type of developers by the names Ninjas, Wizards, Rock Stars, or 10x. These are terms of endearment used in praise of the activities above, or even in job advertisements looking to recruit developers with these habits.

What these behaviours actually do to your development team could not be further from a positive outcome.

Don’t get me wrong, the short term progress can be impressive. So impressive in fact that managers, and often less experienced team members won’t be able to help but praise our False Hero. Speed is always seen as a good thing in a word of complexity and deadlines. Solo progress without the need for peer input is often seen as something to aspire to.

Continue reading