Extruding Code from Tests

As you may or may not know, I've been working on a game. I've also been experimenting with writing all my code in test files and extracting it.

I think I'm getting it down.

Recently, I built a lobby for my game. It's an in-memory lobby for letting people start a game on their device but it's the first step.

I started a little bit before the below video but this is where it really started getting good.

Good Advice

Fred woke without opening his eyes. He'd become a very light sleeper in recent weeks, which enabled him to avoid letting on that he was awake.

Casually, he rolled over and slid his hand under his pillow, feeling for the artifact of his other recently-developed affectation.

A brief panic flashed through Fred's mind when he couldn't find it. When the lights flicked on, his blood ran cold.

"It only works if you sleep with your hand on it," said Kramer.

Fred opened his eyes and looked in the direction of the sound.

Kramer sat in the chair across the hotel room. The lower part of his left leg was balanced casually on his right knee. In Kramer's right hand was a gun Fred didn't recognize. Kramer's left hand held Fred's "pillow pistol".

Neither weapon was pointed in any particular direction. Instead, both of Kramer's hands hung a little slack, pointing the ends of the barrels at the floor and letting them drift lazily.

"It's not a bad idea, Fred," said Kramer, "but the execution is all wrong. A gun under your pillow only works if you can go from asleep to awake and drawn in a single fluid motion."

"I'll try to remember that," said Fred.

"If I'd been here to hurt you, your little 'roll and reach' maneuver would have forced my hand."

Kramer gestured in the general direction of Fred with his left hand, being careful to keep the piece aimed at nothing in the process.

"It's a good thing I'm not," he added.

"How do you keep getting past security?" asked Fred. "Those are federal agents in the next room."

Kramer smirked. "I have to admit," he said, "it's getting harder. Those guys are going to have some nasty headaches in a few minutes."

Fred shook his head. Without thinking he reached up to rub the sleep out of his eyes, then he froze, peeking at Kramer without moving anything but his eyes.

Kramer chuckled. "It's okay. I'm not startled by sudden movements or anything."

"What do you want?" asked Fred, as he tried to rub the blur of midnight from his eyes.

"Samantha knows something," said Kramer. "I think you know it, too. I want to know it, as well."

"I bet you do," said Fred. "I don't think you're going to hurt me to get it, though."

"Oh?"

"Well, you saved me from that guy?"

"Did I?"

Kramer tapped his right index finger against the trigger guard of his pistol. After a long while, he said, "Let me give you some advice." Then there was another long pause.

"Well?" asked Fred.

Kramer pursed his lips and nodded. "Stop making assumptions," he said.

"I don't get it."

"If you don't really know but you can only really imagine one answer, it's probably not the one."

"You're saying...you didn't save me?"

"I'm not saying that."

"You're saying you did save me?"

"I'm not saying that."

"You're saying I don't really know what you're after?"

"That's right."

"Why would you tell me that, if you're not trying to help?"

"That's the question. Assuming someone is helping because they did something helpful may seem reasonable but it is an assumption."

"So what do you want?"

"I think Mike is working for someone. Someone you probably wouldn't like very much, if you found out who it was. I want to know what Samantha knows - what I think you know, too - before Mike can find out and deliver it to his handler."

"So you are on my side?"

"Maybe I'm not and I want you to think I am. Maybe I am and I just want you to think differently."

"Your friends will be waking up, soon, and I'm sure they'll have plenty of questions for you when they do." Kramer stood and began to walk toward the door.

Ask Kramer grasped the handle of the door leading to the hallway, Fred asked, "What if I don't help at all? I mean, anyone...either way."

Kramer paused with one foot out the door. For a moment, he seemed frozen...like a robot whose processors were all simultaneously in deadlock. He looked down and smiled. Then gently placed Fred's Glock on the TV stand, just within his reach.

"Then get used to keeping your hand on the gun under your pillow every night for the rest of your life," he said.

Just before the door closed, obscuring Kramer from view, he added "However long that may be..."

Labors of the Fastidious Coder

I spend a lot of energy on the coding equivalent of the mantra "cleanliness is next to godliness".

People sometimes think this is extra work but it's not. In fact, it's anything but that.

Fastidious coding is frontloaded work. That is, I'm taking the thing that I know is hardest - keeping my design natural to my problem - and doing that work as soon as I can.

When you do that, code-cleanliness work doesn't start to stack up into a seemingly insurmountable pile.

That psychological effect, alone, is worth the "effort" but there's a subtler, more potent source of value.

Badness compounds on badness. When you let code be bad, you do bad things to get it to work. That makes the code worse.

So, allowing a quality problem to fester not only accumulates redesign work into large chunks but also accumulates work you would never have had to do if you just kept things clean.

Following is a video wherein I spend about an hour cleaning up a test library, among other things. You can think of it as a waste of time or an expression of my perfectionism if you want to, but I would like to offer a different perspective.

What if you watch the video and try to think about all the things that could go wrong if I didn't do that cleanup, this morning?

A Friend Asked Why I Don't Have Comments

The answer is simple.

I don't like the way the blog looks with comments enabled. I think it looks ugly with this style.

If people are interested in discussion, I'm sure I can find a solution that isn't visually-jarring.

Intensive Coaching

I'm going through an intensive coaching experience. The idea is that I spend a full ten weeks with a single team.

I'm a little surprised with the outcome. I knew there would be an impact but the team is progressing a lot faster than I, for one, anticipated.

I don't have enough data to attribute that to the intensive experience, yet. It's also a really engaged and interested team and I suspect that has a lot to do with the progress being made.

I think people have a tendency to be a little superstitious in assigning reasons for success or failure. I don't want to contribute to that but, it's easy to see why someone who went through an experience like this one might be convinced it's the only way to coach software developers.

American Idle

We work a lot, here. We work a lot more than we probably should.

That's not really a problem. Not long ago, where I'm sitting was the frontier. Hard work was necessary to survive and to thrive.

Yet, even in frontier times, people rested. They worked hard and then they rested. Then they worked more.

I think we lost that somewhere along the way. People feel like they need to spend every second working.

The mentality is this:

If you're not busy, you're wasting your time. So get busy.

There are many problems with this.

First, you're way more effective for the period of time shortly after you've rested than you are when you've been working for a long time; at least, that's true for most people. So you lose productivity by trying to stay at full utilization. It's a self-defeating proposition from the get-go.

Next, there's the fact that the impulse to work hard continuously suggests there's something fundamentally wrong with your approach. There's a practically-limitless amount of work to be done. Work needs to be managed and sliced into bite-sized pieces with adequate funding. If heroics are required, then the work isn't really being managed. Mismanaged work is nearly-guaranteed to fail.

Finally, there's the fact that work is probably not the best part of your life. I mean, every workplace wants to be a second home, or whatever, but the reality is that most of us have something else that matters more. We have families. We have hobbies. We have charities. Those are typically the reasons why we work in the first place. Working to the detriment of our higher goals is, again, self-defeating.

So if you want to work hard, great. If you want to cannibalize your life to try to get a little more done, spare a few minutes asking yourself way.

The break will probably help you get more done anyway.

Dependencies, Not Levels

The way we teach people to be software developers doesn't make a lot of sense.

It's one of those things that sounds reasonable so long as it is described in vague-enough terms. The idea is that you build up someone's skills slowly, incrementally.

For instance, some people believe that you should start by teaching scripting. Then promote students to procedural coding. The traditional version of object-oriented design follows. Finally, assuming the person you are talking to has enough understanding of software development, you start teaching design patterns.

The same is true of test-driven development. Start with test never. Then move on to test-after. Upgrade to test-first. Promote to TDD and then, ultimately, to organization-level BDD.

Refactoring gets a similar treatment if it gets any treatment at all.

What's really being proposed is ordering alternative ideas by how difficult they are to completely master.

This doesn't make any sense because it sets up a pattern of wasted effort. You start by teaching someone something the wrong way. Then, after they've attained a modicum of mastery in that way, you tell them it's bullshit and they should do something else.

How do we expect people to react?

I'm experimenting with a different pattern: Start with a skill that doesn't have any dependencies and don't worry about mastery. Just help people get enough to start using it, which really isn't that much. As skill in that area improves, it also enables someone to start learning a skill that depends on it.

In software development, given developers who already have basic coding skills, refactoring is the skill with no dependencies. Refactoring enables design because it's way easier to imagine a new design if you have a chance of getting there safely. Design, in turn, enables TDD because it's easier to imagine using tests to drive your development process when you know you can create and refactor to designs that will enable the effort.

It seems like it's working really well.