I’ve finally gotten around to reading the Phoenix Project! With practical advice on how to improve the performance of an IT department, it’s a great read for anyone who is involved with software projects.

It’s a spiritual successor to the AMAZING book, the Goal. It takes Goldratt’s principles and applies them directly to the software development world. It does a great job at doing this, but I would definitely recommend you read the Goal first to fully appreciate the lessons provided.

Who this book is for

Unlike the goal, the phoenix project is focused on IT delivery. The story follows an IT manager and how he turned around a failing IT department within a failing company.

Obviously this book is a great fit for anyone involved in the delivery of software but the lessons in it could be applied to many different situations.

Erik

The first thing I’ve got to talk about in the book is the enigmatic guru Erik.

Throughout the book, Erik gives little pieces of advice to the protagonist to help him improve the situation of the company. To be fair, I agree wholeheartedly with the lessons, but I think the way he delivers them is shocking. An example of his unacceptable behaviour is he refuses to use people’s correct names until they agree with his points.

Just because you may know more than someone on a particular topic doesn’t mean that you should talk down to them. If anything, it is the opposite, you should work with someone to understand what experience gave you that knowledge and share it.

Now my rant is over I’ll look at some of the great ideas in the book.

What I enjoyed in the book

If you only take one lesson away from the phoenix project it should be to identify and widen your bottlenecks. A bottleneck is an area in your business that has the smallest limited capacity and therefore is restricting the flow of the system.

In the book, the bottleneck is an engineer called Brent. Brent is the only one who knows how a lot of systems work. So a lot of work gets piled up behind him in the system. By identifying this as a bottleneck, you can start to look for ways to widen it. Ideally this would be to train other engineers on the activities Brent does. But even having someone helping him would be good. The person helping him might not feel as efficient as they are not doing “their job” but the system as a whole will improve.

Focusing on where the value is also massively important. Rather than continuously starting more work that never makes it to live, focus on the work that is closest to live. Visualizing the work in progress can be massively helpful with this. There are loads of tools such as Trello that can help. Or even using cards like they do in the book.

Many small deployments is another realization that they came to in the book. I couldn’t agree with this more. If deployments are a scary struggle, don’t wait and bundle them all together for a big bang release. Do them more often!

To help with his you should be looking at automating your deployments. If there is a human element within a deployment method, at some point it will definitely go wrong.

Great book, now go read the goal

The phoenix project is a decent book with a lot of good points being made.

Anything that advocates for better delivery of software is worthy of reading. However it’s not been able to replace my love for the goal. I found the lessons in the goal to be more impactful for myself. This was down to the goal not being software oriented and I had to see how they applied to software delivery myself.

With so many services available, AWS has made cloud development much easier. However, navigating around so many services can be a little confusing. Using the one click navigation bar, you can get to the services you use the most easily and quickly.

Setting up the toolbar

Setting up the toolbar is super easy, but it’s not immediately apparent that the tool bar even exists, never mind how to set it up.

Firstly, click the push pin icon at the top of the AWS console;

Then drag any commonly used AWS services to the top of the screen;

Once all the services you want are at the top of the screen, click the push pin again to finish.

Hopefully this little tip will help people save some time when navigating around the AWS management console!

If anyone knows any similar tips I would love to hear them.

Retros are awesome. The chance for a team to come together and review how things are going is a huge opportunity to improve.

They should be open, honest, and engaging. It’s very easy to forget that they should be engaging. That’s why I like to try different formats when I get the opportunity to run a retro.

The elevator pitch

A common retro format is “stop, start, continue”, or a variation on that theme. It’s a common format because it is effective. I think it encourages people to be honest while reminding them positivity is also important.

However, I often find that in a retro where people are asked to give as many ideas as they want, they feel obligated to come up with lots of ideas. Even ideas they don’t particularly want to discuss themselves. Then you use up a lot of time as people deliver all these ideas back to the group and then more time as they are grouped together.

In the “elevator pitch” retro, each participant gets just one idea to pitch to the group to discuss. This can help to make people edit their own ideas and focus on what is truly important to them.

As people are only delivering one potential discussion topic to the group, hopefully they feel like that have more time to fully explain their point and the group will better understand their idea. Furthermore, the time saved on grouping many ideas can be spent on further discussions.

My experience

I’ve found running the”elevator pitch” retro to be a useful format for a retro. Often when people are asked to quickly deliver all their ideas on post it notes to the team; they can go into great detail, using a lot of time, or they gloss over important ideas.

By giving each person an allotted time about the one point they want to talk about it can help to focus the discussion. The extra time to explain their point can also help the group to decide if they would like to discuss it further.

If anyone has any other retro ideas that have worked well for them I to our love to hear them!

I’ve just seen a really useful option for curl commands; using the output option to save the return value to a file.

Using curl

Curl isn’t a tool I use everyday, but whenever I do, it always impresses me at how useful it is.

By using curl on the command line or in scripts, you can automate grabbing data from URLs. This can be super useful to speed up manual processes. By using the curl options to check things like headers you can quickly get through a lot of URLS that would have taken a long time by using a browser manually.

Output option

Using the output option, the data returned from the curl command will be saved to a file rather than stdout.

For example;

curl http://myurl.com -o myfile.txt

or

curl http://myurl.com --output myfile.txt

You can check out the rest of the curl options here.

Future processes

I saw this option while downloading the install script for the Python package installer (pip). But I thought this would be helpful in automating processes where I had to get information from URLs and save the outputs, then use those files as an input to another process.

If anyone else knows of any useful curl options I would love to hear them!

I’ve been thinking recently about why I think TDD is so effective. I think I write better code when I develop using TDD, but I’m also happier when I do. Writing cleaner code probably has something to do with that, but I think it also has something to do with the fabled “zone”.

Tests != TDD

Writing tests does not mean TDD. TDD is when your design is guided by the tests. By following the red, green, refactor steps the design will emerge through writing the minimal amount of code to make your tests pass.

If you write all of your code first then go back to add tests, you are not using TDD.

Benefits of TDD

In my opinion, TDD is a massively helpful tool when trying to write clean and maintainable code. I’ll probably look at the benefits of TDD and the approaches to realise those benefits in other posts.

However, recently I’ve been starting to notice that by following TDD I’ve been noticing other benefits that aren’t immediately apparent from looking at my code. I’ve been noticing that I spend more time in the elusive “zone”.

What is the zone

People often refer to the “zone” as the productive state of mind where you write your best code, everything comes easily to you, and amazing applications shoot out of your finger tips. I might have exaggerated that last bit.

While I do think done people put too much faith in the zone, I do believe it can take time to get in to a productive state of mind.

How TDD can help with the zone

I’ve always seen a bit of a running theme with a lot of developers that interruptions are terrible.

I agree that it can take me time to get back up to speed after an interruption. But I don’t think my productivity is more important than anyone elses. If somebody needs to interrupt me, I want them to feel free to do so.

This is where I find following a TDD approach can help with productivity. One of the best pieces of development advice I was ever given was “go home on a failing test”. That way, when you come back in the next day is much easier to pick up where you left off.

Using the XP principle of turn up the good, I try and always leave my work on a failing test whenever I have to leave my work. Having that failing test is much easier to focus on rather than trying to remember exactly what I was doing before.

If anyone else has any good tips on trying to stay productive I’d love to hear them.