Why Refactor at All?

Slow Development

Ever work in a software system where your business asked you to build a new feature but once you started digging into the existing code, you discovered that it wasn't going to be so easy to implement?

Often, this is because our existing code is not flexible enough to handle the new behaviors the business wants to include in your application.

Why?

Well, sometimes, we take shortcuts and hack stuff in.

Perhaps we don't have the knowledge and skills to know how to write healthy code (this book will help!).

Other times, timelines need to be met at the cost of introducing these shortcuts.

This is why refactoring is so important:

Refactoring can help your currently restrictive code become flexible and easy to extend once again.

Code is like a living organism (https://meltingasphalt.com/a-codebase-is-an-organism/) – like a garden. Sometimes, you just need to get rid of the weeds!

Note

I've been involved in a software project where adding a checkbox to a screen was not possible given the system's setup at the time! Adding a button to a screen took days to figure out! And this was as a senior developer with a good number of years under my belt. Sadly, some systems are just very convoluted and hacked together.

This is what happens when we don't keep our code healthy!

Saving Money

It's a practical reality that you need to meet deadlines and get a functioning product out to customers. This could mean having to take shortcuts from time to time, depending on the context. Bringing value to your customers is what makes money for your company, after all.

In the long term, however, these quick-fixes or shortcuts lead to code that can be rigid, hard to understand, more prone to contain bugs, and so on.

Improving and keeping code quality high leads to the following:

• Fewer bugs
• The ability to add new features faster
• The ability to keep changes to existing code isolated
• Code that's easier to reason about

All of these benefits lead to less time spent on debugging, fixing problems, developers trying to understand how the code works, and so on.

It saves your company real money!

Navy SEALS Get It

There's an adage that comes from the Navy SEALs that many have noticed also applies to the creation of software:

Slow is smooth. Smooth is fast.

Taking time to build quality code upfront will help your company move faster in the long term. But even then, we don't anticipate all future changes that need to be made to the code and still need to refactor from time to time.

Being a Craftsman

Software development is a critical part of our society.

Developers build code that controls the following:

• Vehicles
• Power grids
• Government secrets
• Home security
• Weapons
• Bank accounts
• And more!

I'm sure you can think of more cases where the software a developer creates is tied to the security and well-being of an individual or group of people.

Would you expect your doctor to haphazardly prescribe you medication without them carefully ensuring that they know what your medical condition is?

Wouldn't you want to have a vehicle mechanic who takes the time to ensure your vehicle's tires won't fall off while you are driving?

Being a craftsman is just another way of saying that we should be professional and care about our craft.

We should value quality software that will work as intended!

I've had it happen before that my car's axel was replaced and, while I was driving away, the new axel fell right out of my car! Is that the kind of mechanic I can trust my business with? Nope!

Likewise, the quality of software that we build can directly impact people's lives in real ways.

Case Study #1

You might be familiar with an incident from 2018 where a Boeing 737 crashed and killed all people on board.  It was found that Boeing had outsourced its software development to developers who were not experienced in this particular industry.  Also, these developers were having to redo improperly written code over and over again.

It is clear from this example how it can be inefficient and even dangerous when a group of developers are lacking the knowledge or tools to build quality software in such critical systems.

For Boeing in general, what did this overall lack of quality and craftsmanship lead to?

The company's stocks took a huge dip a couple of days after the crash.

Oh, and don't forget – people died. No one can undo or fix this.

After this was all said and done, Boeing did not benefit from cutting costs, trying to rush their software development, and focusing on speed rather than quality.

As software development professionals, we should seek to do our part and value being software craftsmen and craftswomen who focus on creating quality software.

Note

You can find the full article here: https://www.bloomberg.com/news/articles/2019-06-28/boeing-s-737-max-software-outsourced-to-9-an-hour-engineers.

Case Study #2

Do you still think that because airplanes can potentially kill people that the software that's built is going to be quality? Nope.

Here's another example of software quality issues in the aviation field: a $300 million Airbus software bug solved by turning it off and on again every 149 hours (https://gizmodo.com/turn-it-off-and-on-again-every-149-hours-is-a-concernin-1836818094).

Sounds kind of like a memory leak, right? You know, when you have a web application that starts getting slow and clunky after keeping it open for a while? Just refresh the page and voila! Everything's fine again!

Sadly, we are building airplanes like that too.

Quoting the article:

"Airlines who haven't performed a recent software update on certain models of the Airbus A350 are being told they must completely power cycle the aircraft every 149 hours or risk "...partial or total loss of some avionics systems or functions," according to the EASA."

Do you want to fly on those planes?

Quality matters. And the fact is, many developers are not writing quality software.

I hope that this book will help developers get just a little bit better at building quality software.