Looking for Agile Software Developer in Central NJ

Are you a software craftsman? Do you value growing your skills as you simultaneously learn from and teach the other members of your team? Want to help us build the world’s best cross-platform mobile solutions for field service workers?

The folks that fix your A/C when it’s 100 degrees and keep your toilet from backing up into your living room deserve the best software technology can provide, and we need your help. We are looking for a key addition to our Agile/Scrum/XP team that is building a highly scalable, event-driven, mobile-enabled platform. This person will be test-driven and team-focused. He or she will be a mentor to team members new to TDD and some of the other XP practices.

Must haves:

  • At least two years of test-driven development experience with the .NET platform (C#) on a collaborative team (Scrum, CI, TDD/BDD, Paired-Programming, Collective Code Ownership, Refactoring, Iterative & Incremental Development)
  • Strong foundation in Object-Oriented Design and Programming (Design Patterns, SOLID principles, etc.)
  • Strong desire to learn and teach others

Highly valued:

  • Domain-Driven Design experience
    SOA and/or SaaS experience (especially with NServiceBus or any ESB)
  • Entity Framework Code-first or other ORM experience (especially with RavenDB, MongoDB, or other document databases)
  • Significant JavaScript experience (especially with Sencha Touch, CoffeeScript, or any JavaScript TDD/BDD framework)
  • Mobility experience (iOS, Android, or Web)

Voted as one of the Top 30 Places to Work in NJ, Marathon develops supports and sells SaaS software and marketing solutions to the SMBs in pest control, landscaping, HVAC and other service verticals. Comprehensive benefits package including vacation, insurance, and company sponsored profit sharing plan. Contact me at efarr@marathondata.com or @efarr.

TDD and the Power of Habit

“Champions don’t do extraordinary things. They do ordinary things, but they do them without thinking, too fast for the other team to react. They follow the habits they’ve learned.” –Tony Dungyimage

The quote above comes from The Power of Habit: Why We Do What We Do in Life and Business by Charles Duhigg. This book is a fascinating look at habits—what they are, how they form, how they affect us, and how can we choose our habits.

The Habit Loop

Most of us are barely aware of the habits that make up so much of what we do, but psychology and neuroscience researchers have made great progress in understanding how habits form.

image

At the core of this research is what Duhigg calls the habit loop. We usually have no trouble identifying the routine, which is what we think of as the habit itself. The value comes from identification of the two other elements of the habit loop.

The first insight comes in realizing that habits are driven by some kind of reward. The reward could be virtually anything–relief from boredom, sense of completion, etc.image As our behaviors result in the reward we seek repeatedly, our brains literally restructure themselves. Our brains move the instructions for performing the actions needed to invoke the reward to areas that can operate without our conscience thought. Our habits become become so deeply encoded that they become almost impossible to separate from who we are.

The second insight comes in recognizing that there are particular cues that trigger the routine in pursuit of the reward. Cues could be just about anything as well–a feeling of boredom, the sight of a particular object, the presence of a particular person, etc.  Identifying these cues are key to understanding and changing our habits, but you’ll have to read the book for that.

Keystone Habits

Studies have documented that families who habitually eat dinner together seem to raise children with better homework skills, higher grades, greater emotional control, and more confidence. Making your bed every morning is correlated with better productivity, a greater sense of well-being, and stronger skills at sticking with a budget. It’s not that a family meal or a tidy bed causes better grades or less frivolous spending. But somehow those initial shifts start chain reactions that help other good habits take hold. If you focus on changing or cultivating keystone habits, you can cause widespread shifts. However, identifying keystone habits is tricky. To find them, you have to know where to look. Detecting keystone habits means searching out certain characteristics. Keystone habits offer what is known within academic literature as “small wins.” They help other habits to flourish by creating new structures, and they establish cultures where change becomes contagious.

Keystone habits are the drivers that lead to other habits. For example, studies have shown that people who adopt the habit of regular exercise find that seemingly unrelated areas of their lives change for the better (being more productive at work, smoking less, being more patient with their kids, etc.).

Small Wins

Small wins are exactly what they sound like, and are part of how keystone habits create widespread changes. A huge body of research has shown that small wins have enormous power, an influence disproportionate to the accomplishments of the victories themselves. “Small wins are a steady application of a small advantage,” one Cornell professor wrote in 1984. “Once a small win has been accomplished, forces are set in motion that favor another small win.” Small wins fuel transformative changes by leveraging tiny advantages into patterns that convince people that bigger achievements are within reach.

Small wins are those sure steps in the right direction that separate high performers from everyone else.

TDD: Keystone Habit of Great Developers

image

The agile software movement centers around incremental and iterative steps with feedback mechanisms that allow for lots of small adjustments to bring the project to success. So, when I hear Duhigg talk about small wins, it resonates with what we’ve found in building software.

Test-Driven Development (TDD) is the most central of agile practices. It fits Duhigg’s definition of a keystone habit.

TDD and Small Wins

The demands on software developers get bigger and more more ambitious all the time. We presented with complex problems that we generally don’t know how to solve. It is easy to become overwhelmed by the magnitude and get bogged down trying to boil the ocean with code.

The discipline of TDD forces us to methodically break problems down into small chunks. Each passing test is a win and one small step closer to the system the customer needs.

The Cue is obvious: a customer needs a new feature.

The Routine is the well documented (but seldom practiced) red-green-refactor loop.

The Reward is the passing test and a thoroughly executed unit of responsibility completed.

The cycle continues, with small wins coming one after another until the feature is complete.

TDD as Keystone Habit

The TDD habit has many follow-on benefits beyond completed, tested software. Every time we write a test before we write the code, we remind ourselves of several truths:

  • If the software is worth creating, it is worth ensuring that it works.
  • Each unit of functionality must have a single responsibility and its dependencies must be loosely coupled.
  • Keeping the code clean is vital. Keeping it clean is made possible by the protection provided by a comprehensive suite of tests.
  • Writing only enough to make the test pass keeps our focus on the customer’s requirement and not a speculative future feature.

I’ve found a common idea emerging among the colleagues that I respect most: we would rather hire a developer that practices TDD and does not have experience in the primary programming language our shop uses than hire a developer with that programming language experience that does not practice TDD.

Language syntax and style is relatively easy to learn. TDD is a keystone habit of great software developers.

Lightweight Context/Specification BDD in C#

Behavior-Driven Development (BDD) provides all of the engineering benefits of traditional Test-Driven Development (TDD) while additionally resulting in a specification that non-developers can read and validate. At its heart, BDD transforms the tests of TDD into specifications. Those specifications are expressed in English sentences that are expressed in business value as opposed to coding or engineering terms.

The most popular structure for BDD today is called the Gherkin format and follows a Given/When/Then format, like…

Given a new bowling game
When all frames are strikes
Then the score should be 300

There are frameworks like SpecFlow to help you arrange your specifications (test) into this format. However, I find this format awkward and forced. I prefer the simpler format known as Context/Specification (aka When/Should)…

When all frames are strikes
Should have a score of 300

There are frameworks, like MSpec, that attempt to make the specifications read more like English sentences. However, I find that these frameworks get in the way as much as they help. It is also nice to be able to write readable tests with just PONU (plain old NUnit). Over time, I’ve developed a convention that I find easy to write and easy to read. I’ve also developed a tool  that turns the tests into a markdown file that can be turned into a pretty HTML report.

To show the approach at work, I present some snippets from a hypothetical order pricing system I created as a “developer test” provided by a prospective employer last summer. Here is what I was given:

Instructions: Build a system that will meet the following requirements. You may make assumptions if any requirements are ambiguous or vague but you must state the assumptions in your submission.

Overview: You will be building an order calculator that will provide tax and totals. The calculator will need to account for promotions, coupons, various tax rule, etc… You may assume that the database and data-access is already developed and may mock the data-access system. No UI elements will be built for this test.

Main Business Entities:

  • Order: A set of products purchased by a customer.
  • Product: A specific item a customer may purchase.
  • Coupon: A discount for a specific product valid for a specified date range.
  • Promotion: A business wide discount on all products valid for a specified date range.

*Not all entities are listed – you may need to create additional models to complete the system.

Business Rules:

  • Tax is calculated per state as one of the following:
    • A simple percentage of the order total.
    • A flat amount per sale.
  • Products categorized as ‘Luxury Items’ are taxed at twice the normal rate in the following states
    • FL
    • NC
    • CA
  • Tax is normally calculated after applying coupons and promotional discounts. However, in the following states, the tax must be calculated prior to applying the discount:
    • FL
    • NM
    • NV
  • In CA, military members do not pay tax.

Requirements:

Adhering to the business rules stated previously:

  • The system shall calculate the total cost of an order.
  • The system shall calculate the pre-tax cost of an order.
  • The system shall calculate the tax amount of an order.

Deliverables:

  • A .NET solution (you may choose either C# or VB) containing the source code implementing the business rules.
  • Unit tests (you may choose the unit testing framework).
  • A list of assumptions made during the implementation and a relative assessment of risk associated with those assumptions.

You can see that there are quite a few specifications here. It’s a perfect scenario for a BDD approach. Lets take a look at the specification that most states charge taxes on the discounted price, while a few states require taxes to be calculated on the original price.

Here is a specification that a standard tax state calculates taxes on the discounted price…

namespace Acme.Tests.ConcerningCoupons
{
    [TestFixture]
    public class When_coupon_is_applied_to_item_on_order_in_standard_tax_state
    {
        private Order _order;
        [TestFixtureSetUp] public void Context()
        {
            Product product = new Product(10);
            Coupon coupon = CreateCoupon.For(product).WithDiscountOf(.5m);
            _order = CreateOrder.Of(product).Apply(coupon).In(StateOf.NC);
        }

        [Test] public void Should_calculate_tax_on_discounted_price()
        {
            _order.Tax.ShouldEqual(.25m);
        }
    }
}

You can see that the test fixture class name defines the context (the when) The test method name specifies the specification (the should). The Context method sets us the context in the class name. Also note the ConcerningCoupons in the namespace. This allows us to categorize the specification.

Here is the code that specifies the prediscount tax states…

namespace Acme.Tests.ConcerningCoupons
{
    [TestFixture]
    public class When_coupon_is_applied_to_item_on_order_in_prediscount_tax_state
    {
        private Order _order;
        [TestFixtureSetUp] public void Context()
        {
            Product product = new Product(10);
            Coupon coupon = CreateCoupon.For(product).WithDiscountOf(.5m);
            _order = CreateOrder.Of(product).Apply(coupon).In(StateOf.FL);
        }

        [Test] public void Should_calculate_tax_on_full_price()
        {
            _order.Tax.ShouldEqual(.50m);
        }
    }
}

Now take a look at a section of the report generated from the tests…

orders

Anyone can now compare the generated report to the original specification to verify we hit the mark. It’s a little more work to structure your tests this way, but the benefits are worth it.

The full source for the sample and the report generator are available here.

Unit Tests Just a Happy Side Effect of Test-Driven Development

Interviewing developers has given me an interesting, although not scientific, sampling of the thinking and mindset of software developers in the Atlanta area. While there have been a few bright spots, most of what I’ve learned has been disheartening.

I have found that TDD is still only an idea that most developers have heard about but never practiced. Of the ones who have practiced it, almost none of them understand what TDD was meant to achieve and only view it as automated unit testing. I believe this is due to two factors working together derail the original intent of TDD. First, TDD was named poorly. “Test” has specific meaning and has for a long time. It naturally biases us toward a certain type of thinking (strangely enough… testing and quality assurance). Second, most developers and development organizations would rather apply a formula or recipe to what they do than to take the time and effort to deeply understand what makes software development success or failure (and all of the degrees in between).

Scott Bellware is the guy who first got me thinking about a new way to approach TDD. It started with a new name: Behavior Driven Development (BDD). I actually think the “D” should be changed to Design to complete the mind shift. In a nutshell, BDD attempts to get back to the XP view of the tests being documentation of what the code should do. In this way of thinking, the set-up code is referred to as context and the assertions are referred to as specification. It has helped reform my thinking about TDD for the better.

You can catch Scott pontificating on the subject on the latest Hanselminutes podcast. Scott doesn’t get as specific as I would have liked, but this interview shows the side of Scott that I like so much. He’s passionately advocating a valuable practice and philosophy without the insults and vitriol that he is prone to fall into. I highly recommend it.

[Update: My reference to “Scott” in the above paragraph is to Bellware–not Hanselman, who is always pleasant and rarely vitriolic.]