White space can be very helpful but in the wrong places it can be sign that a bit of refactoring might be helpful.

Why blank lines in code are a problem

Adding in a blank line often feels like a natural thing to do while programming. Just like adding a full stop at the end of a sentence, a blank line can finish a thought.

However, if a function has these blank lines breaking up the code, that can be a sign that there is more than one thought in a function. If there are clumps of lines together it is usually a sign that methods or classes could be extracted.

In this example, blank lines have been used to separate the logic for the calculating the subtotal and the discounts.

function CalculateTotal(products, priceList) {
    let subTotal = 0
    products.forEach(product => {
        subTotal += priceList.getPrice(product)
    });

    let discounts = 0;
    if(products.filter(product => product.inDiscount).length == 2) {
        discounts = 20
    }
    if(products.filter(product => product.inDiscount).length > 4) {
        discounts = 40
    }

    const total = subTotal - discounts
    return total
}

Uncle Bob has a great analogy for why people like to break code up with things such as blank lines. He likens finding your way around a code base like that to recognising features in a landscape. When someone knows an area they might use landmarks such as mountains on the horizon to know where they are. The shape of the code can act in the same way. However if you don’t know the area those landmarks offer little help, just like blank lines offer little help in an unfamiliar code base. Well extracted and named functions or classes are a much nicer way to navigate without that tacit knowledge.

How to deal with blank lines

As I’ve mentioned, a straightforward refactoring you can do if you have logical groups of lines broken up by blank lines is to extract those groups in to methods.

The example has been refactored by extracting out the logic to new functions.

function calculateTotal(products, priceList) {
    const subTotal = calculateSubTotal(products, priceList)
    const discounts = calculateDiscount(products)
    const total = subTotal - discounts
    return total
}

function calculateSubTotal(products, priceList) {
    let subTotal = 0
    products.forEach(product => {
        subTotal += priceList.getPrice(product)
    });
    return subTotal
}

function calculateDiscount(products) {
    let discounts = 0;
    if(products.filter(product => product.inDiscount).length == 2) {
        discounts = 20
    }
    if(products.filter(product => product.inDiscount).length > 4) {
        discounts = 40
    }
    return discounts
}

Further refactoring should be done on this example, but by extracting the logic clumps to their own functions, rather than using blank lines, the intent is much clearer.

If you have several groups of lines and they are sharing data, it might make sense to extract a class during your refactoring.

I have seen some push back against this advice. I’ve heard comments like, “these functions are too small now” or “that’s too many files in the project”. But for me, many small, well named things are much easier to navigate my way around though.

I loved Martin Fowler’s example of a small function though. In his book, Refactoring, he tells of the example from Smalltalk of a single line function called Highlight which only calls the function Reverse. While this is a single line function, it still made the code easier to understand.

So like all code smells, I wouldn’t say blank lines in themselves are a problem, but they might be a sign that a useful refactoring may be a good choice.

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!