Archive

Archive for the ‘Pair Programming’ Category

A Developers Take On Pair Programming

March 16, 2012 Leave a comment

David Cooksey on Pair Programming

March 16th, 2012 | David Cooksey

A Developer’s Take on Pair Programming

Over the past few years at Thycotic I have spent a lot of time pair programming. Five days a week, eight plus hours a day adds up to thousands of hours. Through my experiences in pair programming I came to a few conclusions about the practice. These represent my take on pair programming, I make no claims as to their originality.

First: Pair programming makes programming social.

This sounds obvious, but it has by far the biggest impact on how you, as a developer, write code. You are effectively writing code as a committee of two, where each member has veto power. All the factors that developers typically do not have to deal with when working alone come into play. Do you like your pair? Does he/she like you? How about respect? Do you work in similar ways? Do you work similar hours? Will you argue incessantly over architecture? Did you or your pair have a rough night?

Second: Verbal communication is as important as technical ability.

Ideas have to be expressed clearly enough that your pair can understand them. The greatest idea in the world may never be attempted if it is not stated clearly. Equally important is the ability to offer clear reasoning when you disagree with an approach. “I don’t like that” is not sufficient.

Third: Two heads are still better than one. Usually.

The caveat to this one is the social aspect. While in most cases two people who are focused on the task can do a better job, the social aspects mean that particular people may be worse together than they are apart.

So, as a developer, what is the best way to pair program? With courtesy. Learn when to shut up and let your pair drive. Learn how often you can interject comments without causing undue irritation. Learn when to push and when to let it go. If you push for your point of view all the time, no one will want to work with you. If you always give in, no one will respect your opinion. Compromise.

What were your experiences with pair programming? If you have never tried it, what are your thoughts on the subject?

David Cooksey is a Senior .NET developer at LogicBoost, an agile software services and product development company based in Washington DC.

StrictMock vs. DynamicMock: What are You Testing Here Anyway?

July 16, 2009 3 comments

Dynamic Mock vs Strict Mock

July 16th 2009 | Jimmy Bosse

StrictMock vs. DynamicMock: What are You Testing Here Anyway?

Here at Thycotic, we are TDD enthusiasts and pair developers. Test Driven Development and Pair Programming go together like chocolate and peanut butter, especially when you tackle a brand new piece of functionality and practice some green-field Ping-Pong programming.

For those unfamiliar with the concept of Ping-Pong programming, it’s a fun way to develop a new piece of business logic when you are not sure what the best method of implementation will be.

To start, one of you writes a failing test. The other makes the test pass, and then writes the next failing test (refactoring as needed). You make that test pass and write a new failing test. The goal of the session is to write the smallest amount of code possible, then try to write a test that effectively tests the desired functionality while providing a challenge to your pair. The session is easy at first, but as the tests move toward satisfying the more complicated requirements of the business, the exercise becomes more challenging.

Once your code becomes suitably complex, you’ll start to have multiple classes with dependencies—and with these dependencies come mock tests.

Then you have to decide: StrictMock or DynamicMock?

The problem with Strict Mocks is that you are required to set up your entire mock dependency far beyond the scope of the subject/system under test (SUT).

Take the following example.

[Test]
public virtual void ShouldSubscribeToViewEventWhenConstructed()
{
    MockRepository mocks = new MockRepository();
    IView mockIView = mock.StrictMock<IView>();
    mockView.SomeEvent += delegate{};
    LastCall.Constraints(Is.NotNull());
    mocks.ReplayAll();
    IPresenter presenter = new Presenter(mockView);
    mocks.VerifyAll();
}

To implement a presenter:

public class Presenter : IPresenter
{
    private IView _view;

    public Presenter(IView view)
    {
        _view = view;
        BindToEventsOn(_view);
    }

    private void BindToEventsOn(_view)
    {
        _view.SomeEvent += SomeEventHandler;
    }

    private void SomeEventHandler()
    {
        //Do something…
    }
}

The test is now green because you’ve subscribed to the event. But now that you’ve bound to the view in your constructor, you must always expect a call in your test whenever you mock IView with a StrictMock. This will make your tests verbose and it will be difficult to determine the actual SUT in each test.

Another issue is this: When you use a StrictMock you are essentially telling your pair what to program. Let’s say you and your pair sit down to create a calculator business object that must be able to add numbers together.

Your pair writes the following test:

[Test]
public virtual void ShouldReturnFourWhenGivenThreeAndOne()
{
    int firstNumber = 3;
    int secondNumber = 1;
    int expectedSum = 4;
    MockRepository mocks = new MockRepository();
    IAdder mockIAdder = mock.StrictMock<IAdder>();
    IAdderFactory mockIAdderFactory = mock.StrictMock<IAdderFactory>();
    Expect.Call(mockIAdderFactory.Create()).Return(mockIAdder);
    Expect.Call(mockIAdder.Add(firstNumber, secondNumber)).Return(4);
    mocks.ReplayAll();
    ICalculator calculator = new Calculator(mockIAdderFactory);
    int result = calculator.Add(firstNumber, secondNumber);
    mocks.VerifyAll();
    Assert.AreEqual(expectedSum, result);
}

Well, there’s nothing to think about here is there? If this is the way you want to write tests, invest some time and write a tool that will parse your test and create your business object for you. The test tells you “use the factory, create an adder, call the add method on the adder and return the result. Where’s the fun in that? What are you actually testing? Does it really matter how the calculator does what it needs to do?

Actually, I think the above test could be a good one if it was created three days into the calculator object—when you were refactoring the different pieces of the calculator into distinct service objects.

But right now, all you need is a calculator that can add two numbers together:

[Test]
public virtual void ShouldReturnFourWhenGivenThreeAndOne()
{
    ICaclulator calculator = new Calculator();
    Assert.AreEqual(4, calculator.Add(3, 1));
}

This should be your first failing test. I don’t care how you add it, but by golly you’d better give me back 4 when I give you 3 and 1.

I love DynamicMock because I am a believer that a test should test a very specific piece of code. Recently, however, I came across this poignant counterpoint that shattered my DynamicMock utopia. I had written tests and an object that looked something like this:

[Test]
public virtual void ShouldReturnTrueIfBigIsTrueAndBadIsFalse()
{
    MockRepository mocks = new MockRepository();
    IDataWrapper mockIDataWrapper = mock.DynamicMock<IDataWrapper>();
    SetupResult.For(mockIDataWrapper.IsBig).Return(true);
    SetupResult.For(mockIDataWrapper.IsBad).Return(false);
    mocks.ReplayAll();
    IDad dad = new Dad();
    Bool result = dad.IsABigBad(mockIDataWrapper);
    mocks.VerifyAll();
    Assert.IsTrue(result);
}

[Test]
public virtual void ShouldReturnTrueIfBigIsFalseAndBadIsTrue()
{
    MockRepository mocks = new MockRepository();
    IDataWrapper mockIDataWrapper = mock.DynamicMock<IDataWrapper>();
    SetupResult.For(mockIDataWrapper.IsBig).Return(false);
    SetupResult.For(mockIDataWrapper.IsBad).Return(true);
    mocks.ReplayAll();
    IDad dad = new Dad();
    Bool result = dad.IsABigBad(mockIDataWrapper);
    mocks.VerifyAll();
    Assert.IsTrue(result);
}

[Test]
public virtual void ShouldReturnFalseIfBigIsFalseAndBadIsFalse()
{
    MockRepository mocks = new MockRepository();
    IDataWrapper mockIDataWrapper = mock.DynamicMock<IDataWrapper>();
    SetupResult.For(mockIDataWrapper.IsBig).Return(false);
    SetupResult.For(mockIDataWrapper.IsBad).Return(false);
    mocks.ReplayAll();
    IDad dad = new Dad();
    Bool result = dad.IsABigBad(mockIDataWrapper);
    mocks.VerifyAll();
    Assert.IsFalse(result);
}

public interface IDataWrapper
{
    public IsBig { get; }
    public IsBad { get; }
}

public class Dad : IDad
{
    public virtual bool IsABigBad(IDataWrapper dataWrapper)
    {
        return dataWrapper.IsBig || dataWrapper.IsBad;
    }
}

My test was green and I was happy, but my pair informed me that a bug could be introduced accidentally and no one might ever notice:

public interface IDataWrapper
{
    public IsBig { get; }
    public IsBad { get; }
    public IsFat { get; }
}

public class Dad : IDad
{
    public virtual bool IsABigBad(IDataWrapper dataWrapper)
    {
        return dataWrapper.IsBig || dataWrapper.IsBad || dataWrapper.IsFat;
    }
}

Because a DynamicMock will not throw an exception for unexpectedly calling IsFat and will return false as the default for the bool base type, my tests will all remain green. But in production my code might not work as expected.

There is seldom a single solution that works in every situation. I have learned to find the proper place for both Dynamic and Strict Mocks in my TDD toolbox and hope that this encourages you to think more deeply about your own toolbox.

Jimmy Bosse is a Senior .NET Consultant and Team Lead at Thycotic Software, an agile software consulting and product development company based in Washington DC. Secret Server is our flagship password management software product.

Pair Programming and Pandemics

June 25, 2009 1 comment

Ben Yoder the Facade Pattern

June 25th 2009 | PouyaYousefi

Pair Programming in the Time of Swine Flu

I am not a doctor. Nor do I claim to have any medical knowledge other than what I pick up from watching House. I am an “Agile Expert”, a “Test Driven Developer” and a “Pair Programmer”. That last existential statement has faced new challenges with the recent media scare and the possible pending spread of global pandemics such as the H1N1 virus, more commonly known as the “swine flu”.

Inherent to pair programming is the need for close proximity to another person. Although in the past our team has conducted remote pairing with some success, our day to day development requires that two programmers need to sit across from each other at the same pairing station sometimes for several days. Now it does not take a genius to see that this situation would be ideal for the passing and spread of communicable diseases.

Our team has taken many measures to combat the possibility of our team members getting sick. We have alcohol-based hand sanitizers at every pair station, provide alcohol wipes for cleaning the keyboards and pairing areas, and allow for working from home. We hope these measures reduce the likelihood of catching or spreading any illnesses but I believe that an inherent mental shift in thinking needs to occur in order for any measure to really work. That shift in thinking is this: “Do not come to work until you are 100% over your illness.”

I am guilty of coming to work when I feel less than stellar in order to preserve time for an upcoming vacation. Sometimes the urge to get back to work to help the team can sometimes hurt the team instead. Pushing to get back to work when your body is not at 100% can prolong your illness, make you susceptible to other illnesses, and expose others.

Kent Beck, one of the leading minds on Agile methodologies, and the author of eXtreme Programming Explained explains that one of the values of XP is respect. He states that respect is the fundamental value that binds the team and drives the project towards a unified goal. Taking care of yourself should be as important as looking out for your team. The next time you “suck it up” and drag yourself to work because you think it makes you a team player, stop and think about whether or not your staying home might be better for the team in the long run.

Pouya Yousefi is a Senior .NET Consultant at Thycotic Software, an agile software consulting and product development company based in Washington DC. Secret Server is our flagship password management software product.

From solo developer to team coder (TDD, C# and Mocks)

January 1, 2009 Leave a comment

Pair Programming

December 11th 2008 | Jonathan Cogley

On Monday, 11/24/2008 I did a presentation at the Northern Virginia SQL Server User Group. Shaking too many hands at the Microsoft TechEd tradeshow the week before in Barcelona had given me a nasty case of viral bronchitis so my voice was fading fast. If I could just keep drinking liquids and get a microphone, I would be ok.

The focus of the presentation was code – there would be no slides. The idea was to show real code being written as the Thycotic team would write it. We use Test Driven Development (TDD), Single Responsibility, Dependency Injection and Mocks to make our code single in purpose, easy to follow, and fast to test. We also practice Pair Programming so we get rapid feedback, and review during development.

A quick poll of the audience revealed few people are familiar with TDD and even fewer with Pair Programming. Surprisingly very few individuals were even in the habit of writing any unit tests for their code! The session needed to drop down a notch to make sure we didn’t lose them in the first NUnit test case using mocks. We started out slow, explaining the parts of NUnit and the structure and purpose of a unit test in a simple state-based scenario. Everyone seemed to follow along well and asked thoughtful questions. Gulp my diet coke and take off my microphone to cough…

We then moved in to the first mock-based test. The subject matter dealt with adding a tracking feature to our online store in order to track visitors during their visit and determine their path-to-purchase – a typical business value feature that is critical to marketing folk. This was real code in a real code base so it didn’t smack of academia – it also had some nice external dependencies such as the online store database, existing business objects, and the web environment to track visitors. These all made for great mocks as we isolated those responsibilities outside of the code we were writing.

We spent some time reviewing the requirements (written as a sprint-style story with “As a”, “So that” syntax and conditions of satisfaction). We had missed the essence of one requirement and had to change our test and logic accordingly. The audience once again seemed to follow along well and got the concepts at play. They were very surprised with the structure of the tests and the amount of work done to ensure that the code functioned correctly. Wheeze, cough and thanks to all.

The general sentiment at the user group was that most were getting into code from DBA positions and were looking to improve their programming skills. The techniques demonstrated were more advanced – typical of projects with large teams or multi-year development projects where quality and sustainability are essential.

If you are interested in learning more about TDD, Pair Programming or mock-based development – sign up for our new Agile Training Mailing List – we will be announcing training dates in Washington DC from January 2009 onwards.


Jonathan Cogley is the founder and CEO of Thycotic Software. Test Driven Development (TDD) is the cornerstone of the thycotic approach to software development and the company is committed to innovate TDD on the Microsoft .NET platform with new techniques and tools. Jonathan is an active member in the developer community and speaks regularly at various .NET User Groups, conferences and code camps across the US. Jonathan is recognized by Microsoft as an MVP for C# and has also been invited to join the select group of the ASPInsiders who have interactions with the product teams at Microsoft.

Do you have what it takes to be a Thycotic TDD Developer?

October 11, 2007 5 comments

thycotic Thycotic is gearing up for a new product development cycle and we are looking to grow our team of passionate test-first developers. Our team is one of the best places to learn and improve your agile development skills.

Can you solve the problem below?
http://www.thycotic.com/codetest.txt

Please submit your solution with your resume to tddjobs@thycotic.com

You willbe joining a highly capable team of .NET developers who work on consulting projects for clients and interesting products such as Secret Server.

Requirements:

  • You want to develop using Test Driven Development (that is *ALL* we do!)
  • You live, breathe, sleep, eat and drink code of the C# or VB.NET flavor
  • You enjoy or are excited about Pair Programming
  • You have a strong understanding of Object Oriented principles, the .NET Framework, ASP.NET, relational databases and web application development
  • You have the permanent legal right to work in the United States
  • You have excellent written and spoken English
  • You are able to communicate effectively with co-workers and clients/customers
  • You are willing to work in the Washington DC Metro Area

Why come to Thycotic?

  • We always practice TDD and Pair Programming
  • We are a Microsoft Gold Certified Partner
  • Your ideas and opinions will be valued
  • You will be working in the heart of Washington, DC
  • You will continually learn about new development techniques and technologies

PLEASE NO RECRUITERS, THIRD PARTIES, INDEPENDENTS OR OFFSHORE COMPANIES.

Refactoring example in C# and VB.NET

March 26, 2007 1 comment

Our very own Bryant Smith has revamped his conversion of Martin Fowler’s refactoring example (originally in Java) to nowcover both C# and VB.NET.

You can find the article here with the relevant downloads and walkthrough.

Martin Fowler’s example works nicely because it is a simple class structurethat is easy to understand. It alsohas enough complexity to allow refactorings like MoveMethod to show how data and operations should be related. I also like Bob Martin’s refactoring example on generating primes but it doesn’t have much of the OO feel since the whole thing is really just one method being broken out with little instance data. Both examples are great for debating techniques and trying out new ideas. A book filled withrefactoringpuzzles would be a great resource … anyone?

Our team has a weekly Friday morning meeting where we experiment with new techniques and ideas – we have done both of the mentioned refactoring examples by breaking our team into programming pairs and then comparing their solutions at the end. This is a lot of fun and allows the team to experiment with refactoring ideas outside of the deadline crunch. Both examples have worked well in this environment and have helped to spread adoption and familiarity of refactoring techniques across the group. Of course, everyday pairing also helps but sometimes it is nice to refactor it several different ways and then compare approaches (something a client might not be too excited about! :)) – although the learning experience is fantastic.

If you are interested in joining our team where we practice Test Driven Development, Pair Programming and Refactoring daily – we are hiring.

Jonathan Cogley is the CEO and founder of Thycotic Software, a .NET consulting company and ISV in Washington DC. Our product, Secret Server is an enterprise password management system for teams to secure their passwords. Where do you keep your passwords or do you use the samepassword everywhere?

Pair Programming improves your communication skills

March 20, 2007 4 comments

Many developers in our industry prefer a dark corner to the presentation podium. This is often explained away with references to introverted personalities and geekish tendencies. While this may be true for certain individuals, there are definitely many benefits to breaking away from this stereotype. One of the best ways to progress in the business world is to develop strong communication skills – customerswant to be understood and the combination with technical ability provides a powerful skillset when understanding problems and providing solutions. As with so many things in life,excellence in communication can be achieved through lots of practice.

Pair Programmingis the process where two developers work together on the same code with one person typing and both constantly discussing the requirements, design and code. Pair Programming alsoprovides an excellent opportunity to hone your communication skills. To be “in the zone” when pair programming requires that you continually verbalize your ideas in a way that your pair partner can follow your thinking and stay engaged.

This sounds easy, but to do it effectively requires:

  • Verbalizing raw ideas as they come into your head in a way that your pair can follow
  • Asking questions when you don’t understand
  • Focusing on someone elses way of thinking to stay engaged in their thought process
  • Moving in a methodical way so that your pair can keep up
  • Compromising on an approach to a solution and agreeing together on the next steps to take

Any periods of silence when pairing can often indicate a problem:

  • The pair is stuck and doesn’t know how to proceed
  • One or both members of the pair are distracted and are no longer engaged
  • One member of the pair is driving while the other has lost interest
  • One member of the pair is proceeding without explaining their actions to their partner (and that partner has given up asking questions)

As you can see it requires a lot of effort and mostly soft skills to bring out the best in your own technical thinking and that of your pair partner.

We value communication so highly that we practice Pair Programming wherever possible on our development team. We also encourage our team members topresent at development team meetings, user groups and code camps to further improve their communication skills. This is good for our team in that our productivity is enhanced through all the apprenticeship/cross-training and our verbal/soft-skills are enhanced daily through all the practice.

Come along to the upcoming Code Camps in the Mid-Atlantic area to see several of the Thycotic team members present and many other great speakers too.

Jonathan Cogley is the CEO and founder of Thycotic Software, a .NET consulting company and ISV in Washington DC. Our product,Secret Server, is a secure web-based solution for teams to secure their passwords. Where do you keep your passwords or do you use the samepassword everywhere?