Christopher Bennage : Opinion

Blocks and Playsets

Christopher Bennage — Mon, 17 Oct 2011 17:52:00 GMT

I’ve recently discovered that I favor blocks over playsets. I’m talking about toys, and of course the canonical example of blocks is Legos. You can build nearly anything with them. They are useful, versatile, and inviting.

Now, the term ‘playset’ warrants a bit more explanation. I don’t mean the large outdoor sets with swings and sandboxes and spring-loaded ponies. No, I’m a child of the 80s and I loved me some Star Wars playsets.

So my definition of ‘playset’ is colored by my childhood. I think think of ‘playset’ as a themed toy representing an environment. Like the Hoth playset pictured here. If you want to pretend you are the Imperials raining destruction upon a ragtag Rebel Alliance, the Hoth Imperial Attack playset can’t be beat.

The problem is that’s all you can do with it. I mean, you can’t use the Hoth playset to stage an epic Cybertronian showdown between Optimus and Megatron. (Well you can, but you’ll have admit it’s just a bit awkward.)

Let’s get back to the blocks. Those puppies can be used to reconstruct a carbonite freezing chamber as well as hosting a dramatic cliff-side battle between Snake Eyes and Storm Shadow. Better yet, you can construct worlds of your own invention instead of merely mirroring those of others.

In reality, it’s not so cut and dry. (Nothing is, is it?) No, in reality, there’s a spectrum. In reality, there is Lego® Star Wars®. The line between blocks and playsets is blurred.

Software

I believe these categories apply to software as well, though we call them libraries and frameworks. Rob Conery asked a question about this on Google+ recently. Derick Bailey provides a definition attributed to Chris Eppstein:

“Frameworks call your code, you call library code.”

I began thinking about this from a different angle. I think that frameworks impose an opinion. Ruby on Rails has a strong opinion about how to create web apps. I think that make it a framework. Or at least, closer to the framework end of the spectrum than to the library end.

Now, to be clear, I am not saying that opinionated software or that frameworks are bad. In fact, they can be brilliant. I think Rail’s strong opinion has been a significant contribution to its success. What’s important to understand though is the limitations. When you are using a framework, the boundaries are harder to cross. The results can be strained and unnatural. The problem for me begins when our fanboy favor for a framework leads us to force its use it where it doesn’t fit.

Fun

Playing with both blocks and playsets is fun. So let’s stretch the analogy even further. What does that mean to software development? My takeaway is this:

Understand the tools you are using.
If it hurts, ask why. (I always liked Ayende’s Zero Friction thoughts.)
Finally, optimize your development experience for joy.

Comment on this post at dev.bennage.com.

The Last Six Months

Christopher Bennage — Fri, 07 Oct 2011 22:46:00 GMT

I’m two weeks shy of six months at Microsoft. When I arrived here I was immediately thrown into the fray on Project Silk. The primary developer on the project was heading into paternity leave. Fortunately, I had read JavaScript: The Good Parts on my flight out to Redmond. (I had no idea that I’d be diving deep into JavaScript.)

After Silk, I um, got to work on some other cool stuff that propelled me even deeper in the HTML5/JavaScript world.

After hours, I started playing with NodeJS. Specifically, spiking out some play-by-post dorky goodness inspired by the efforts of my buddy Drew Miller using Express, Mongo, and Expresso.

I’ve really enjoyed jumping back deep into JavaScript. This is a return for me in many ways. Back in the late 90s I was doing classic ASP development and I had settled on JScript over VBScript. (I had even begun writing an ORM in JScript, though I had no idea what an ORM was or just how deep the water can get. I just knew that I was tired of writing the same thing over and over.) I was also spending a lot of time with Flash and ActionScript back then. In fact, the Flash community was were I first encountered the MVC pattern. It was also the place where I first began learning about object-oriented programming.

Working at Microsoft has been a wonderful experience so far and I’m especially fond of my team here at p&p. It is a different perspective being on the inside. I’m excited about the opportunities to produce quality guidance. I’m also glad to help encourage trends here that I believe are helpful both to the company and the community.

As a bonus, these first six months here in Redmond have been beautiful weather.

My next project is exploring the mobile web. This is a crazy, active, and vibrant area at the moment. There’s a lot for me to learn. Fortunately, we value transparency here in p&p and I intend to post frequently about my projects.

N.B.

I’ve relocated my official blog to dev.bennage.com. I plan to continue to cross post here on devlicious, but if you want to comment you’ll need to head to the official site.

A Punctuated Life

Christopher Bennage — Wed, 06 Apr 2011 21:23:00 GMT

Chapter XXXVI

My time with Blue Spire has officially ended. I have accepted a position with Microsoft on the Patterns & Practices team. My start date is April 18th.

Even though I’ve been professionally restless for a while, leaving Blue Spire turned out to be rather emotional for me. Untangling myself from a business I spent almost five years building up depressed me. Nevertheless, it’s done and Blue Spire lives on. Keep an eye on Rob’s blog for details about the company and his future plans.

Why?

Several friends have asked me why I would make this choice. Why would I leave running my own business? Why would I go to Microsoft of all places? Why would I uproot my family from a city we love, from dear and close friends, and move so far a way?

I needed a reboot. I wasn’t achieving the personal professional goals I had set for myself and I needed to reevaluate. I wanted a job and a city that would expose me to lots of different influences and perspectives.

So why Microsoft? There were several really exciting positions out there and it was hard to choose. In the end, the Microsoft position had the best balance for what I wanted in my next professional role. I’m genuinely excited about joining P&P. I asked around and I heard nothing but good things about the P&P team. Even from folks who are critical of Microsoft in general. In addition,the values and culture of the team align with my own. They have a vision I can buy into.

Still, at the end of the day, my wife and I made the choice to have the experience. We want to spend some time living on the West Coast. I want to see what it’s like to work for a giant like Microsoft. We wanted to live near a major city, and mountains, and ocean. Of course, I had other goals as well; certain financial criteria I needed to meet, opportunities to learn and grow, chances to exercise my pedagogical nature, and so on. They all flowed together. In the end though, I want my life to be punctuated, full of chapters, experiences, and stories.

I’m excited.

What I Learned Playing StarCraft

Christopher Bennage — Mon, 31 Jan 2011 02:13:00 GMT

On March 31, 1998, around 10am, my then-manager Alex and I left the office we shared together and headed over to Electronics Boutique. Alex and I were both developers working for the IT department of an up and coming software company called PC DOCS. In those days, we didn’t have a corporate firewall. My desktop was a node on the internet. In fact, I was running a web server on it. A bunch of us would stay late after work, barricaded in other peoples’ cubicles, all phones on speaker, playing WarCraft II and Quake. Those were halcyon days. I was just about to turn 23. I was just about to get married.

Alex and I had headed to EB because it was Release Day for StarCraft. I don’t think that I had ever been so excited about a video game. Well, maybe once but that’s another story…

A few months ago, StarCraft 2 was released. While there wasn’t as personal ceremony this time, I still purchased it on Release Day.

This time around I decided to really learn how to play the game. In case you are unaware, StarCraft is huge. There are televised tournaments, professional players, and so on. In many ways, it’s analogous to chess. As I began to learn more about it, I found that there are certain tenets of gameplay and, as I mused on these, I found that they extend to life in general (though I’ll limit them here to a professional context).

The First Lesson

In the game, there are a dizziness amount of options. Your opponent can overwhelm you with astounding ease if you are unprepared for their particular tactic. So you might be inclined to try and prepare for all contingencies. But guess what? You can’t. You will end up spending all of your resources ‘preparing’. You think that this aligns with your overarching goal, but in reality it is a distraction.

Professionally, we are given a goal: build software that will do X. As developers we typically and immediately begin thinking about all the ‘what ifs’. Usually because we’ve been burned by them in the past. X is still in sight, but there is a long road to get to there, because we have to deal with Y and Z and so many other things. We have to be prepared.

The truth is that you cannot be prepared for everything. It is actually a waste of energy and a distraction from your real goal. In the game of StarCraft, if you try to prepare for everything, you will lose. Instead, you must choose your battles.

The Second Lesson

How do you know which battles to choose? Surely a battle is coming. There are always problems in every project. You can’t simply be unprepared. That’s suicide.

In StarCraft, the answer is scouting. That is, you gather intelligence about what the enemy is doing. Once you know, then you can prepare properly and efficiently.

Recently, I was asked about some performance concerns at the start of a project. Now, I have been seriously burned by performance issues. In fact, one of the worst software disasters I was a part of was a performance issue. Nevertheless, the concerns raised with granular and premature. As Donald Knuth said “premature optimization is the root of all evil”. Now, I am most emphatically not saying to avoid optimization. What I am saying is to scout, gathering intelligence and responding accordingly.

A Summary

I’ll sum up these two thoughts:

Don’t waste time on things you don’t need.
Find out what you need through active analysis.

None of this is new. In fact, you see pretty much the same things preached all over. I hear it in XP, I hear it in Agile, I hear it in StarCraft.

Epilogue

I’m reminded of a passage from G. K. Chesterton’s Manalive (chapter 3):

"Well," said the girl solidly, "what is there to wake up to?"

"There must be!" cried Inglewood, turning round in a singular excitement—"there must be something to wake up to! All we do is preparations—your cleanliness, and my healthiness, and Warner's scientific appliances. We're always preparing for something—something that never comes off. I ventilate the house, and you sweep the house; but what is going to HAPPEN in the house?"

My Kinect Review

Christopher Bennage — Tue, 09 Nov 2010 20:49:00 GMT

I didn’t intend to purchase a Kinect for some time. However, there I was, walking reluctantly through Stuffmart, picking up a few random items for my home office. My four year old son, Ranen, had accompanied me. I was digging through various audio connectors when Ranen stopped and said “Daddy! It’s that game!” He was referring to Kinectimals.

I was stunned. He was standing in front of a shelf full of Kinects. I had been under the impression they were sold out nearly everywhere. I stood there, staring destiny in the face. The purchase was inevitable, so I embraced it.

The Setup

There was very little to setting up the device. I don’t have the newer Xbox, so the Kinect just plugged into the wifi port on the back. Once the device was detected, an application called Kinect Hub was installed. It’s like a minimal version of the main Xbox menus built specifically to utilize Kinect’s features.

There was also a built-in tutorial that both explained how Kinect works and did some initial calibration. It lasted 5 to 10 minutes at most.

I moved our coffee table out of the way, giving us about 12 square fee to work with. That was all the space we needed.

Kinect Adventures

Kinect Adventures is the game that comes with the device. It consists of 5 mini-games and reminded me a lot of the initial offering for Wii. The game takes longer than most games to start up. There is a period of calibration for the device as the game starts. After letting it run through this the first three or four times we started the game, I began to skip the calibration with no noticeable impact.

Ranen and I were able to join in a start playing immediately. Picking up the game for him was much easier than it had been using controllers. (His favorite Xbox game is Lego Star Wars, but he still fumbles with the controls every now and then.)

My 8 year old and 2 year old showed up about this time. We discovered that you can simply swap places with an active player to jump in. So two of us would play, while the rest sat on the sofa (which happened to be just out of range).

The facial recognition struggled somewhat with us switching places. I also wonder if poor lighting affected it as well. There is very little light on our faces when we are facing the TV.

I was impressed with Kinect’s ability to keep track of active players with my children constantly running around. It would temporarily lose a player if someone walked in front of the device (and thus completely occluding a player). However, it would pick them back up almost immediately.

It also struggled just a bit with Ranen’s size. Remember, he’s four. Every now and then, it interpreted him as squatting when he was really standing. It didn’t really affect the gameplay, but it bothered him. My two year old didn’t really play, but the Kinect would occasionally get confused when he would wander into the play area.

The game itself was a hit with the kids and I had a lot of fun as well. I’m sure the game will get old after the novelty wears off, but it is definitely a fun entry title.

Demo Games

Saturday night we had a few friends over sans children. In addition to Kinect Adventures, we played through some of the included demos. The dance game was a hoot and it is definitely on the “to buy” list. We also had fun with the racing game, but I don’t anticipate it having enough variety for the long term. I was impressed how friends who don’t play video games at all were able to pick it up and navigate the games.

The fitness game demo was short, but very impressive. That’s on the “to buy” list as well.

Voice

The voice recognition works, but isn’t really that useful. You can navigate Kinect Hub, but that’s about it. Funny enough, it doesn’t recognize my daughter. That really frustrated her.

Interface

The default interface is a little clunky. This is a UI design issue though and not a problem with the hardware. For example, the dance game has a great navigation interface for Kinect.

I’m hoping this will improve in future updates.

Summary

Overall, I was impressed with Kinect’s ability to cope with the chaos of active kids. It really delivers on what it promised with respect to “you being the controller”. The games I tried felt natural, were lots of fun, and contained many creative surprising uses of the hardware.

I do think Kinect is best suited to family and party games, but there’s an increasing amount of that in my life.

Recommendation: purchase.

Visions of Software Development or Can’t We Just All Get Along?

Christopher Bennage — Tue, 12 Jan 2010 11:38:00 GMT

I’m currently reading Thomas Sowell’s A Conflict of Visions: Ideological Origins of Political Struggles. As the title suggests, it deals with certain fundamental differences in the way we see the world and how that affects our political views. Don’t worry, I’m not going to delve into politics in the post. However, I was struck by how applicable the ‘visions’ in the book are to the competing (and conflicting) views about how we should write software.

Here’s a simplified sketch of the two fundamental visions in the book. (Note that I’m not attempting to make a judgment call here on which vision is correct or better. Though admittedly, I have my bias. Likewise, I’m necessarily keeping it simplified.).

Complex problems are best addressed by:
[a] systemic evolution or [b] clear and articulated reason
When a complex problem is addressed the result will most likely be:
[a] a set of prudent trade-offs or [b] a solution
Better results are produced when governance is provided by
[a] role and ritual or [b] well-educated individuals

This is just a few characteristics indentified in the book. We have a tendency to favor either the A answers or the B ones.

Let me unpack this now in terms of software development. I think that the philosophy of agile/software craftsmanship/etc has generally preferred the A answers. While more traditional software development has generally preferred the B answers.

Many agile practices (such as TDD) build up software through systemic evolution. (Tim Barcz touched upon this idea some time ago). Evolution is at the heart of iterative design. In opposition to this is a heavy initial design phase (or Big Design Up Front). In BDUF, the problem is analyzed and a clear, detailed path is laid out.
I think the second point follows implicitly from the first point. BDUF is a ‘solution’, whereas iterative development is inherently about trade-offs. By the term ‘solution’ I am implying that on such-and-such a date, the software will be delivered and the problem will be solved. The value is delayed, but it is complete. In an iterative project the goal is to deliver immediate, but only partial value. It acknowledges that some value is always omitted and that the software might never be complete.
The third point is one of the more divisive ones. I believe that agile practices focus a lot on ritual. TDD is a ritual. (I believe there was a Hanselman interview with Robert Martin that discussed this point). Kaban, Scrum, and other similar practices are ritualistic. These rituals are the soil where the systemic evolution grows. On the opposing side, development teams are led by architects. That is, by well-educated and intelligent individuals who have a greater understanding of what needs to be done.

My Bias

It is always important to admit your bias. I tend to favor the A answers above, though not always. I have been in circumstances where that approach broke down.

Regardless, I highly recommend the book as it has given me a lot of insight into my own views and those of others.

Lacking Confidence

Christopher Bennage — Tue, 25 Aug 2009 11:47:00 GMT

One of my biggest professional hindrances is a lack of confidence. I don’t have a CS degree. In fact, I have almost zero technical academic training. (My degree is in Religious Studies). In addition, I hang out with a lot of very smart and motivated programming gurus. I tend to judge myself by what they are capable of, and hence I often fail at my own standard. Add this to the fact that we men have fragile egos and it’s not hard to see how I arrive at this lack of confidence.

Last week Rob and I presented at the Orlando .NET User Group. Walking back to the car afterwards, I was chatting with Scott Densmore. He mentioned that he doesn’t blog as much as he would like because he’s not convinced that he has anything of value to say. At first this surprised me. If you know Scott, then you know that he has a lot of interesting things to say. In addition, he’s very good at saying them. However, after a moment’s reflection, I recognized that I think the same thing all the time.

What Others Think

Despite the fact that I don’t officially care what others think, I frequently base my actions on the anticipated responses of others. :-P

I am afraid of failing in front of my peers. This has become evident to me as I have worked on NHProfiler. Ayende is something of a Rock Star in the .NET world (though he may not believe it). I was timid to commit code. He might look it. It would suck and then he would know I was an idiot. I mean, I know that I do dumb things all the time but I didn’t want to let that out.

That is the wrong attitude. Instead, I need to open and transparent. What’s the worse that can happen? I write some bad code. We have to revert a commit and then I learn how to write better code. (Yeah, this did happen and I lived.)

Bias Towards Actions

Where am I going with all of this?

We often talk about the value of Failing Fast. We want to surface problems as quickly as possible, so that we are able to address them sooner. We apply this to development tasks, to project management, and even to the way we structure code.

Too often I have not acted, because I was afraid that I would seem stupid, irrelevant, or inadequate. My advice: don’t be afraid to act. Sure, you might fail but that’s okay. Actually, it’s more than okay. True failure is not in falling down, but in refusing to get back up. If you aren’t failing, then you probably aren’t accomplishing anything.

Refactoring Relationships

Christopher Bennage — Sun, 09 Aug 2009 01:45:00 GMT

Working with people is a lot like working with code. New relationships are green fields. Over time they become brown fields and (just like code) they require maintenance. I’m sure that everyone reading this can identify some legacy relationships that they would describer as, well, complicated. Just like some legacy code.

I mean a lot with the word ‘relationship’. I have in mind everything from co-workers to friends to significant others. These variations all require maintenance and I think we should deliberately structure our relationships so that maintenance is easier.

Interaction Smells

So what is the social equivalent of a switch\case statement?

We talk about code smells in software development as suggestive indicators that something is wrong. In our relationships, it is interaction smells. I would consider these common emotional responses to be smells:

avoidance
irritation
suspicion

Personally, I have been guilty of avoiding someone because I thought I would irritate them and I didn’t want the hassle. This was in a work environment and it a negative effect on the overall efficacy of the group. My impulse to avoid was a smell and it led to a problem that needed to be addressed.

Amicability Debt

Bad code gets worse over time. We call this technical debt. Relationships that have soured do not get better by themselves. Little fractures grow over time. If we don’t address them when we smell them, the stink only gets worse. In addition, the stinky relationship can be begin affecting other parts of design, uh I mean, other social interactions (e.g., the team you are working with).

Refactoring the Relationship

Relationships are more difficult to work with than code for one primary reason:

You cannot revert back to the last revision if your changes fail.

Nevertheless, we often need to make changes. Refactoring code doesn’t change the exposed functionality, but we make internal changes to improve it. If you are beginning to have problems with your boss, that doesn’t necessarily mean it’s time to quit (change the function) rather you might just need some relational refactoring.

But what do I mean by refactoring a relationship? Well, there’s a lot to be said there and you can find a lot of practical advice on dealing with conflict and more over on “Doc” List’s blog.

In brief though, I mean this:

Be honest and humble. “Hey, Joe, I feel like you’ve been a bit on edge with me. Did I do something to frustrate you? I’d like to clear the air.” Then talk it over. Again, refer to Doc’s blog for lots of details.

I would like to qualify this further. Since you cannot revert what you say and do, you must be deliberate and thoughtful about your refactoring.

Afterword

You can see where my brain has been lately. It’s the cross-pollination of ideas from software development into all other human interests. Next week: multithreading and Italian cooking, followed up by ALT.NET and comparative religion.

If any of this resonates with you, you might be interested in (a possibly controversial) post regarding the maintenance of marriage on my personal blog.

Agile Living

Christopher Bennage — Wed, 05 Aug 2009 03:14:00 GMT

I yearn to be consistent. I want my professional values to be the same as my personal ones. This is why I was quick to sign the Agile Manifesto; it aligned with my personal values.

I have been overcommitted for the last couple of months and the stress has forced me to do some professional reevaluation. I had a number of entrepreneurial and professional books on my back log. One of the book was The 4-Hour Workweek by Timothy Ferriss.

I really like this book.

That’s nice, Christopher. Thanks for sharing. What does this have to do with software development?

Not a lot. Perhaps. But I think it has a lot to do with the philosophy of Agile.

Eschew BDUF

One of the first ideas in the book is that the notion that retirement is a bit silly. We spend forty something odd years saving up money to retire and for what? How do we really know what to save up for? Do we honestly know what our requirements for old age will be? The standard cultural approach to professional life is Waterfall. We spend so much time building our product, and we have one big rollout.

Iterative Design

I recently watched the film Holiday with Cary Grant and Katharine Hepburn. In the movie, a young and savvy Johnny Case (Grant) struggles between Doing Business (because that’s sensible) and taking time off to figure out what he wants out of life. Ferris makes a similar proposition in the book. He suggests planning mini-retirements. It’s a release often, release early approach to life. Discover what you want you by trying things out. It’s Life in Sprints.

Illusion of Slackness

Agile has had a bad rep for being unstructured and lacking in discipline. Of course, practitioners of Agile know the exact opposite is the case (and let that be a life lesson in itself). One of the things I love about Agile is the focus on delivering value. Likewise, my initial perception of the book was that it was a guide for the lazy; just another Get Rich Quick scheme. No, it’s about being deliberate with your life. It’s not a book that most people can use, because it requires disciple.

Eliminate Waste

If I’m being technical, I guess I would say that this is a Lean principle. However, Lean and Agile are complimentary ingredients in the tossed salad that is my head. Ferris applies this principle to all of life. It’s a beautiful thing. There’s a lot of waste in our lives, hidden under the veil of busyness. Find it and eliminate it. Repeat.

Conclusion

Okay, so I guess this turned out to be a book review of a non-technical book. If any of this stirs your brain, then I recommend that you read the book. If you are compelled by the ideas of Agile or Continuous Improvement, read the book.

My Advice: be deliberate with your life, your professional, and your time.

“… the unexamined life is not worth living…”
Socrates, Plato’s Apology

“Whatever your hand finds to do, do it with all your might, for in the grave, where you are going, there is neither working nor planning nor knowledge nor wisdom.”

Kohelet 9:10

Idealistic vs. Practical

Christopher Bennage — Tue, 24 Mar 2009 14:05:09 GMT

I often identify myself as an Agilist. When I first began to use the term, I was met with a great deal of trepidation. I remember the first few times I attended the local user group. “Oh, you’re one of those guys”. This hesitation has diminished considerably, but I still find that there are some interesting misconceptions about agile.

For example, people frequently contrast Agile with Pragmatic.

“Oh, I’ve heard about SOLID principles (or whatever), but I’m really more pragmatic.”

This has actually made me laugh out loud. You see, it was pragmatism that drove me towards the agile philosophy.

According to Meriam-Webster, pragmatic means:

relating to matters of fact or practical affairs often to the exclusion of intellectual or artistic matters : practical as opposed to idealistic

So here is the relevant contrast:

Idealistic vs. Practical

Is Agile idealistic or practical? Agile does embraces a set of principles (ideals) and I’ve seen many of its adherents become drunk with the beauty of it. I’ve been there a few times myself. So yes, it is idealistic in that respect. However, I think a better question is this:

Is Agile merely idealistic?

There is a strong idealistic streak in Agile, we will not deny it, however the ideal is actually “get work done”. In other words, Agile is the art of pragmatism.

I am motivated by success. I am motivated by accomplishing things. The quickest route to depressing me (or frustrating me) is to prevent me from getting work done. Because of this, when I first encountered the agile idea that change is expensive and therefore we should reduce the cost of change, I was listening. When I discovered that agile methodology offers a set of tools for reducing the cost of change, I was ecstatic.

In the interest of being brief, I’ll jump to my conclusion:

The application of the agile principles is about being successful in software development projects. It is not ars gratia artis. While some enthusiasts may forget that, it doesn’t change the nature of the underlying principles.

Agile is the art of being pragmatic.

MSDN DevCon Reflections

Christopher Bennage — Fri, 12 Dec 2008 17:17:52 GMT

I had a great time at the conference yesterday. I really appreciate everyone who attended our sessions as well as all the positive feedback. For those of you in other cities,Orlando was just the 2nd conference. The rest are still to come.

For anyone interested in the materials from our sessions:

MapDotNet (from the keynote) Don't forget this is free.
jQuery
WPF ToolKit

Why You Should Go

Yes, there are lots of presentations and great speakers, but in retrospect I really think these are secondary reasons. The highlight of the event is the under-advertised Community Courtyard.

Community Courtyard is an Open Spaces-ish gathering facilitated by "Doc" List. No one seemed to know about this portion of the conference, but thankfully Joe Healy herded some of us into the courtyard for a tweetup. (I think the tweetup was just an excuse to get us into the courtyard.)

The result was great conversation. We talked about many things ranging from dealing with conflict to functional programming. These sorts of environments are where I have had the biggest gains in my craft. I can't encourage you enough to check this aspect of the conference.

post scriptum
For those of you twitterati who have asked me to get Rob Eisenberg on Twitter, his name was apparently revealed at this tweetup.

An Early Start

Christopher Bennage — Wed, 10 Dec 2008 01:42:17 GMT

My daughter is about 6 ½ years old. Her reading skills have blossomed in these last 6 months. It's been an amazing experience as a parent both contributing and merely witnessing her discovery of literacy.

Programming is one of my passions, and I like to share my passions. Like watching a sunset, it's better when you are not alone. I've been kicking around ideas for teaching her how to program for a couple of years actually. I had a few concepts that I never got around too, but I abandoned them all when I heard about Boku.

Boku is an iconic programming game for the Xbox. Microsoft announced it at PDC. It looks really cool, though I do have a slight hesitation about the iconic part. (I do so like words.)

Tonight, just before dinner I stumbled onto Small Basic via Brian Johnson's blog. It's essentially a simple IDE with very pretty IntelliSense (that includes keywords). There's a simplified API for accessing things like the system clock and the desktop's wallpaper. Most of it well over my daughter's head. However, I noticed a class called Turtle that allows you do draw in a Logo-esque manner. I decided to see if she was interested. She was.

Here is her first program. I left the IntelliSense popup for you to see.

The output is animated, but here is the final state:

I spent about 15 to 20 minutes explaining the concept, and demonstrating it to her. I recommended that she try to draw an A, but she choose a square. I tried to let her reason it out as much as possible, and only provided guidance when I feared she might get frustrated. (The biggest problem was the parentheses, I had to keep reminding her. I had her execute it to see if it was doing what she expected. I even had her pretend to be a turtle while I gave her commands to move around the room. The funniest moment was when she asked why I kept saying to "run" it.

Tomorrow she wants to draw a triangle!

Tampa Code Camp/WPF Presentation

Christopher Bennage — Mon, 08 Dec 2008 15:17:41 GMT

I had a couple of requests for my slide deck. It's short and mostly pictures, but here it is.

Additionally, the xaml-only font viewer is here. (You might want to do a right-click, save as). The binding example (old way vs. wpf way) is here.

I want to thank everyone that came to my presentation. You were responsive and interactive, and I was energized by the session. I also want to thank the DevFish for pushing me to get more involved in these events.

Some additional personal highlights from the event:

Bill Reiss of Blue Rose Games did a session on developing games with XNA. Specifically, he demonstrated publishing the game to his Zune. Very cool. His Dr. Popper game will be among the community games on Xbox Live soon. It should be pretty cheap as well. (Support indie game developers!)

Meeting passionate people who are excited about their craft is always the best part of these events. I'm always looking for the cross pollination of good ideas. It's also great to discover what's going on in neighboring communities.

I got chat to Los Techie ninja Sean Chambers, a fellow agilist and BDD/TDD practioner . We're doing a TDD firestarter in Tampa next month. I'm really excited about the event.

I also meet Jay Kimble and had some good conversation about the controversies of ALT.NET and related practices. Jay's also one of the forces behind the Tampa UX group; a user group for developers focused on usability, UX, and general UI issues. I'm fascinated by this as those topics are increasingly my focus.

If you are in Florida, don't forget to come the the MSDN Developer Conference in Orlando this week. Rob and I will be there showing off some of our recent work for the Tallahassee-based MapDotNet.

Dubious Honors

Christopher Bennage — Tue, 18 Nov 2008 22:59:00 GMT

Update: With striking proof that I'm dense and a Developer of Little Brain, Andrew points out that the results are sorted by date added. :- P

On at least one torrent search site, our book is the #2 item when you search for WPF. Not searching for "WPF book", just "WPF". Rock on.

I have an alert setup that notifies me every time the book title is indexed on Google. There's an new pirating (free books!) link about once a week.

If only I had a positive review for each site! :-)

Solving Problems with TDD

Christopher Bennage — Thu, 06 Nov 2008 20:03:00 GMT

I'm giving a talk on TDD at our local UG tonight, and under the influence of some recent posts here on devlicio.us, I just finished reworking my presentation. This post is an outline for the first half of my presentation.

The Problems

Code has entropy. That is over time it deteriorates. At least, that's the metaphor we developers like to use. What is really means is that the code becomes harder to maintain and extend as it is maintained and extended over time. Did you follow that? Our typical approach to maintaining and extending code causes the code to become fragile and rigid and thus harder to maintain and extend in the future.

There are three common difficulties that arise, maybe more, but I'm focusing on three:

Unchangeable Code
Unintelligible Code
Unnecessary Code

A portion of code becomes unchangeable when its deeply entwined and entangled with other portions of code that have different responsibilities. You can't change method X because we really don't know what that will do to Y and Z.

Code can become unintelligible for lots of reasons: abbreviated names, circuitous logic, enormous methods, confusion of responsibilities, use of php☺, etc.

Finally, unnecessary code is code that is not used by the system. It can be vestigial, or as often happens, it can be the result of feature anticipation. We thought this was going to be needed in the app, so...

The Solutions

There are some generally accepted solutions to these three problems.

In the case of unchangeable code, we can apply such patterns as Separation of Concerns (SoC) and the Single Responsibility Principle (SRP). For addressing unintelligible code, we have a number of techniques such as thoughtful comments, explicit naming, SRP again, etc. Finally, for unnecessary code we have the old axiom of You Ain't Gonna Need It.

Okay, so we know how to solve the problems. Or least, we know how to mediate them. So what? What does that have to do with TDD?

My proposition is this: solutions are without value unless they are applied.

Additionally, when a problem occurs over time, the solution must be applied over time.

The Analogy

I just started going to the gym. It's been about a decade since I did that, but I'm back. For the past several years however, I have been preaching to certain family members the value of exercise and healthy diet. I knew the benefits: stress reduction, longevity, improved sleeping, and just plain feeling better. However, I wasn't really doing either.

I had the problem and I believed in the solution and, in fact, I made attempts to employ the solution. Ultimately, I was unsuccessful. That is, until I committed to go to the gym three days week at a set time and with a workout buddy.

My point is this, we are human beings and despite being smart we frequently revert to doing "the easiest thing". Therefore, we ought to set up some sort of framework of methodology or discipline where the easiest thing is actually what we want to do.

Additionally, I have to keep on going to gym. For as long as I want to be fit, I will need to exercise. In the same way, for as long as I want my code to fit I will need to apply good principles.

TDD as a Discipline

I will argue that TDD is a discipline that enables the application of the solutions outlined above. Perhaps you apply those solution naturally. Perhaps you can benchmark 200lbs because of your genetic disposition. Bully for you. Go ahead and skip the rest.

Let's examine a few essentials of TDD and see if they really address the problems we outlined.

Test First

I'm an advocate of automated testing in general. However, I do think that writing your tests first yields additional value. Primarily, it helps you discover your ideal API. In other words, you can design your API up front such that it is more intuitive. More intuitive means easier to understand.

Secondly, testing first helps you identify dependencies early. You quickly discover that class X will need a Y and so you are forced to create seams in the application at the onset. This encourages SoC and SRP.

Testing Units

It took me a long time to understand the "unit" part of unit testing. The idea is that you decompose your problem into units, and deal with the problem one unit at a time. You could call this "test just one thing". Okay, well what is "one thing"? That is hard to tell and comes with experience. Nevertheless, the practice of trying to decompose a problem and identifying units leads you back to SoC and SRP again.

Just Enough Code

Another tenet of TDD is to write only enough code to pass the test. Our natural instinct is to anticipate. It is part of what we are as developer, and it is not a bad thing. However, like many strengths, it can become a weakness. By constraining ourselves to a single problem at a time we will end up with less code. It also forces us to be conscious about our anticipation and to ask if a given scenario is really necessary.

Conclusion

I know that there is much contention over the actual value of TDD as a practice, and I am not going to force it on anyone (unless I hire you and now you are warned). However, I have found it to be a useful discipline for helping me to overcome common problems and because of that I encourage it's use.