Department Kata: The Good and the Bad

Introduction

As a department we decided to organize a “Team learning Kata“.
We would work on the ‘Game of Life‘ which is  is a cellular automaton game. The game is a zero-player game, meaning that its evolution is determined by its initial state, requiring no further input. One interacts with the Game of Life by creating an initial configuration and observing how it evolves, or, for advanced “players,” by creating patterns with particular properties. ¹

Rules
  • Work in Mobs (with Mob Timer )
  • Team up with co-workers you do not interact/work with often
  • TDD
  • Strict Navigation
  • 2 Languages ( JavaScript & TypeScript )
  • Work for 1 hr , then rotate to new team, new language and start all over
Expected Outcome

Some of the main focus for this exercise  were:

  • Navigation
  • Team communication
  • Articulate intentions
  • Common Understanding
  • Sharing expertise

To be honest I was not excited to participate since we have done this exercise last year. But after  reviewing what we accomplished and the obstacles we had to overcome I was reminded of some practices we try to implement as a Software Department such as stop the cross talk, no estimates and communication.

Group 01

Stop the cross talk

To start, I guess we were all just excited to begin and face the problem. We all began to navigate and try to implement our own method. After 3 driver rotations we decided to stick with strict navigation, because it was confusing for the driver what to implement. We continued to discuss and ask questions as to  what the navigator  decided to implement and to keep everyone engaged.

Personally I dislike strict navigation where one person is allowed to talk and make the decisions because that is not what we do in our working mob. We discuss the issue and agree on a solution and continue with one Navigator, as we did in Group 01.

Will talk more about strict navigation later……

After we decide to implement “strict navigation”, everything went smoothly. Slow and steady, we continued working.

Estimate

When time was up, we were assigned to a new team. As I gathered my stuff I reviewed what we accomplished and what obstacles we encountered. As I moved to my new mobbing station I (forgive me Woody for I have sinned) estimated we would accomplish more in Group 02, boy was I wrong.

Group 02

Estimate Continued…..

I thought we would accomplish more in Group 02. I mean we did work on this already, we know what to do, what could possibly go wrong *in a sarcastic voice*. Well it seemed that some of our members never worked in JavaScript before and this slowed us down. We also had different ideas to handle the issue. Even though we worked on a similar (or even the same) problem, we do not know the unknowns and cannot use previous experience to estimate.

STRICT! Navigation…..Yuck

Once we settled in our new mobbing station we began to face the same problem but in a new language. I was first to navigate and decided to ask a question.

“How do we want to implement this…..”

I explained how we implemented in my previous team and also asked if they had a better way than mine. I wanted to review and get ideas from the rest of my team. But Mobber X said:

“I don’t know, your the one navigating.”

At first I wanted to explain why I wanted to review. But I was tired, it was Friday, there was only an hour left of work so I played along. So I continued with strict navigation and started to implement the same way as my previous mob.

After each rotation, the next driver always asked:

“What was your thought behind this,”

The previous navigator would explain, the new navigator would take time to understand, then (with the little time left in the rotation) continued to implement…… then repeat. We decided to add a retro into the rotation, and when the time arrived our Senior Engineer asked:

“Any comments or concerns of what we did”

And Mobber X said:

“I feel like we all have different ideas, and it is confusing to see what we are trying to implement….”

Now I’m not saying strict navigation is not helpful, there are benefits in using it such as trying to stop the cross talk (Group01) or help someone learn from other mobbers (Group02).

Since one of the main focus of this  exercise was communication, I believe using STRICT navigation (where only one person talks and make the decisions) is not the way to go. As we saw in Group 02, Mobber X  enforced STRICT navigation then had trouble to understand what the other mobbers were trying to implement.

Conclusion

This department learning session reminded of principles we practice in our department. Even though I felt like I was not going to learn anything, it made me realize why we try to implement these practices as a Software Department.

 

Express Yourself: Immutability

Immutability

The easiest way to tame side effects in C# is to enforce immutability within our custom types.

Immutable Objects: an object whose state cannot be modified after it is created

public class DateRange
{
    public DateTime Start { get; set; }
    public DateTime End { get; set; }

    public bool DateIsInRange(DateTime checkDate)
    {
        return Start.CompareTo(checkDate) <= 0 && End.CompareTo(checkDate) >= 0;
    }
}
  • Types are mutable
  • Type can be shared across multiple threads
  • Will cause problems when running in parallel

By building some locking strategy to ensure that one thread does not change the state of the type, we will avoid producing incorrect results on another thread.

Private Setters

One way to enforce immutability is by setting the Start and End property setters to private and add a constructor to set those values.

public class DateRange
{
    public DateTime Start { get; private set; }
    public DateTime End { get; private set; }

    public DateRange(DateTime start, DateTime end){
        if(start.CompareTo(end) >= 0)
            throw new Exception("End must occur after start.")
        Start = start;
        End = end;
    }

    public bool DateIsInRange(DateTime checkDate)    {
        return Start.CompareTo(checkDate) <= 0 && End.CompareTo(checkDate) >= 0;
    }
}

This makes the type immutable from outside the class; however, lets see how we can make them immutable from internal.

public class DateRange
{
    public DateTime Start { get; private set; }
    public DateTime End { get; private set; }

    public DateRange(DateTime start, DateTime end){
        if(start.CompareTo(end) >= 0)
            throw new Exception("End must occur after start.")
        Start = start;
        End = end;
    }

    public void Slide(int days){
        Start = Start.AddDays(days);
        End = End.AddDays(days);
    }

    public bool DateIsInRange(DateTime checkDate)    {
        return Start.CompareTo(checkDate) <= 0 && End.CompareTo(checkDate) >= 0;
    }
}

As you can see in the new function “Slide” we are setting Start and End values to represent new dates.

Read-Only Modifier 

To make the class truly immutable, we must replace the auto-implemented properties with explicit properties backed by read-only fields

public class DateRange
{
    private readonly DateTime _start;
    private readonly DateTime _end;

    public DateTime Start { get { return _start; } }
    public DateTime End { get { return _end; } }

    public DateRange(DateTime start, DateTime end){
        if(start.CompareTo(end) >= 0)
            throw new Exception("End must occur after start.")
        _start = start;
        _end = end;
    }

    public void Slide(int days){
        Start = Start.AddDays(days);
        End = End.AddDays(days);
    }

    public bool DateIsInRange(DateTime checkDate)    {
        return Start.CompareTo(checkDate) <= 0 && End.CompareTo(checkDate) >= 0;
    }
}

The read-only modifier on these field definitions means that we can set the field’s value only as part of the declaration or in the constructor. Setting the value anywhere else will result in a compiler error.

We set the properties in the constructor.

        _start = start;
        _end = end;

Updated the properties with explicit getters that return the backing field values

    public DateTime Start { get { return _start; } }
    public DateTime End { get { return _end; } }

By introducing and updating these properties, our “Slide” method is now broken and must be updated since we were trying to change the property values via the private setter.

public class DateRange
{
    private readonly DateTime _start;
    private readonly DateTime _end;

    public DateTime Start { get { return _start; } }
    public DateTime End { get { return _end; } }

    public DateRange(DateTime start, DateTime end){
        if(start.CompareTo(end) >= 0)
            throw new Exception("End must occur after start.")
        _start = start;
        _end = end;
    }

    public void Slide(int days){
        return new DateRange(Start.AddDays(days), End.AddDays(days));
    }

    public bool DateIsInRange(DateTime checkDate)    {
        return Start.CompareTo(checkDate) <= 0 && End.CompareTo(checkDate) >= 0;
    }
}

As you can see, we are now returning a new value rather than changing the original object’s state.

    public void Slide(int days){
        return new DateRange(Start.AddDays(days), End.AddDays(days));
    }

This makes executing the “Slide” method an expression

Alternative C# 6

    public DateTime Start { get; }
    public DateTime End { get; }

C# 6 introduced getter-only auto-properties which define the backing fields as read-only for us.

public class DateRange
{
    public DateTime Start { get; }
    public DateTime End { get; }

    public DateRange(DateTime start, DateTime end){
        if(start.CompareTo(end) >= 0)
            throw new Exception("End must occur after start.")
        Start = start;
        End = end;
    }

    public void Slide(int days){
        return new DateRange(Start.AddDays(days), End.AddDays(days));
    }

    public bool DateIsInRange(DateTime checkDate)    {
        return Start.CompareTo(checkDate) <= 0 && End.CompareTo(checkDate) >= 0;
    }
}

As you can see, we do not need all those read-only backing fields and explicit properties anymore.

 

<-  What is Functional Programming

What is Functional Programming

OO vs Fp

“No matter what language you work in, programming in a functional style provides benefit. you should do it whenever it is convenient, and you should think hard about the decision when it isn’t convenient.”
– John Carmack

When you apply the basic functional principles to your software, your resulting product will be more predictable, reliable and maintainable.

Clean Code: Chapter03 – Functions

  • Keep functions small
  • Don’t repeat yourself
  • One job
  • Avoid side-effects
  • 3 parameters max

OO makes code understandable by encapsulating moving parts. FP makes code understandable by minimizing moving parts.

— Michael Feathers (@mfeathers) November 3, 2010

Both Object Orientation and Functional Programming try to solve the same problem, but take very different approaches. Object Orientation tries to manage the ever changing state of a system, while Functional Programming is trying to avoid that state altogether.

The main difference between Object Orientation and Functional Programming is how you compose your application.

Defining FP

Functional programming is a paradigm which concentrates on computing results rather than on performing actions.

-Dave Fancher

Central Themes of Functional Programming

1. Tamed Side Effects

Side effect in programming is anything that happens to the state of a system resulting of invoking a function.

Language Purity
Purely Functional Impure
Guarantees (except in certain limited cases) that functions do not have side effects No guarantee about functions and side effects
Functions always behave the same way regardless of the external state of the system
This allows parallel or asynchronous execution
2. Emphasizing Expressions

Everything produces a result

Statements vs Expressions

Statements Expressions
Define actions Produces Results
Executed for their side effects Execute for their results
var posAndNeg;
if(value > 0)
     posAndNeg = 'positive';
else
     posAndNeg = 'negative';
var posAndNeg = 
     value > 0
          ? 'positive'
          : 'negative';
  • Functional Programming is usually shorter.
  • We do not have unassigned variable
  • Fp tend to be more testable
3. Treat Functions as Data

Higher Order Functions

  • Functions which accept other Functions
  • Functions which return a Function

LINQ example

myList
     .Where(x => x % 2 == 0)
     .OrderBy( x => x);

 

Pros Cons
Produces Results More Memory Allocation
Does not alter the original Source
Allows Asynchronous Runs

 

 

Express Yourself: Immutability  ->

Manifesto for Rocket League

For my lightning talk I decided to make a parody of the “Manifesto for Agile Software Development”

Altering the 4 values to help my colleagues “Git Good in Rocket League

previous arrow
next arrow
Slider

 

Download PowerPoint

Database Unit Testing + Continuous Integration

Problem:
In the current mob I work in, we deal with an application that contains complex logic in the database (i.e. Business Rules). When bugs appear we first take time to understand its logic and why this scenario caused it to misbehave. After applying a fix, we test the new logic against the scenario that brought up this bug. Although this may fix the initial problem, we are unaware if this new change has broken anything else.

For example, we optimized a Stored Procedure that determined how many transactions it takes to balance out a redemption and mark those transactions as ‘used’. Originally it used a cursor to loop around each transaction until it reached the redemption amount. But this took minutes (especially for big customers redeeming large amounts) and would timeout, so we optimized. We brought it down from minutes to seconds, a major improvement. Everything seemed fine until months later we noticed an edge case that caused the Stored Procedure to not mark these transactions as ‘used’. Fixing these accounts took a couple of days and this was where we decided, we need Database Unit Testing.

tSQLt:
What is tSQLt? tSQLt is an open source database unit test framework for Microsoft SQL Servers. This framework allows you to implement unit tests in T-SQL. Some major features that tSQLt has are:
1. Tests are wrapped in transactions: independent and reduces cleanup
2. Tests can be grouped within schema: allows you to organize your tests
3. Ability to fake tables and views and to create stored procedure spies: removing constraints and dependencies.

How to Install tSqlt:
1. Download and extract the zip folder
2. Execute SetClrEnabled.sql file on database
3. Execute tSQLt.class.sql file on database
4. Done!

I won’t go into much details about tSQLt here, but there are many resources available. This post is mainly about how we integrated automated Database Unit Tests into our Continuous Integration.

Learn more about tSQLt:
Homepage
Pluralsight
YouTube

Using DB unit tests with Continuous Integration:
We use ThoughtWorks GOCD as our Continuous Integration and Delivery service. We had to figure out a way to implement Database Unit Tests in our application’s pipeline, and it came up with the following steps:
1. Install tSQLt to Database
2. Install Tests (checked into Source Control, 1 script file per StoredProc/Function/View)
3. Run tests

Since the tSQLt framework and tests are just scripts that we need to execute on the database, we created a PowerShell script that goes into a folder and executes all .sql files into the database. Below is the PowerShell Script we developed:

Download file – ImportScripts

We saved the PowerShell script in a shared location that can be reached from any of our agents. Setting up a task for steps 1 and 2 can be done with the format seen from the image above.

Now that the tSQLt framework and db unit tests are in the database you must execute them by running the stored procedure tSQLt.RunAll. Below is another script we created to run a stored procedure from a database

Download File – RunStoredProcedure

Conclusion:
Now that we have Database unit tests integrated in our CI pipeline, whenever a change is required to this complex database we always include unit tests. This gives us the confidence to make changes and have instant feedback that we did not break any expected behavior. When fixing a bug and adding unit tests we can make sure this bug never gets back into our code.

Thanks Dexter!

Hello World!

My name is Jonathan Cruz, I graduated from California State University of  San Marcos in May 2016 with a bachelors in Computer Science.I have always been interested and curious about technology,
and fascinated of its rapid growth in becoming part of everyone’s life. Freshman year of college, I was unsure what to major in: it was between Math, Business, or Computer Science. So I took classes for all of them and at the end I decided to continue with Computer Science and I’m glad I did.

Joining the Mob!

“Nice application you got here. Be a shame if any thing happened to it”

While I was applying for my first job, I came across an Eventbrite Workshop for Mob Programming by Woody Zuil. I was interested in learning but most importantly, were they hiring? After the workshop I spoke with Chris Lucian, Director of Software Development and he mentioned there was an opening for an Associative Software Engineer. I applied, studied all the materials HR sent me, had my interview and got the job 🙂

Working at Hunter Industries as a Mob Programmer for my first job has been amazing. Being able to Mob with Senior Engineers, being involved in learning sessions, going to conferences and working in a great work environment……. I couldn’t ask for more.