Legacy Code Rocks! - Issue 7  September 28th 2016

Characterization Testing by Michael Feathers

Writing tests to describe and fix existing code

Excerpt: "Most types of testing have the quality of being about correctness. We test our code to see that it is doing what we want it to do. This assumes that we know what it is supposed to do - that we have some sort of specification in our heads or elsewhere that tells us what we’re aiming for.

What if we don’t?"

Why On Earth Is Google Building A New Operating System From Scratch? by Jared Newman

Could this be nothing more than an experiment?

Excerpt: "Last week, a group of Googlers did something strange: They quietly revealed a new operating system that theoretically competes with Google's own Android OS.

Dubbed Fuchsia, the open-source OS-in-progress could run on everything from lightweight, single-purpose devices (think ATMs and GPS units) all the way up to desktop computers. But unlike Android, Fuchsia isn't based on Linux, nor is it derived from any of the other software that underpins nearly all personal computing and communications today. Instead, it's an attempt to start from scratch."

What Will Your Legacy [Code] Be? by Colin Jones

With Legacy Code, you're invited to build a sort of team camaraderie across time and space.

Excerpt: "The words "legacy code" strike fear into the hearts of developers everywhere.

Behind that fear, legacy code means it's slow to understand existing behavior, slow to fix bugs, slow to develop features, and slow to gather confidence that I haven't broken some seemingly unrelated thing.

And I hate slow. Slow means risky. Slow means expensive. Slow means trust-eroding."

Hacking Doom Code for Transparent POV Display by Guillaume Chéreau

Sometimes, your favorite game needs just a bit of tweaking...

Excerpt: "Doom (the original version), is not only one of the best game ever made, but it's also a great example of C code.

Thanks to id Software decision to release the code as open source in 1999, anybody can have a look and modify it.

I had this project of changing the rendering of doom, to add a border effect to the walls, or cel shading. You can check the video at the end of this post to see why I wanted to do this to start with."

Embracing the Red Bar: Safely Refactoring Tests by M. Scott Ford

Have you ever heard of "Refactoring Against the Red Bar"?

Excerpt: "Do you ever refactor your test code? If not, I hope you consider making this part of your normal practice. Test code is still code and should adhere to the same high standards as the code that’s running directly in production.

As important as it is, refactoring your test code is actually a little risky. It’s very likely that you could turn a perfectly valid test into one that always passes, regardless of whether or not the code that it covers is correct. Let’s explore a technique for protecting against that possibility."

The Different CTO Roles by Werner Vogels

An older, yet insightful piece on the various roles of the CTO.

Excerpt: "The first thing that always comes up when you want to discuss the role of a CTO is that there is no well-established definition of what a CTO actually does. The role is very different depending on the type of company and the role technology plays in the company."