Teaching an Old Dog New Tricks

I had a really amazing experience this week. I had an opportunity to pair with a gentleman who has been programming since I was in diapers. He had only ever test driven code once before, but is really excited about learning. I think that in and of itself is amazing, but I learned a few things during the experience as well.

Being it was his second time test driving, I navigated while he drove. He’s seen our team pair, and asked if we were going to ping pong (one of us would write a failing test, then the other make it pass), but I wanted him to build as much muscle memory as possible. A smile lit up his face and I can’t tell you how happy it made it me.

Our task was to parse a version number and increment the patch number on it. He immediately created a new file for the test, but I stopped him.

“Hey, wait a sec. Why don’t we take a few minutes to write a test list first?”

“What do you mean?”

“Well, I like to take a minute to think about the inputs, outputs, and edge cases, then write down any tests we think we should write. The test list is our roadmap. It keeps us on task. I don’t like Test Drive Design. I like to do just enough design first, then test drive the development.”

“Okay man. I can dig that. That’s smart. I never understood how TDD makes better code when you weren’t taking the time to design anything. So, what you’re saying is that TDD doesn’t mean “don’t design at all”, but “design just in time”, right?”

“Yeah. I guess I am. Something like that anyway.”

I’ve said before (perhaps not on this blog, but before and relatively often) that TDD doesn’t excuse us from good design. What I hadn’t realized is the “just in time” part. Just like everything else in my development cycle, I’m doing just enough, just in time to be most effective, yet still as lightweight as possible. It’s interesting and I’m surprised it never dawned upon me before.

Anyway, we create a test list and finally he gets to create that test class he was so eager to create. Even though he’d barely done this before, he instinctually created the test class first. I know I had to have been smiling as I watched him. “This guy’s a natural”, I thought to myself. He copied just enough code from a neighboring test class to get the test runner to pick it up and then I had him delete any extra remnants of the other test. We paused for a moment and I asked him to pick out what he thought would be the simplest test to write. He picked one and began writing the test, beginning with creating an instance of our not yet existent class.

“Whoah! Hold up! You’ve got a failing test.”

“What do you mean? There is no test yet!”

“Yes there is, and it’s failing. That code won’t compile. A test that won’t compile is a failing test.”

He smiled. “Okay man. I’m picking up what you’re laying down. Write just enough to make it fail, right?”


There it is again. Do just enough, just in time….

So, he created the new class, ran the no-op test, and went back to writing the test. Soon, we also had a no-op function and a failing test that actually tested something meaningful.

“Okay. Now let’s make this pass.”

“Sure. Now let’s see. We’re going to need to split this string and..”

“Whoah! Slow down a little. Is that really the simplest way to make this test pass?”

“What do you mean?”

“Well, why not just hard code the return value?”

He looked at me like I was totally nuts. Maybe I am….

“Huh? I don’t get it.”

“If we hard code the return value, the test will pass. Then, we’ll go back and add a new test that forces us to change the code. If we start splitting strings right now, we might accidentally write code that isn’t tested.”

“Hmm…. I don’t know man, but you’re the expert. All right, let’s just hard code it for now.”

He reminded me of just how counter intuitive TDD can be when you’re new at it. Heck, it can be counter intuitive when you’re experienced at it. I’ve been doing this for years and I still feel weird hard coding that return value, but I’ve also burnt myself by writing more code than absolutely necessary to make a test pass. This is a nice reminder of just how much discipline it takes to test drive.

We test drove this little function for about an hour, writing just enough code to make it fail, then just enough to make it pass. At the end of that hour, we had about a dozen tests and I could see the concern growing on his face. I had a feeling that I knew what was coming.

“Man. These tests are great, but the implementation code sucks. It’s downright awful. Are you sure about this TDD stuff?”

“Yeah. That code does suck, doesn’t it. Let’s fix that. So far we’ve been skipping the refactor step. I wanted you to get the feel for the red/green cycle. I probably should have stopped us sooner, but you were having fun and building muscle memory.”

We spent 15 or 20 minutes refactoring the code until we had something not quite as nasty as before.

“Dude. That was awesome! We just completely tore the guts out that code and it still works! More importantly, I know it still works, because the tests are green. Not bad man, not bad at all. I can see why you young guns like this so much.”

This is something that strikes me often about test driven code. Test driven implementations tends to be ugly as sin. I mean, downright bad, rotten, spaghetti code implementations, but we have the tests. We can refactor. Hell, I’ve deleted entire implementations and started over, knowing that when I was done, I’d have working code again, because I have the tests. The ugly implementation is only a problem if we skip the refactor step. Don’t skip it. Even if there’s nothing to refactor, be sure to take a moment to double check that there’s nothing to refactor yet. It’s really important to build that habit. Next time I teach someone TDD, I’ll be sure to make it an explicit part of our cycle from the very beginning.

We continued on like this for the rest of the afternoon. By the end of the day, we had a really bullet proof implementation ready to merge in.

“So, Chris… This is really great and all. I mean, I had fun man, but it took us all afternoon to write that one function. Is this really worth it?”

“Well, you’re right. It took a long time to write that, but let me ask you something. All those edge cases we found… If we had whipped up the 30 minute version of this function, without test driving, would we have thought of them?”

“No. No way.”

“When would we have thought of them?”

“Months from now when someone reported a bug.”

“Right. Months from now, when…”

“When we’ve forgotten all about this code and not only will it be more expensive to fix, but it’s also caused real damage out in production.”

“Exactly.” I said with a smile on my face.

An old dog learned a new trick this week, and this pup learned some valuable lessons as well. I’m looking forward to pairing with him again. I’ve a feeling we’ve got a lot to teach each other.



, , , , , ,

Leave a comment

The Bottleneck

The monk Ahiru was pairing with the bright young apprentice, Taipisuto. The apprentice was quite impressed with his customized editor and the speed at which he could type. Ahiru was not nearly as impressed. The screen was flickering in a way that made him more than just a bit nauseous.

“And what shall you do when you’re assigned to a clan and they use a different editor? How will you pair with them?”, asked Ahiru of the apprentice.

“I shall teach them the vastly superior ways of Emacs”, replied the apprentice matter of factly. “It allows us to type very quickly with almost no effort at all! How can anyone deny this?!”

Ahiru quashed his desire to strike the young man. He appreciated his confidence, but the young apprentice had a lesson to be learned. That night, Ahiru committed the worst of sins. He rebased the clan’s master branch, eradicating the work the apprentice and he had done that day and making it impossible to easily restore it from the apprentice’s local fork.

When the monk arrived the next morning, the apprentice was visibly distraught, his fingers flying over the keyboard in pure desperation.

“What’s wrong?” asked Ahiru, knowing full well what he had done.

“Our commits!”, cried the apprentice. “They’re gone! Someone committed the sin of all sins and rebased the master branch! We’ve lost an entire day’s work! Who can have done this?”, he moaned.

Null.“, said Ahiru. “We’ve simply lost the code. The work has not been lost.”

The apprentice just stared at the monk, not understanding the words he had just heard.

“90% of what we do is think about how to solve a problem, Taipisuto. The temple does not pay us to write code, they pay us to solve problems, and solve the problem we did.” Ahiru slid down into his seat next to the young man. “Now, let us re-implement the code. How long do you think it will take us?”

“It took us all day yesterday to write it…”, the apprentice bemoaned again. This time, Ahiru did not restrain himself and came down swiftly on the top of Taipisuto’s head with his staff.

“Type.”, said Ahiru.

Half an hour later, as the pair were checking the newly re-implemented code into the clan’s master branch, the apprentice was enlightened.

I’m a big fan of The Codeless Code and since they’ve not posted anything new in a while, I thought that I’d try my hand at their style of “programmer’s koan”. Following their lead, the story above is provided under the Creative Commons Attribution-NonCommercial 3.0 Unported License.

Leave a comment

Doing what’s best, even when it sucks

About 8 months ago, I promised you that I’d follow up and let you know how our transition to Agile software development was going. This is that long overdue follow up and I’m sad to say that six weeks ago I submitted my resignation. Tomorrow I start with my new company.

I’m sitting in an airport right now reading Brad Warner’s “Hardcore Zen” for the dozenth time and I think I’m finally ready to talk about all this. I’ve been trying to figure out what to say for over a month. I know I need to write about this, but I’ve not had the words until now. It turns out, that it’s fairly simple.

I failed.

I failed. I failed. I failed. I learned, my team learned, we found an incredible amount of success, then we failed. Then I failed in the worst possible way: I gave up.

Read the rest of this entry »


In Depth on my first NodeJs / Express Stack

The whole goal of my hobby site is to iteratively create the simplest website that could possibly work using all “new to me” stacks. Getting a static site up and running on my own Linux CentOS with Lighttpd was definitely simple. Getting a NodeJs web service up and running with Express was equally simple, but making it production quality was definitely a frustrating experience for me.

My initial experience with NodeJs was exhilarating. I had a web server & app running with just a few lines of code, but then I quickly soured on the whole platform when I found TDD & mocking to be more difficult than I feel it should be. I’m happy to say that through a bit of research and effort, I now have a stack that I’m relatively happy with.  I want to capture the struggles and solutions while they’re still fresh in my mind.

Read the rest of this entry »

, , , , , , , ,

Leave a comment

Initial Thoughts on Node.js

I’ve been building a hobby site so I can learn about non-Microsoft stacks and I spent the weekend learning Node.js. At first I was completely amazed at how awesome it was. It took about 5 minutes to spin up a webserver and start returning HTML from an endpoint! It was easy and fun! That 5 minutes of fun ended as soon as I thought “okay, now let’s write some production quality code”.

I’m not sure if it’s a problem with JavaScript or with Express, but dependency injection is far more complicated than it should be. I like to test drive my code and that means mocking out datasources so we don’t need to hit a filesystem, database, or network. That proved to be extremely difficult with Express’ `require` system. Requiring an external module basically hardwires you into that dependency, which is a no starter when you need to fake that dependency. I wasn’t able to get a constructor for the route working properly, so I ended up settling for keeping my requires in my `server.js` file and using property injection. Ugly, but it worked.

This ugly solution was bothering me, so I dug my heels in and went searching for a more idiomatic way to accomplish DI. What I found was Proxyquire. Proxyquire isn’t really DI. It works much in the same way you’d break a C `imports` dependency by creating a fake and telling the linker to use your fake instead. Only, of course, Proxyquire does this at run time instead. The documentation is good, but not great and it took about about an hour to get it working properly. It was a rather frustrating experience.

So, with a way to fake dependencies in hand, I get to writing an actual assert statement. That’s when I hit the next wall. Express’ way of sending responses doesn’t actually return anything. It all works via side effects. So now I could go install Sinon and learn a 4th library or I could just not write the tests because I’m not having fun anymore. Wasn’t that why I fell in love for that brief moment? Didn’t I love Node a few hours ago because it was easy and fun?

That doesn’t mean that I don’t have a use for Node.js though. I would absolutely use it to quickly prototype an idea. It’s completely fantastic for getting something simple up and running quickly. However, I would then just as quickly throw that prototype in the trash and write my production code in something else. A platform being quick, fun, and easy doesn’t matter if it’s hard to do things the right way. If it’s easier to write tightly coupled and untested code, we will. I don’t know about you, but I like knowing my code works and will continue to work.

Before I tried Node.js, all I could think was why would anyone want to use JavaScript for their backend. After a few days of learning it, I’ve found a use case, but am still left with a sour taste in my mouth. Maybe I’d be less disappointed if I hadn’t had a moment early on where I fell in love with it. Granted, there’s no way I learned the idiomatic way to write a Node web app in a few days, but I just can’t see myself ever using this for a production application. If you know of any good alternatives to Express that make testing Node code easy, please let me know in the comments. I hate to write off such a fantastic platform prematurely.



Complete Guide to Setting Up a Secure Website on a VPS with Lighttpd

Last time I talked about setting up a simple web server and site from my phone. Since then, I’ve been spending a little bit of time getting things set up right. That’s been a bit more challenging than simply getting the thing up and running, so I figured I’d take a moment to jot down some notes in case I ever need to do this from scratch again.

Read the rest of this entry »

, , , , , ,

1 Comment

Building a Website ON an iPhone

There’s a lot of information out there about building websites for mobile, but have you ever considered that it’s completely possible to set up a website from a mobile device? I did just that today. 

A few days ago, I received an email notifying me that an old domain of mine was set to expire. I haven’t had it hosted in years, but didn’t want to let go of the domain. I was tossing around the idea of setting up an old desktop as a server, but I’d like to eventually migrate this blog to the domain and an old desktop on a commercial ISP probably wouldn’t handle the traffic very well. A friend of mine recommend a VPS (virtual private server) instead. It sounded like a great way to get to know some different stacks and I planned to set things up a few weekends from now. 

Over coffee this morning, I logged in to renew my domain and pick out a hosting company on my phone. Before I finished my first cup I had not only accomplished that, but already had an SSH session to my shiny new instance up and running in my mobile’s chrome browser. It was a bit awkward, so I did a quick search on the App Store and found the Reflection SSH client app. Much better. This app was nearly as good sitting at my desk typing in a Putty terminal. Within a few minutes, I had a new user setup. 

I went for a second cup of coffee and thought, “How far can I push this? Can I set up a webserver from my phone?” A quick search led me to this great tutorial about setting up a webserver on Linux. I followed along through some basic server  setup and everything went smoothly right up until I tried to actually install the Lighttpd (“lighty”) webserver. Lighttpd isn’t listed in the CentOS repositories, so I needed to manually download it from a mirror. Typing in that URL was not fun, but all in all, not hard. It was just awkward typing it on this tiny touch screen. It’s odd, I can easily type entire blogs on it, but a URL is beastly to type out on an iPhone. 

A few more google searches and I had the firewall set up correctly and could access the Lighttpd sample site from my phone’s browser. 

Back over to my domain name provider to point my domain to the VPS and my domain name was now routing to my website. 

In about 2 hours, I had a webserver running using nothing but my iPhone. That’s pretty damned cool if you ask me. When I was my daughter’s age, it would have taken that long just to download and install the SSH client!

I just couldn’t resist pushing this absurdity to the extreme at this point. I went back to the App Store and found an SFTP app and an HTML editor. 30 minutes later I had the simplest website that could possibly work. 

It’s not pretty, or fancy, but it’s online and I never touched my laptop. I certainly wouldn’t recommend doing this from your phone if you need to be productive and I won’t be maintaining the site this way, but I find it terribly fascinating that it’s possible. 

, , ,

1 Comment

Do you want to be a VBA Developer, or do you want to be a Software Developer?

I’ve seen a number blog posts by very good VBA devs worrying about the future of the platform and their careers. They’re right to be concerned, but not because they’re VBA devs. A Java developer should be concerned. A C developer should be concerned. And yes, a C# developer should be concerned too. 

You see, these folks are worried that their platform/language of choice is going to become obsolete. If it’s the only one you know, that makes you obsolete too. If you’re an X developer, then any given day could be your last. As new technologies become prevelant, old ones become more and more niche. The jobs fade away with the old stacks. If you want to protect yourself and your family, then you need to have more than one hammer in your toolbox. I think you have to ask yourself, do you really want to be a VBA developer or do you want to have the security of being a Software Developer?

It’s often said that bad developers can write bad code in any language, but the opposite is true too. Good developers can write good code in any language.

I’ve had a few folks ask me how I made the jump from being a VBA dev to being a C# dev.  The truth is, I wasn’t ever a VBA dev. My first (and second) language was BASIC. Then I learned some Java. At this point, it was only a hobby. I had no dreams or aspirations of doing this professionally. I was a Planogram Analyst. My job was to create schematics to show people where to put the right amount of the right product on the shelf. It was a tedious job, so I started using VBA and JDA Space Automation (a proprietary scripting language) to automate my work. I bet many of you VBA developers out there started the same way. 

Being a nice guy, I shared these tools with my coworkers. Eventually, I was asked to do it full time. That’s when I had to learn some SQL. Soon after, I started using SSIS for all the ETL jobs we needed. So you see, I was never really a VBA dev. I was a software developer. I learned and used whatever tool I needed in order to get the job done. 

Still, if you looked at my resume At the time, you would have labeled me a VBA dev. Perhaps, a person could be justified in doing so. Hell, 6 months ago, you could have easily labeled me a C# dev, but I’m not. I’m more than that and I bet you are too.  It’s often said that bad developers can write bad code in any language, but the opposite is true too. Good developers can write good code in any language.

That doesn’t matter much to recruiters and hiring managers though, does it? So how did I make the jump away from VBA professionally?

First, I accepted that being labeled a VBA dev was putting my future at risk. Then I picked a language that was in demand and started learning it. I’d write solutions to Project Euler problems and post them on Code Review Stack Exchange. There, I could get feedback from professionals who really knew the language. That feedback is absolutely critical to really learn something. Without it, you don’t even know that you’re making mistakes. 

Next, I started getting serious about OOP, SOLID, clean code, and unit testing. I’d spend my time reading books like Clean Code and Code Complete. I started to ruthlessly apply good engineering practices to my VBA code at work. Only, VBA didn’t quite have the toolset I needed to really test drive my code. So, I started building them, in VBA at first, but soon after the Rubberduck project was born. Finally, I ended up breezing my way through an paid and verified EdX course for some “formal proof” that I knew the language I’d be using at the places I was applying to. 

Now I had all the ammo I needed to make the jump, but it still wasn’t easy. I had to treat finding a job like it was a job, because it was. During the time I was looking for work, I was spending at least 20 hours a week writing cover letters and performing phone screens, on top of my 50 hour a week job. I nearly burnt out before I finally found a great place to work, but I did find one and made the jump. Since then, I’ve started to learn C, C++, and embedded development. 

So, for those of you who’ve asked me how I made the jump from VBA to C#, I’m still not sure that I’m the right person to ask, but here’s my TL;DR:

  1. Learn how to write Object Oriented VBA. 
  2. Stop thinking of yourself as a VBA dev. 
  3. Learn an in demand language. 
  4. Learn how write good unit tests. 
  5. Start contributing to an Open Source project written in your new language.
  6. Get a certification, even if it feels silly. 
  7. Make it your job to find a new one. 
  8. Never stop learning. 

, , ,


Retrospective: How We Could Have Failed Faster

For the last several months, I’ve been working on a project that involves reading data from a device via Bluetooth and then sending that data to another machine via RS232 serial port. At least, that’s my piece of the puzzle. It’s proved to be a challenging, but not insurmountable, task for  someone who is traditionally a CRUD programmer.

Yesterday, we discovered that we built the wrong software. I built what I was asked to build, but it isn’t what the client needs. The sensor device that was chosen doesn’t provide appropriate data for the use case. I spent the day salvaging whatever code I could for reuse in the end product, but the application itself (and several months of development) will be thrown away. This has prompted me to have a personal retrospective on this project to see if there were things we could have done to fail faster.

Read the rest of this entry »

, , , , , ,

Leave a comment

ObservableCollection is a Leaky Abstraction

And so is BindingList. Or, rather, exposing them through your controller’s interface is a Leaky Abstraction.

Anyone who’s done any Windows desktop development has eventually come across ObservableCollection and BindingList. How often have you written a controller (ViewModel or Presenter, doesn’t matter what you call it, they’re all some variant of the Controller in MVC) that looks like this.

    public class LeakyWpfController : INotifyPropertyChanged
        public ObservableCollection<Person> People { get; } = new ObservableCollection<Person>();

        public event PropertyChangedEventHandler PropertyChanged;

Or this

    public class LeakyWinformsController
        public BindingList<Person> People { get; } = new BindingList<Person>();

What’s wrong with this code?! We need to expose a collection type that the framework understands for the databinding to work!

No. We don’t. Both Winforms and WPF don’t care what you expose. They only care that the backing field is of the proper type. All you need to expose in your public interface is an ICollection, in both cases. Databinding to these two controllers works perfectly well.

    public class WpfController : INotifyPropertyChanged
        public ICollection<Person> People { get; } = new ObservableCollection<Person>();

        public event PropertyChangedEventHandler PropertyChanged;

    public class WinformsController
        public ICollection<Person> People { get; } = new BindingList<Person>();

Ok, so big deal. It’s not like I’m ever going to use my ViewModel or Presenter for anything but the specific View they were built for…

Are you so absolutely sure of this? If you’re certain that you’ll never want to use the same presentation logic in more than one window or application, then sure. You’re probably right. Leaking this abstraction doesn’t hurt, but what if we wanted to reuse logic from our old Winforms application in our new WPF app? Or what if we wanted to set ourselves up to migrate away from that old Winforms app into a new WPF application? What do we do when WPF and ObservableCollection aren’t the newest, greatest thing anymore and we’d like to migrate to that newest framework? Wouldn’t it be nice to be able to do so with minimal effort?

Our two controllers are at this point so similar, we can combine them into one. (Thanks to the fact that WPF supports BindingList as a backing field.)

    public class Controller : INotifyPropertyChanged, IController
        public ICollection<Person> People { get; } = new BindingList<Person>();
        public ICommand AddItemCommand = new AddItemCommand(this);

        public event PropertyChangedEventHandler PropertyChanged;

I only recommend using BindingList as a backing field if your Controller (view model/presenter) needs to work in a Winforms environment though. There are some performance issues with BindingList. If you only need to target WPF or UWP, then ObservableCollection is the right way to go. Either way, there’s no reason to expose anything more than an ICollection to the outside world.

, , , , , , ,

Leave a comment