This looks like something right up my alley. Maybe we will see you there.

Kalamazoo X Conf

A New Metaphore - Epic Story to TV Series

I’m currently reading a book by Ka Wai Cheung called “The Developer’s Code: What Real Programmers Do”. In the chapter called “Metaphor” Cheung writes “...when I’m asked what I do, I often resort to analogy. Our industry is chock-full of them. It’s the way we describe our work to everyone else... metaphor has to become our meta-language. Not only is it how we connect the uniqueness of programming to the general public, but it’s often how we make decisions on how we approach our own software problems.” He goes on to explain how we borrow from traditional building when we speak of building software. We have roles such as engineers, architects, project managers and designers. We have borrowed our very identities from another industry. Some of that made a lot of sense when software releases were done over floppy disk or CD, but not today with the web the way it is. I wont quote the entire chapter, but he ends with the idea that, “Software development might be closer to writing a novel or composing music.” I love the writer analogy and I’ll probably overuse it so much in the future that it will become more harmful than helpful, but let’s have some fun with it.

There is a series of fictional books out by one of my favorite authors. Perhaps you have heard of George R. R. Martin, or perhaps you have heard of the HBO series that is based on his books called, “A Game of Thrones”. It has a very mature rating so be warned if you check it out. My new analogy for software developers and software projects in general is that of the epic book series turned TV series. Writers (Developers) take the original book (Business Processes) with the help of the director (Architects or Leads) and the original author (The Business), and they break it up into seasons and episodes. For now I like to think of the season as the current technologies a project will take advantage of. Each episode is a release with it’s minimum marketable features and these can and should happen much more often than we have allowed them to in the past. As Cheung says, we are on the web and people are now embracing iterative change much more than they use to. In all episodes there are lots of subplots or stories that make up the whole episode. Agile has already defined features as stories, so I’ll just stick with that for now.

Before I read this book and before this analogy, I started calling our sessions by season and episode (S3E2). It was just my funny way of keeping things interesting but now I’m going to rethink the significance of it. I think this is a way better description of our industry today than the bridge or skyscraper analogies of days gone by and as Brian and I co-author Luncht I’ll be thinking about it more and more.

Luncht S3E4 - Test Driven DESIGN - Chadrick's Take

There is substantial overhead when doing TDD, but the code is better for it and the knowledge transfer is automatic.

Doing things right takes time and a lot of effort.

What I found was my story bullets, what I call Acceptance Tests, were not completely thought out. It's hard to anticipate what you will be testing until you really spend some time focusing on the feature, which includes how the user will use the system, which in turn means views. Because we were unsure of the acceptance tests we started with wire-framing the two views (ForgotPassword & ResetPassword). Then psudo-coded our implementation in the form of comments so we generally know which services would need to be created. Then at the back-end it was a return to TDD to build our services. Eventually this brought us back up front where we tested our controller actions with mocks of these new service(s). It went pretty well I think, but led me to wonder about a few things.

First, most TDD tutorials only test business rules at the domain level (back end). When in reality we are developing our solution in an all inclusive way. Our features, to be complete need a front to back, or back to front (however you decide) implementation. I'm not saying I want to write a bunch of implementation tests, but we have to be looking at a workflow that covers all these pieces and interaction between these pieces, and I don't think we are there yet.

In the real world, is it possible for the business to write valid acceptance tests that we could convert directly to test methods? How does this work where your features are coming from the business who on one extreme wants to design and architect the entire solution, or on the other extreme doesn't have a clue what he/she wants. I think what we realized is that we developers will almost always end up massaging the acceptance tests while we determine more exact requirements.

My Second Set of Eyes When I'm Not Pairing

Tests become even more important to me when I'm coding alone. They allow me to focus on the here and now of my code while not having to spend a ton of time thinking about what I will probably break by making a change. They are in essence, my second set of eyes. Just yesterday I changed the very foundation of my current project because I found out I was doing it a bit wrong. (Side note: If I'd been programming as a pair we probably would have found this much sooner.) Rather than hack a fix because I was so far along, which I've done plenty of times in the past, I rewrote the foundation of my code-base. I only attempted this because I had the confidence that my test coverage would help me get back to where I needed to be in a short amount of time.

This quote from Michael Valenty is one of my favorites, "It’s like rediscovering that diet and exercise is the key to losing weight, except that I rediscovered that not having tests really sucks when you have to make changes."

Luncht S3E3, UI Testing - Chadrick's Take

Because our second session was a bit difficult I looked up a Plural Sight video on TDD and ASP.NET MVC. It was a very helpful video and led us to the conclusions I've already wrote in my post on Session Two.

After we decided what not to do, Brian did basically all the plumbing for us to implement Selenium tests against various environments. If we couldn't do a view test with TDD maybe we would do a view test with Selenium. Once the plumbing was done we wrote integration tests to validate we had a Registration page and we worked it all the way through to the Successful Account Creation page.

When we got this far we took stock of things and determined that we need to think of the Controller Action as a contract, and test it accordingly. Together we decided we would not be doing the Selenium tests as part of our TDD workflow at all. The third session was profitable and again we learned what not to do, but we are on our way to much more productive sessions in the future.

Retrospective

At the beginning of our session I felt like I had to dig into the recesses of my brain too much to determine where we left off. Those recesses are deep and dark so something had to change. Brian had the solution. He brought up our session doc and added a quick paragraph to that end. I'm looking forward to seeing if that helps us jump right into the code.

MVC Model Binding Feature Request

Model binding is smart but I really wish it would take care of my spelling errors for me ;)

Be Productive - RescueTime

I heard about this service at CodeMash (thank you Scott Hanselman) and I started using it a short while ago. It has literally made this blog possible for me. If you are a knowledge worker who works on a computer, has multiple meetings, email and IM to answer, and other things that distract you through the day RescueTime is for you. Give it a try. The basic version is "forever free" and it's worth it IMH(BC)O.

Paired Programming vs. Getting Input from a Co-Worker

So now that we have some experience in Ping Pong Pairing (PPP from now on), albeit limited, I find that while I'm working through some problem solving I'm also wishing I had another programmer to work along side. It's not good enough to get some co-workers opinion on the matter anymore, even though that's better than programming in a silo. When you are working together on the same code-base, you are both invested fully in the solution. You don't get half-thought-out, non-real-world psudo-solutions (man-I'm-using-a-lot-of-dashes). While doing PPP you are forced to understand the domain context and think through the code together. You are forced to think through the code and come up with a concrete solution together and I think this is a huge advantage verses the advantages or sometimes disadvantages to getting a co-workers opinion about your work.

About time for some contribution

Ok, its about time for some contribution here.  Hi, I'm Brian Krygsman (@brnkrygs).

I'm a software developer.

I think the bug hit me in the early years of high school.  I had spend my younger years playing with the Tandy my Dad brought home one day.  I was absolutely fascinated with it and found all sorts of excuses to interact with it.  There were simple games, and playing 'spy' by typing out word processing documents. It seemed magical to me that you could illicit behavior in a virtual world (or, more accurately at the time an imaginary world) just through tapping on keys.

Fast-forward a bit to high school where I helped found the computer club at the school and began getting more into software.  Karel the robot was where it was at.  I loved tackling and solving problems and Karel presented entertaining problems to solve, while gently introducing programming concepts like branching structure, iteration, and recursion.  Before that I assumed I'd have to be a structural engineer to be "problem-solver" in the way I felt called to be.  But my exposure to software development easily convinced me there was a better avenue for my interests.

I think the aspect of software development that captured me was the endless creative possibility.  The idea that you're building an environment from scratch. You define the rules, you define the structure, you network with other environments if you so choose.  Those poor structural engineers are stuck solving problems in the physical world with all of its complications and limitations.  Fascinating and creative solutions come out of those restrictions of course, and thats not to say that software doesn't have its own level of restriction. But, part of the nature of software right now is how fast it breaks through limits that once were considered hard-and-fast.  Working in software gives me the freedom to solve problems in creative ways, to build fascinating systems and worlds, and to help those around me (and on the other side of the planet!) interact with their increasingly digital lives.

As a professional, I've spent most of my time developing on the web. In college I did a bit of work with Java thick clients, but since then its been on the web. Mostly LAMP stack work (Linux, MySQL, Apache, PHP/Perl/Python), with a heavy dose of front-end CSS/Javscript alongside, but more recently I've been working with Chadrick in the .NET world with C# and Microsoft SQL Server, with a bit of Ruby (Rails) on the side.

As Chadrick said, this blog is mostly an exploration of the Ping Ping Paired Programming development methodology.  Or, this blog has at least been initiated by it.  We're both passionate about improving ourselves as developers, learning as much as possible, and finding a way to implement it.  I'm excited to see where this leads.

Luncht S3E2, Controller Testing - Chadrick's Take

We spent a lot of time writing controller tests and trying to figure out how to get the rendered HTML from Controller.Index() What we didn't understand at the time was that this is not really the way it is designed to be tested. We still learned a lot even though it was learning how NOT to do things.

Basically if you are going to be testing MVC don't try to test the rendered results of a controller action. You can test that the ViewResult has the correct Model and that the View exists by checking for an empty ViewResult.Name, but don't expect to test the rendered HTML. Brian made a good point when he said, "Our views should be stupid. If anything is going to be smart it needs to the be the business layer and the controller needs to know hot to access the business layer." Now that is not word for word, but it's how I heard it. I question if this would be true for heavy client side scripted apps.

Still having a lot of fun with this, so keep an eye out for our future postings.

Luncht v.3 - Password Reset

Not sure if we will get to this feature tonight but I'll try to keep one step ahead of our sessions so we are not wondering what is next.

Password Maintenance

As a user I need to be able to reset my password if I've forgotten what it is or whenever I would like to change it.

• Key Is Created for forgotten Password
  A key needs to be created that will be sent to the user in the form of a link.
• Key and New Password Required for Reset
  If key does not match we will error out.
• New Password Will Be Encrypted
  We never want to see the password so the new one will be encrypted.
• Email and New Password Will Validate User
  If Email and New Password match the user will be valid.
• If User is Validated Password Can Change Without Key
  If the user is logged in the key is not required for password reset.

I think this is doable in one session. If not it's not a big deal.

Luncht v.3 - Session One - Chadrick's Take

I want to start by thanking Brian for trying TDD & PPP. I knew he had (maybe "has") a tendancy to shy away from pairing and I appreciate his openness to try it.

I also want to thank Dan Tape for throwing out the suggestion that we try Google Hangout for our dev sessions. As far as I'm concerned it's as good, and perhaps better than real life. Now we can base our showering habits wholly on our wives desires to be around us. if you have not tried Hangouts, do it and save some soap.

I had pre-written a feature called 'Registration' with a few bullets of acceptance tests to start with. I was basically following our precompiler format. Then because we are both familiar and fans of Pivotal Tracker I converted that item to a story with tasks for each of the acceptance tests.

Registration

As a user I need to be able to register for a new account so that I can use the system.

• Required Property FirstName
  User needs to have a FirstName property and it is required.
• Required Property LastName
  User needs to have a LastName property and it is required.
• Required Field Email
  User needs to have a Email property and it is required.
• Required Field Password
  Password field is encrypted once set.
• Password Field Needs to be Encrypted
  User needs to have a FirstName property and it is required.
• Default Chat Notifications
  During registration users are will be signed up to receive chat notifications.
• Default Deal Notifications
  During registration users are will be signed up to receive deal notifications

When we opened Visual Studio we started with a class library project and loaded NUnit and Moq with Nuget. We had one test at first with all the fields in it, but later refactored it so that each prop had its own test.

[TestFixture(Description = "As a user I need to be able to register for a new account so that I can use the system.")]
public class Registration
{
    [Test(Description = "User needs to have a FirstName property and it is required.")]
    public void RequiredPropertyFirstName()
    {
        // Arrange & Act
        const string firstName = "blah1";
        var user = new User( );
        user.FirstName = firstName;

        // Assert
        Assert.AreEqual(firstName, user.FirstName);
    }

    [Test(Description = "User needs to have a LastName property and it is required.")]
    public void RequiredPropertyLastName()
    {
        // Arrange & Act
        const string lastName = "blah2";
        var user = new User( );
        user.LastName = lastName;

        // Assert
        Assert.AreEqual(lastName, user.LastName);
    }
}

As you can see I've started putting the text inside of Description of the Test. I have an idea for a code generator that would build these tests out with an [Ignore] attribute on them. I might write about this in a future post. But as you can see we build our tests based on the required acceptance tests. Understand properties are not the sexiest of tests to write and perhaps a bit overkill, but it's TDD and we are 100% sure when done means done.

For most of this session we just did domain object tests. They were very basic and that allowed us to practice the Red >> Green >> Refactor Ping Pong Pairing workflow. For those of you who don't know what that is I'll give a quick run-through.

1. I start by writing a failing test. We decided our code had to compile so we had to create what was necessary for that to happen. I pushed the code to BitBucket for Brian.
2. He implemented the code to make the test pass and then checked it into HG and pushed it back to BitBucket.
3. We talked through things if necessary and refactored it accordingly.
4. Now it was his turn to write the failing test, so we jumped down to the next bullet.
5. I implement...
6. He refactors...
7. ...repeat

I was happy how it went. I'll let Brian give his own take on it.

TDD and Ping Pong Pairing

At CodeMash I attended the precompiler event, 'Putting the D&D Back Into TDD' by Guy Royse (@guyroyse) and George Walters II (@walterg2). Now I'm an old school D&D player at heart so this abstract was right up my ally.

Abstract: Are you tired of TDD workshops that make you do boring things like calculate bowling scores and prime factors or demonstrate how to win at the game of life? If so, this is the session for you! In this TDD workshop we will be building the domain model for EverCraft -- a new MMORPG from Blizzards of the Coast. We have lots of story cards prepared covering features from combat to magic, classes to spells, and races to items. Plus, we'll be defining some of these cards during the session in case you want that +9 knife of ogre slaying or enjoy casting magic missile at the darkness. This workshop is language agnotisic and for all levels of developers. The focus is on TDD and emergent design but pair programming will be covered as well. The only requirement is that you bring a laptop and that you be able to test-drive you code with your language of choice. When you are done you will emerge a better programmer for the experience but there is small chance you will have a craving for Cheetos and Mountain Dew.

Early in the session George said something that had a huge part in the development of this blog. While talking about agile practices and paired programming in particular he said, "Let's be honest, programming alone is scary." I laughed a little and then the thought kept coming back to me throughout the day and ever since.

"Let's be honest, programming alone is scary."

                                                                            ~ George Walters II

As promised we were given a sheet of features then instructed to team up with another dev who was using the same language. Then we started. The workflow was simple. One of us would write a failing test, the other would implement the code to make the test pass, and then the first dev would refactor the implemented code.

At first we were unsure of ourselves and decided that maybe we knew better. We would take and write two tests; one each. Then we would switch and implement the other's test at the same time. Then we would refactor together and this seemed to work out alright for us. After our first iteration we had a retrospective and talked about our workflow. Guy and George talked us into doing it the more purer way, so after lunch we did and realized some major benefits.

Benefits of TDD & Ping Pong Pairing:

1. Focusing on the acceptance test stopped me from over designing the solution.
2. Writing the failing test makes you think about how you would like to use a class and its methods.
3. Implementing code to make the test pass kept me focused on the test at hand vs. stuff we are probably not going to need. YAGNI
4. Watching each other program and discussing the problems together helped each of us learn.
5. We both had intimate knowledge of the codebase when we were done.
6. Working on things together kept us from becoming distracted by outside influences (email, phone calls, day dreaming etc). We continued to code for almost 8 hours with only a few breaks.
7. We knew when we were done with our feature.

Something that I came away with is that Test Driven Development is less about testing and more about designing. I watched a video about TDD that used the analogy of tests being like a carpenter's jig for the woodworker. There is a difference in that the developer only writes his/her test right before coding it while the carpenter starts with a complete jig.

This event motivated me to get back into Luncht with Brian. We have been using Google Hangouts to do our ping pong pairing and have done three sessions so far. It's been very cool learning the workflow together and I'm hoping that we will be writing more about this as life permits.

Hi, I'm Chadrick and I'm a...

...developer. When I first understood that I could press my fingers to the keyboard and build content of some kind something happened within me. I felt like I was tapping into some secret ancient arcane power. I could summon things to the screen if I knew the right words to type. I could make things happen faster than the speed of thought. Its hold on me grew more and more. I would spend countless hours in a small room lit only by a monitor, learning and coding anything and everything I could. The more I learned, the more I believed anything was possible. If I could imagine it, I could produce it; or at least the potential to produce it was a real possibility. Now marry that to the fact that I've always been an ideas person and you can start to see that I had a real problem. In order to help me understand my addiction I had to find other practitioners of these arts. It was hard back then because I wasn't going to school for it or working in it full time, but we found each other. I learned that we spoke the same language, squinted at the sun in the same way when we had to be out in it, and tended to do our own things our own ways. To save my marriage I had to get paid for my addiction and then things started to change. I had to learn what it was like to go into business with someone who promised me one thing for doing what I loved and then gave me something else. After that experience I joined corporate IT and had to mature even more. I had to learn about this thing called source control, and there were these people called Business Analysts, and these documents called Specifications Documents and the ever present DEAD-LINE and other developers who freaked me out because they obviously knew more than I did. Around this time I came across a book called, Extreme Program Explained: Embrace Change. WOW! If I could only get my co-workers and managers to understand the benefits of what was in this book our lives would be forever changed for the better. At the time my influence didn't go real far, but I kept at it. Gradually the people started to see what I had seen. I became someone with a bit more influence and we all started to hear the word Agile more and more. A few years and companies later; I'm still not doing extreme programming everyday but I'm starting to practice some of those extreme practices I'd only read about, and others are doing it as well. I'm hoping we can write about our adventures and bring something helpful to the table. Here is to hope.

CodeMash 2012 - Special Thanks

Thanks to my blog co-author Brian I was introduced to Christiaan Baes from Less Then Dot who was running a little competition. Because of that fateful link, a few sad words, a new boss, a supportive wife and the generosity of chrissie1 I attended CodeMash for the first time this year. Thanks to you all.

CodeMash is a unique event that will educate developers on current practices, methodologies and technology trends in variety of platforms and development languages such as Java, .NET, Ruby and PHP.