Refactoring is just a fancy term that means improving your code without changing how it behaves.
Let's look at some reasons why you should learn about when and how to refactor effectively.
Note: This is an excerpt from my book Refactoring TypeScript: Keeping Your Code Healthy.
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's not going to be so easy to implement?
Many times, this is because our existing code is not flexible enough to handle 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?
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 to become flexible and able/easy to extend once again.
It's just like a garden. Sometimes you just need to get rid of the weeds!
I've been in a software project where adding a checkbox to a screen was not possible given the system's set up 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.
Long-term, however, these "quick-fixes" or shortcuts lead to code that can be rigid, hard to understand, more prone to contain bugs, etc.
Improving and keeping code quality high leads to:
- Fewer bugs
- Ability to add new features faster
- Able 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, etc.
E.g. It saves your company real money!
Aside: Navy SEALS Get It
There's an adage that comes from the Navy SEALs which many have noticed also applies to creating 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 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:
- Vehicles
- Power Grids
- Government Secrets
- Home Security
- Weapons
- Banking Accounts
- Etc.
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 medications without carefully ensuring that he/she knows 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 to say 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 to? 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:
Increasingly, the iconic American planemaker and its subcontractors have relied on temporary workers making as little as $9 an hour to develop and test software, often from countries lacking a deep background in aerospace.
Also, these developers were having to redo improperly written code over and over again:
The coders from HCL were typically designing to specifications set by Boeing. Still, “it was controversial because it was far less efficient than Boeing engineers just writing the code,” Rabin said. Frequently, he recalled, “it took many rounds going back and forth because the code was not done correctly.”
One former software engineer with Boeing is quoted as saying:
I was shocked that in a room full of a couple hundred mostly senior engineers we were being told that we weren’t needed.
While I have no beef with software developers from particular countries, it does concern me 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 it's all said and done, Boeing did not benefit from cutting costs, trying to rush their software development and focus 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.
Case Study #2
Do you still think that because airplanes can potentially kill people that the software built is going to be quality? Nope.
Here's another example of software quality issues in the aviation field: $300 million Airbus software bug solved by "turning it off and on again every 149 hours."
Sound's kind of like a memory leak? You know, when you have a web application that starts getting slow and clunky after keeping it opened 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.
How To Keep Your Code Healthy
This post was an excerpt from Refactoring TypeScript which is designed as an approachable and practical tool to help developers get better at building quality software.
Keep In Touch
Don't forget to connect with me on:
Navigating Your Software Development Career Newsletter
An e-mail newsletter that will help you level-up in your career as a software developer! Ever wonder:
✔ What are the general stages of a software developer?
✔ How do I know which stage I'm at? How do I get to the next stage?
✔ What is a tech leader and how do I become one?
✔ Is there someone willing to walk with me and answer my questions?
Sound interesting? Join the community!
Top comments (12)
I have a few real-world refactoring stories. The gist of each one take the following rough outline:
For a real world example, I had been using the ClassyHash gem fairly extensively as part of a project. I needed to start extending it for more specific test cases than were possible by default with classy hash. I tried for a day to make my own extension and it was like pulling teeth. Realizing I was pulling teeth was step one.
Next I had seen that there was a giant conditional statement at the heart of ClassyHash. I know big conditionals are bad practice. I had found the source of the pain.
Third, I know that polymorphism is the fix for conditionals.
Finally, I rewrote the whole gem in the course of 4 hours including tests.
So, what did this gain me? After the re-write I could write an extension with tests in 10-20 minutes, an order of magnitude development speed increase.
Nice! It's an awesome feeling when you come back to that task you were trying so hard to pull-off, and it takes a fraction of the time to do and is just really simple and straightforward now. 🥳
It’s nice to read a post on the importance of refactoring. It would be nice to read a hands-on example on and why it made a difference, with the code itself.
I previously had some comments on the original text, that is now changed, this the comments no longer relevant, so removing these.
Good luck with the book, it will be nice to see a great resource on Typescript and software craftsmanship!
I never said not refactoring was a cause. In context, this was concerning being a software craftsman. I did say:
Sure - there are many issues and causes we could look at in this specific case, which actually further my point about taking time to build quality systems (whether software or otherwise).
As far as the engine issue, I read somewhere that the decision to go with the larger engine and not change anything else was in efforts to get this thing done faster in order to match a competitor. For software developers out there, that should sound awfully familiar...
But as a segue, I think the point remains that as software developers we should seek to be craftsmen and value building quality systems.
I have no issues with developers from outsourced countries - but if they have a lack of experience in that particular industry for such a critical system and the company outsourcing (Boeing) is getting rid of its experienced senior devs in efforts to "cut costs", then that perceived trade-off of "less quality = fewer costs" is not true.
Quoting the article:
Did that cause the crash? Dunno.
However, seeking to squeeze out costs and ignore quality in these kinds of critical and/or complex software systems do matter and have long term consequences that end up affecting costs negatively when bugs and unexpected behaviour do finally occur.
One of the ways developers can make sure they are doing their part is to address code quality and take ownership of it.
One of the tools to do that is refactoring.
Hopefully, that's clearer 😊.
I see - thanks for the clarification! And good luck with the rest of the book.
I just added some more context and re-worded things in the article to make it more clear 👍
Hopefully, that's more clear. Thanks for the feedback!
Yes, it’s a lot easier to follow your train of thought. Thanks! 👌👏
Awesome 🤜🤛
I think the author trying to say is the quality of your code is important. Every developer should care about and be responsible for it. And refactoring your code to be cleaner is the key.
Great article.
If only each and every one of us takes the time to find a better(sometimes cleaner) way to code, so many of these accidents can be avoided.
Hope that day comes.
Nice and thoughtful article with great example that shows how hurriedly and badly written software impact on people lives.
Thanks James.
Thanks Branislav 👍