Mob Programming: Moving from a Multi-Mob Project to a Single Mob Project and the Sense of Accomplishment

I just hit my one year anniversary at my organization as a mob programming software engineer. I wanted to share one of the experiences I have had over the course of that year.

My first 9 months at Hunter I worked with the same team. The team consisted of eight developers. This team generally had two mobs going. So, I would be switching mobs on roughly a weekly basis. This meant I was changing tasks being worked on and not always seeing tasks to completion since I would switch to the second mob. This all sounds great sharing knowledge and changing mobs being worked with.

The big change came in February. I changed projects. I moved to a team of just three developers including me, so a much smaller team. With just three developers this means we are a single mob all the time, every day. The biggest difference is no more switching between mobs, no more switching between tasks. I am seeing all our tasks from start to finish. It might seem difficult to work with the same two other people every day but honestly, they are great!

This no more switching of mobs, no more switching of tasks has led me to have a much greater sense of accomplishment when it comes to programming. Something I have heard from more than one developer has been their feelings of lack of accomplishment. They think they are just a tiny piece of a much larger project. Or simply the fact that they cannot physically see or hold their project makes them feel less accomplished. Putting your code on a flash drive and waving it around saying, “look at what I made”, is not all that fulfilling.

The fact that all three of us on the team work together always, all three of us complete tasks to the end together, and all three of us struggle through the hard problems makes for a strong accomplished team.

Numerous times while working on my old team of eight, one mob would be struggling on a challenging problem while the other was working on a different problem less challenging. One mob would be having a bad day trudging through a problem while the other was moving forward at a normal pace. The pain was not always shared but due to having two mobs it could not be shared, that is just how it was.

Now, it is never fun to have painful programming days but at least if the whole team shares the pain it can be more of a team building experience rather than team dividing. When a problem is solved by the whole team together a greater sense of ability is shared and most importantly if the same problem comes up again later we can crush it!

I mentioned above the task switching problem and that was a major hindrance to the feeling of accomplishment. At times, I would be working on a problem all week and just when we were about to get to the light at the end of the tunnel I would switch mobs. I felt almost robbed of the accomplishment. I know I was a major player in the completion of the task, but damn, it hurt just a little to be taken away before seeing it to the end.

Do not get me wrong, one of the strongest points of mob programming is the switching of mobs within a team to ensure no knowledge silos are formed. But it is important to see the other impacts that switching teams has. I felt somewhat cheated of getting to complete something I had worked a long time on, but also I felt I lost some learning because I did not get to participate in the final steps to solving the problem.

Overall on my new smaller team, I feel more accomplished. I am seeing all our tasks to completion, I am struggling through the difficult parts altogether as a team, and I get the fullest sense of learning because I was not taken away at any point from the problem. Again, I had plenty of feelings of accomplishment and achievement while on the larger mob, but now I get to experience every accomplishment and achievement with the smaller team.

Expect more post and experience reports about switching from a large mob to small.

Programming Better and Easier With The Happy Path

When I start down a new solution or looking at how to solve a problem one of the first things to jump into my head are all the crazy edge cases that may or may not ever occur. I see it as a blessing in disguise because, in the long run, it helps out tons to be able to think about the crazy things a user may do. But when just trying to get a proof of concept together it can make the work that much more daunting.

When putting together a proof of concept stick with the happy path. Hard code values, expect perfect reproducible input, and for the proof of concept even lower the security levels a bit. Make sure if using lowered security settings you are in some sort of development environment. Do not go lowering your security on production.

But the key is to make it as easy on yourself as possible. What if you took the happy path and find out your solution did not even work anyway? You do not want to have wasted your time making your ability to accept input the most robust known the man if your strategy to submit the code is

A more real world time when the happy path saved me much time and effort was when the team and I at work were attempting to setup up a cloud solution using AWS. We had a couple different strategies in our minds as to how to build out our cloud solution. It involved security, databases, IoT, Lambda functions. It was going to be an extensive cloud system.

First thing we did was throw security out the door. We knew it needed to be done but would only complicate things. We did not set up a database because again takes time and we had a lot of database knowledge on our team so that did not pose too much of a risk. We just hard coded the data we would receive back when we did end up making the database.

Now we could take a look at the happy path for our proof of concept. Perfect user input, interaction, no confusing security. We found that our first model would not scale well so we threw it out the door. Our second model was not easily supported due to library limitations imposed on us. Our third solution found a happy medium of ability to scale, performance, and ease of implementation. This all did not happen overnight it actually took a few weeks. But imagine if we had added the extra complexity of security or the database. It would have taken months.

Taking the happy path saved us time and frustration. The process of making application development as easy for you as possible. Ignore the edge cases, ignore security, hard code values. Made us more productive and let us explore multiple solution strategies in a shorter amount of time.

 

How to test your EventWaitHandle C#

What is EventWaitHandle

“The EventWaitHandle class allows threads to communicate with each other by signaling and by waiting for signals.”

Problem faced

How do I go about testing an EventWaitHandle. Events are being published threads are flying around the application and I want to test my WaitOn() and Set() calls on my EventWaitHandle.

Why I am using EventWaitHandle

I have a function that displays user data, let’s call it DisplayUserData. But I need to make sure I have all the latest customer data before presenting it. I publish an Event that makes API calls in order to gather all the user data, called GetUserDataEvent, in the beginning of DisplayUserData. I need to make sure that my GetUserDataEvent has fully completed before displaying any data. I have a GetUserDataEventCompleted that I am waiting for. EventWaitHandle is the solution I have to pause inside of DisplayUserData until GetUserDataEventCompleted has been received. Below is a simple sample of what I have currently going on in my code, that needs to be tested.

How to test your EventWaitHandle

Now how can I test this? How can I ensure that the code WaitOne() is working and code is not attempting to access user data before the Set() is called? We will use some threading in our test!

We will put our function call on its own thread. This allows the GetUserDataEvent.Publish() and the WaitForUserData.WaitOne() to occur on their own thread. Our test code can continue and verify what is happening.

Directly after the call to start our thread we want to assert or verify that our code for displaying user data is not being called. This can be tested in a couple ways. It is up to you. But for me, I had a mock of my DisplayUserData and was able to verify that it had not been called yet. For a less advanced approach, you can set input a thread delay and ensure that certain values are still null. Such that they have not been populated with the user data yet.

After we have verified our display code has not been called we can populate our user data with simple test data. This is where the mock comes in because since I had mocked out my actually API call no data was coming back. I simply need to input my own test data. I am not trying to test my API calls at this time I have other tests for that, I only want to be testing my EventWaitHandle.

With our test user data generated we can call, GetUserDataEventCompleted. The subscription for this event calls our WaitForUserData.Set().  We expect that once the Set() is called our Display for the user data will be called once. Below is a layout of our entire test created for EventWaitHandle. This now tests that the Display call on user data does not occur until we explicitly get our Set call on WaitForUserData.

The above works due to mocking using moq library. If you are not familiar with mocking I highly encourage you to look into tutorials on how to use the differen mocking libraries available to you.

For help writing your own EventWaitHandle test leave a comment!