Posts Tagged ‘Development’

Software Developer and Evolution Conference 2010

August 20, 2010 Comments off

Looks like this October i’ll be making my way east out to Winnipeg where I have the opportunity to present two sessions at the Software Developer and Evolution Conference.  I’m very excited as not only will this be my second conference of the year that i’m presenting at, it’s also going to be my first time in Winnipeg.  If you know of any fun family things to check out in Winnipeg please leave a comment!

My first session is about self organizing teams, participating on and leading.  There’s a lot of things to think about when it comes to creating and fostering self organizing teams.  I plan to talk about some of them from the perspective of a manager and leader, as well as a team member on the team.  I’m also coming up with a good exercise that I hope will be fun and help illustrate my points.

The second session will be on iterative development.  I did this session at the Prairie Developer Conference in Regina, and i’ve used the feedback I received from the attendees there to refine the presentation to hopefully be even better, and i’m also incorporating an exercise in to this one as well.

I’ll probably be making more posts on those two topics in the coming weeks, so check back for more.


Django’s assertRedirects little gotcha

April 23, 2010 1 comment

Something we’ve be trying to pay more attention to with our newest green field development projects is the running time of our unit test suites.  One of the projects was running ~200 unit tests in 2 seconds.  As development continued and the test case number grew, it started taking 10 seconds, then over 30 seconds. Something wasn’t right.

First challenge was to determine which were the slow running tests.  A little googling found this useful patch to the python code base.  Since we are using python 2.5 and virtual environments we decided to simply monkey patch it.  This makes verbosity level 2 spit out the run time for each test.  We then went one step further and made the following code change to _TextTestResult.addSuccess:

    def addSuccess(self, test):
        TestResult.addSuccess(self, test)
        if self.runTime > 0.1:
  "\nWarning: %s runs slow [%.3fs]" % (self.getDescription(test), self.runTime))
        if self.showAll:
  "[%.3fs] ok" % (self.runTime))
        elif self.dots:

With it now easy to tell which were our slow tests we set out to make them all fast again. As expected the majority of the cases were an external service not being mocked correctly. Most of these were easily solved. But there were a few tests where we couldn’t find what hadn’t been mocked. Adding a few timing statements within these tests revealed the culprit. The Django frameworks assertRedirects method.

    def assertRedirects(self, response, expected_url, status_code=302,
                        target_status_code=200, host=None):
        """Asserts that a response redirected to a specific URL, and that the
        redirect URL can be loaded.

        Note that assertRedirects won't work for external links since it uses
        TestClient to do a request.
        if hasattr(response, 'redirect_chain'):
            # The request was a followed redirect
            self.failUnless(len(response.redirect_chain) > 0,
                ("Response didn't redirect as expected: Response code was %d"
                " (expected %d)" % (response.status_code, status_code)))

            self.assertEqual(response.redirect_chain[0][1], status_code,
                ("Initial response didn't redirect as expected: Response code was %d"
                 " (expected %d)" % (response.redirect_chain[0][1], status_code)))

            url, status_code = response.redirect_chain[-1]

            self.assertEqual(response.status_code, target_status_code,
                ("Response didn't redirect as expected: Final Response code was %d"
                " (expected %d)" % (response.status_code, target_status_code)))

            # Not a followed redirect
            self.assertEqual(response.status_code, status_code,
                ("Response didn't redirect as expected: Response code was %d"
                 " (expected %d)" % (response.status_code, status_code)))

            url = response['Location']
            scheme, netloc, path, query, fragment = urlsplit(url)

            redirect_response = response.client.get(path, QueryDict(query))

            # Get the redirection page, using the same client that was used
            # to obtain the original response.
            self.assertEqual(redirect_response.status_code, target_status_code,
                ("Couldn't retrieve redirection page '%s': response code was %d"
                 " (expected %d)") %
                     (path, redirect_response.status_code, target_status_code))

        e_scheme, e_netloc, e_path, e_query, e_fragment = urlsplit(expected_url)
        if not (e_scheme or e_netloc):
            expected_url = urlunsplit(('http', host or 'testserver', e_path,
                e_query, e_fragment))

        self.assertEqual(url, expected_url,
            "Response redirected to '%s', expected '%s'" % (url, expected_url))

You’ll notice that if your get request uses the follow=False option you’ll end up at line 34 in this code snippet which will kindly check to make sure the page you are redirecting to returns a 200. Which is great, unless you don’t have the correct mocks for that page setup too. Mocking out the content for a page you aren’t actually testing also didn’t seem quite right. We didn’t care about the other page loading, it had it’s own test cases. We just wanted to make sure the page under test was redirecting to where we expected. Simple solution, write our own assertRedirects method.

def assertRedirectsNoFollow(self, response, expected_url):
    self.assertEqual(response._headers['location'], ('Location', settings.TESTSERVER + expected_url))
    self.assertEqual(response.status_code, 302)

Back to a 2 second unit test run time and all is right with the world again.

Dustin Bartlett

The Concept of Feature Fidelity

February 25, 2010 Comments off

When we’re building software, we often have a desire to deliver something that will blow people away.  It makes sense right?  Why would we want to deliver something that isn’t impressive, doesn’t work all that well, doesn’t look really pretty etc.

Well, it just so happens that there’s a good reason you’d want to do that, because it still delivers value, even in it’s often simple and unrefined form. 

Consider this scenario, a client comes to you and asks you to build them a chair for their office.  They want it to roll around, comfortable, adjustable height, nice arm rests etc, and they want it as quickly as possible because they don’t have a chair at all now.

Using the typical mentality of not delivering anything until you think it will blow people away, you go away and over the course of a month you build a fabulous office chair.  You showed some pictures of it along the way to the client and they were pleased with the design, however they really wished they could have been sitting down at their desk while they looked at your designs…

The concept of fidelity is simply to deliver the simplest thing that provides value as soon as possible, and the move on to refine it.  Using the chair example, the client wants a fancy chair, but the client also currently has NO chair, so obviously just having anything to sit on provides SOME value.  Thinking in this way, the lowest fidelity solution that will deliver some value to the client might look something like this:

milk crate

The client will obviously not be satisfied with a milk crate as the final product but it isn’t the final product, it’s the first iteration of the final solution.  You would tell the client something along the lines of “here’s what we came up with in the first day, turn this upside down and it will allow you to sit at your desk, we’ll be back in a few days with an improved version for you.  A couple days later you return with:

chairYou tell the client that it’s a little more comfortable than the last delivery, and looks better as well.  You will further refine the chair and be back in another week.  After a week you come back in with:

swivel chair The client takes a look at what you’ve delivered, sits in it, the padded chair is comfortable, it looks stylish, and they tell you this is my chair, this is what i want, don’t make any more changes.

So, what are the main differences here?  The client ended up with an end product they were happy with in both cases right?  The second method had a couple key benefits though.  First of all, the client had results in hand and was able to use them (start sitting down) the next day, instead of having to wait for a month.  Also because the team was delivering improvements regularly the client had many opportunities to suggest how they would like things changed.  Finally, the client has the opportunity to stop the development of the product early for any reason and still be left with a usable product!  So whether it turns out that the client is happy with less than they originally asked like in my example, or if the client just ran out of money and had to stop early, they are always left with something usable.

You could make the argument that this is just iterative development, and technically you are correct, however it’s important to remember the fidelity aspect which is that each iteration should provide a usable product that provides value.  Consider another way to iteratively deliver a chair to the customer.  In the first iteration you deliver fully refined wheels, in the second you deliver the adjustable chair post, in the third you deliver nice leather wrapped arm wrests, in the fourth a nice padded leather seat, in the fifth a nice leather chair back, and in the sixth you put it all together.  That’s iterative right?  You produced and delivered a piece of the product in each iteration and showed it to the client.  The problem is that you weren’t delivering any value with each iteration.  The customer doesn’t realize any value until the last iteration when you put it all together, which means if the project had to be stopped early, the client is left with nothing useful.  Even worse, the customer can’t see how everything is going to work together until you put it all together for them, so they don’t have much ability to give feedback on your work.

Always deliver in iterations that provide value to the client, so they are left with something useful that provides value no matter how deep in to the project you are.

by: Chris Dagenais

Iterative Development – An Introduction

February 5, 2010 Comments off

Iterative development is a pretty basic concept.  You just develop iteratively…  Hmm pretty sure i read once that you shouldn’t use the word you’re defining in the definition.  Lets try again.

Iterative development is the practice of developing software in small defined chunks of time.   This is in contrast with the old-school method of starting a project and working on it over the course of months or years in one long chunk, or iteration.

Lets just dig in to the meat of why it’s important.  Imagine you wanted to get a house built.  You line up a contractor who has experience building houses.  You tell him you want a 1200sq ft house with lots of windows and a double garage.  He asks you what layout you want, where should the windows be, do you want a deck, what colors for the interior and exterior etc.  You answer him by saying “I don’t know, I hired you because you’re good at building houses, so you just make sure it’s 1200sq ft and has lots of windows”.  Can you see where this is going?

Six months later he calls you and says the house is done.  You walk in and while the house is impressive, it’s not how you had envisioned it, and with the amount you are paying him, you want it to look how you want.  Unfortunately now that all the work is already done, it will cost a LOT more to make changes.

Software is the same way, if somebody comes and says to you “I want a system that does X” but they don’t have any details as to how it should look or work, it would be foolhardy to believe that they are going to just be happy with whatever you deliver to them.

Iterative development helps with this by allowing you to break up the project in to small iterations, the smaller the better, ideally 1 or 2 weeks.  This way you can show what you have accomplished during each iteration to the customer and see what they think, and get their feedback on what they would like changed.  Even if they customer had no idea what they wanted ahead of time, you can bet that they will after they see what you have built.  The sooner you get that feedback from them, the cheaper it will be to ensure the project turns out how they want.

One of the other big advantages of dividing work up in to short iterations is that it’s a lot easier to estimate what you can get done in 2 weeks than in 2 months.  Once you have the project divided up in those iterations it also becomes a lot easier to see if you’re falling behind or not as well.

That should give you a basic idea of some of the advantage iterative development provides.  I’ll go in to more detail in future posts of some of the other advantages.

by: Chris Dagenais

The Agile Game

December 3, 2009 Comments off

Dr. Stuart Brown, founder of the National Institute of Play, believes that the act of play is essential to human development and intelligence. After watching one of his TED talks, Play is more than fun, I was inspired to look into games an agile team can play during a regular sprint. After all, it seems pretty straight forward that human development and intelligence are valuable aspects of a software developer’s career. So I hit up Google for what it could tell me about agile games, and found a bunch of balloon toting, crazy string wielding fun games I could play with my development team. I envisioned my team’s reaction to the introduction of these wild games:

1. Get a bunch of awkward looks.
2. Make a fool of myself to help lead the way
3. Get a few giggles playing the game
4. Try to come up with a different crazy game the following sprint

To me this seemed like a lot of effort for a little flash-in-the-pan fun. I decided I wanted to focus more on games we could play that would infuse themselves into our work stream — Heck, let’s just make our work a game! First let’s discuss what makes a game fun. Games are scenarios where you have a goal to reach while operating within established rules, boundaries and limitations. What makes the game fun is having the freedom to choose different paths toward the goal, being able to use your skills to achieve smaller goals along the way, and to reap the rewards for achieving the goal.

We already have plenty of rules, boundaries and limitations in our workplaces, but let’s talk more specifically to agile software development. I am talking about story breakdown, story estimating, spiking, definition of done for a story, coding standards, pair programming, TDD, stakeholder satisfaction, etc. Once the rulebook is well understood by your team you must give them time to play the game. YOUR ATTENTION PLEASE: the players need uninterrupted blocks of time where they get to play by the rules and innovate a solution. Don’t be afraid, these blocks are measured in hours, not days. Do what you need to do to provide the players with at least 75% of their day as uninterrupted game time (the more the better). If you need meetings with them make sure you consider the following:

1. Do you NEED the meeting?
2. Does everyone need to attend?
3. Can the meeting occur at the edge of a break (start/end of day, right before/after lunch)?

As a Team Lead your job is part referee and part coach. Encourage healthy demonstrations of play and discourage improper play. Help remove problems which affect their ability to play, and celebrate their victories while helping them learn from their defeats.

And finally, a word to the wise – break down your stories into small enough pieces that they can be achieved in no more than 2 work days. Having those frequent moments of accomplishment makes every game more enjoyable.

Logan Peters

Aligning Purpose

October 14, 2009 Comments off

In August I was fortunate enough to attend the Agile 2009 conference.  I saw two excellent sessions presented by Pollyanna Pixton.  I later found out that four other sessions (attended by Tefon) included recommendations of the book Stand Back and Deliver, authored by Pollyanna and 3 of her colleagues.  These presenters were so convincing Tefon even purchased the book while still at the conference.  It was a good read, but the chapter on the “Purpose Alignment Model” was by far my favorite.

The Purpose Alignment Model is a simple tool designed to do exactly that – facilitate an alignment of purposes.  The underlying premise is all product features or development that a company performs can be placed on two scales:  how critical and how differentiating they are to the operation or success of the company.  With everything placed on these scales, they can then be combined into a graph.

Purpose Alignment Model

Purpose Alignment Model

This simple graph can make discussion about any number of product features or work processes significantly easier and more effective.  When discussion about a feature starts by first placing it on the graph above, it is placed sharply into perspective.

What constitutes a mission critical differentiating feature?  One simple method for determining this is to ask ‘Could this feature be the center of an advertising campaign for the product?’  These features are the driving force to a product’s adoption and define the identity of the company.  If every feature gets a ‘yes’ answer to this question the model is being used wrong.  Trying to differentiate with every feature will result in little more than a mediocre product.  A select few features should be placed in the ‘Invest’ quadrant and these are the features that, naturally, should receive heavy investment.  If these features aren’t the most polished and solid in the product, get to work.

If an honest assessment of everything about a product is completed with this model, the majority of what might initially have been placed in the investment quadrant will end up falling into the parity quadrant.  The parity quadrant is interesting.  Most of a product’s features will invariably not be differentiating, so why waste resources trying to develop them?  These features are mission critical, make no mistake about it, they have to work and they have to work well.  Parity features will drive the sticking power of an application, thus it is still critical to get them right.  The key point, however, is that parity features only need to reach parity.  No wheel reinventing required.  Parity features aren’t innovative.  Look at what the market is doing.  What is the accepted best practice?  Do that and nothing more.

If a feature is differentiating but not critical to the success of the business, find a partner.  Don’t waste resources that could be spent getting parity features to parity and investing in mission critical differentiating features.  Find a partner who is investing in the feature and use them.

If a feature is not mission critical and not differentiating, who cares? If a feature in this quadrant is being worked on, ask why.

If every feature to be worked on is placed properly relative to each other on this graph the result is an amazingly powerful communication tool.  Suddenly everyone from the CEO to the developer implementing the feature can easily be on the exact same page.  With an aligned purpose across the whole team, from executive to business to development to IT, more time is spent making a profit and less time debating about how to make a profit.

By: Dustin Bartlett

What happened to building race cars?

October 5, 2009 Comments off

When my older brother was a young man his fantasy was to be a part of a great team building cutting edge race cars. His passion led him to spend countless hours on his own figuring out how an internal combustion engine works, how well-tuned suspension helps keep power to the ground, and why one transmission was better than another. He got his foot in the door at the local garage and began his career as a mechanic. Today he is a very successful, respected and knowledgeable mechanic at a different local garage. I am very proud of him and the skills he has acquired over the years. But what happened to building race cars?

At his garage my brother had all the tools he needed plus skilled co-workers.  What stopped him from building his race car?  Whenever my brother wanted to work on something new, innovative, and generally cool he would have to wait until after work hours or the weekend.  Young and energetic he would complete his work day and dive into his own pursuits.  Sometimes he was even able to get co-workers to stay with him and try something he could not do alone.  This lasted for a while but as time went on he could not afford to invest the hours his creative mind was asking of him.  At the end of the day he would be exhausted and ill-suited to pour creative energy into his projects.

In the agile software development environment I currently work in I am surrounded by seasoned professionals, inexperienced raw talent, and everything in-between.  I am proud to be a part of a company that values professional development time as discussed in Hemant Naidu‘s post, A Vivid Imagination Isn’t Just for Kids.  In doing this we acknowledge how important creativity and innovation is to the growth and success of our company.

In an effort to provide momentum to the professional development time the development leads have asked our developers to get together with no manager participation.  They have been tasked with using their professional development time to work together on the major hurdles affecting development across all teams.  It is our hope that leaders will rise, tribes will form, and developers will learn to work together on their own initiatives.  As a developer, expect from us the creative freedom to try, and from yourself the courage to fail.

By Logan Peters