Legacy Dependency Kata v2.0

Well, well, well. Look what the samurai dragged in. An updated version of my Legacy Dependency Kata. I’ll have to update the Coding Kata Resources page.

50795_01_kurosawas-classic-seven-samurai-gets-stunning-4k-remaster

I’m not proud to admit that there even was a v1.0 at the moment. Let me explain.

Just over two years ago, I was experimenting with writing katas, presenting at code conventions, and running a coding dojo. It turns out. I wasn’t super fantastic at any of these things. Nevertheless, I wrote a kata, ran it a few times with the kind folks in my dojo, and proceeded to share it with the delightful folks at Utah Code Camp 2014. Reviews were mixed, but overall I felt good about it.

Fast forward to the present. While planning the lunchtime learning schedule for our recent SAFe Program Increment, there was an opening, and I, ever so graciously, decided to run my Legacy Dependency Kata for folks who may not have had the chance to see it before. Upon thoroughly embarrassing myself with some of the crappiest kata slides in existence (slides even I couldn’t completely fathom), I recognized that my life would be forfeit if folks were forced to do the kata again with the same slides the following day.

I dashed to revise the slides and spent many hours on the task. When I presented the kata on the second day, it was a much more successful attempt. I’d go so far as to call it a version 1.7. I spent some more time and enlisted the advice of the ever-gracious and capable Kaleb Pedersen in finalizing v2.0. The source code is still the same. Legacy code problems from 2 years ago are still very similar to what they are today.

coughnounittestabilitycough

I think the new slides do their job. Could this kata still be better? Without a doubt. Please submit your recommendations in the comments or feel free to yell at me on Twitter. I’m sure I deserve it for something.

Without further adieu, I give you Legacy Dependency Kata Version Two.

Seed code is still on GitHub:
https://github.com/KatasForLegacyCode/kCSharp/releases/tag/Step0

Lean Teatime Is Both More And Less Than Lean Coffee

Ok, I’m going to share this like no one has ever thought of it before.

braceYourselvesMeme

The other day, I was giving a lightning talk at Utah Software Craftsmanship about how I run bi-weekly team meetings with Lean Coffee. In short, I highly recommend the practice. It helps keep our meetings quick and on-task. Succinct really.

People seem to like it because we discuss the most important things, and we usually finish early.

If you aren’t allowing your meetings to end on time or early– use this opportunity to rethink your life. You don’t want to sell anyone death-sticks.

Back to the lightning talk. I spoke for about three of my five allotted minutes and opened up the floor for questions. There were a few, but the most interesting question by far (paraphrased) was this:

How do you get people to arrive at desisions when running a meeting with Lean Coffee?

The query took me by surprise.

For a moment, I considered decisions that came out of our meetings. Granted, there weren’t a ton. Often these sessions are more informational. Sometimes they result in questions I don’t have an answer to, so I take to-do items and communicate back to the team later.

However, we did reach decisions. We planned a team party, for example. For these types of situations, I looked for a majority consensus. Often, we found ourselves using a technique I will now dub “Lean Teatime”.

6808987192_cb44303a47_z

Lean Teatime

Lean Teatime is a subset of Lean Coffee. It can be run either in the middle of a lean coffee session, or completely separate from it. The gist is simple:

  1. Set expectations by making clear the intent of the Lean Tea session (e.g. selecting a venue for a team party).
  2. Make sure everyone has access to Post-It notes and Sharpies (the tools of any agile facilitator).
  3. Set a timer (2-5 minutes) and have the group come up with as many ideas as possible. They will write each thought on an individual Post-It.
  4. Organize similar items into groups and stick them to a desk (or wall for bigger groups).
  5. Give everyone groups/3 dot votes and turn them loose to place dots on the item groups they prefer. Allow one dot per group or multiple, your choice (I prefer 1 per).
  6. Order the results from most votes to least. In the event of a tie for first, vote one more time with the two tied items only.
  7. I like to do a fist of five at this point to see if anyone just hates the thing that ended up on top. In this case, I’ll ask the group to offer mitigation suggestions.

All of this only takes a few minutes and usually has a positive result.

So there you have it. The “genesis” of Lean Teatime. I hope you find it useful.

If you enjoyed the article, hit me up on Twitter or leave a comment below.
If you disliked the article, hit me up on Twitter or leave a comment below.

The Pursuit of Simplicity

Recently I read Seven Brief Lessons on Physics by Carlo Roveli. True to its title, the book is brief, and clocks in at a scant eighty-one pages. Its beauty is in the nearly poetic brevity and the expressive nature of the word choices the author (and translators) use. Unlike massive scientific tomes on particle physics I once attempted to read as a 12-year-old boy, Roveli’s book is written in a way I could have understood even as a young boy.

The book brought me a remembrance of the elasticity of young minds with its references to young physicists like Einstein, and his solving massive problems with simple solutions at a very young age. The book inspired me to write, and this is the result.

Fractal_tree_bbc

Anecdote Time

When I was a first-grade elementary school student, I recall having a tough time memorizing multiplication tables as students were taught to do at the time. Ever precocious, I wanted there to be some rhyme or reason, a pattern even, to the way we determined the values of these simple mathematical expressions. No, I was told, you just have to add the number you are multiplying by to itself the number of times the multiplier expresses.

For a young, and frankly lazy, Willy Munn, this was an annoyance at best for a number like one, two, and three; and completely unbearable for the silly number nine. You see, not being able to use a calculator or a multiplication table, and being required to show my work meant writing out nine addition problems just to “show my work” and get an acceptable grade.

My young brain started looking for a better way. It wanted to enable the laziness my heart so desired. It wanted to find a way for me to skip writing out these problems and allow me to go back to reading or playing with Lego blocks or watching the Superman movies I taped onto VHS from TV. I WANTED some rule as simple as “1 times anything is the number being multiplied” or “10 times anything is the number being multiplied with a 0 tacked onto the end”. I started to see patterns (we are talking about math after all, which is nothing without patterns). A solution for the ridiculously tedious number nine came first.

Looking at the following multiplication table, I unconsciously looked for patterns I could exploit. What patterns do you see?

1*9=9
2*9=18
3*9=27
4*9=36
5*9=45
6*9=54
7*9=63
8*9=72
9*9=81
10*9=90

I noticed the following in this approximate order:

Reversed Pairs of Numbers as Results
This was the first thing I noticed. 18 and 81, 27 and 72, and 36 and 63 all the results on opposite ends of the table form numeric palindromes. Even 09 and 90 technically work.

Everything Adds Up to Nine
Next, I realized that the first and second digit of every result always add up to 9. This seemed like something exploitable, and I saved the knowledge for later use.

First Digit Is The Number Being Multiplied By Minus One.
Eureka! I had a formula (even if I didn’t know that’s what it was called). I could take any number one through ten and subtract one from it for the first digit. Then I could subtract that number from nine to get the second digit. Simplicity itself!

I took my solution to Mrs. D, my first-grade teacher, for confirmation. I just knew she would be so happy and proud that I had found a better way to do multiplication by nines.

My youthful supposition couldn’t have been farther from the truth.

A study in human nature, being an interpretation with character analysis chart of Hoffman's master painting "Christ in the temple"; (1920)

Mrs. D. assured me that this was not the proper way to do the math and that I must write our all of my answers as she had taught. Needless to say, if young Willy Munn was a thing besides lazy, he was stubborn. I dug in my heels, so to speak. I refused to do this work stating that I would sooner die than do unnecessary work after I had found a better solution. Predictably, Mrs. D marched me right down to the principal’s office and demanded that he deal with my insubordination. She suggested corporal punishment if necessary.

The principal of my elementary school, Mr. F looked at me with kind, wise eyes, mostly gray hair, and just a quirk of a smile on the edge of his lips, and asked me to explain my method to him. I was nervous. I didn’t know what this corporal punishment was, but it sounded serious. With sweaty little palms and a mildly shaky voice, I explained my idea for the number nine. Mr. F asked some thoughtful questions and proved my hypothesis on the blackboard in his office. Then, to the joy of my young heart, he said the words I had so desired to hear from Mrs. D, “Willy, it looks like you’ve come up with a better way to solve this problem. At least for you.” Then the golden words of freedom, “Mrs. D, since this proves out, it shouldn’t be necessary for Willy to write out all of his multiplication solutions should it?” Mrs. D grudgingly agreed with her boss, although I’m fairly sure she held a cold, dark place in her heart for me for the rest of the year. In retrospect, maybe I shouldn’t have challenged her so directly, but I was 6 and thought the world revolved around me.

Mrs. D grudgingly agreed with her boss, although I’m fairly sure she held a cold, dark place in her heart for me for the rest of the year. In retrospect, I shouldn’t have challenged her the way I did, but I was six and thought the world revolved around me.

I went on to “discover” patterns for other simple multiplication problems that saved me a bit of time over the years, and even eventually memorized all the basic times tables. For several years, I got away with doing all of my math problems in my head and never showing my work. This irritated my teachers to no end and probably is what made learning manual Calculus feel like one of the most tedious tasks I’ve ever undertaken.

Many years later, while attending Southern Utah University, I learned additional math practices in my Discrete Mathematics class that used similar patterns and approaches to my early experimentation. Fun realization, that.

The Point (There Is One)

I knew, even as a youth, I had spent more time working on this solution than it would have taken just to write out the problems as I had been asked.

Today, I recognize my solution as less simple from the Mrs. D’s viewpoint. She was giving students one tried and true way of solving all multiplication problems. While it wasn’t easier for me to achieve my work, it was certainly simpler to teach. Just because there is a pattern or formula, doesn’t make a solution better based on that merit alone.

A fractal bacteria colony may BE simple once you understand it, but at first glance, it seems strange and complex.

fractal_bacteria_colony
Fractal Bacteria Colony

All anecdotes aside, the pursuit of better, simpler solutions is one that I’ve been chasing from a young age. It is the same pursuit of any scientist including the computer scientist. Let’s not forget this as we write code. Our ultimate goal should be the simpler solution because it will lead to better, more maintainable code. It will save time overall even if there is an opportunity cost up front.

We must remember that what is simpler from our particular point of view may not make sense from another’s perspective. A simple solution is only as good as our colleagues’ ability to grasp it.

Agile Teams Don’t Always Have Tech Leads, But When They Do…

I queued this post last year when I was a Technical Lead for an outstanding scrum team at HealthEquity. The role was new for me here, although I’ve had leadership roles at several companies over the years.

A Little Background

Our team consisted of six people who had never worked together directly. We not only found a way to meet the requirements of the project, but we also did it on time, on budget, with little overtime, and quite a lot of team fun.

At any rate, the team was very successful, and its success was noticed. It resulted in considerable renown for the team. Credit where it is due: the team’s success belongs to the entire team. My role certainly wasn’t more significant than any other. If anything, it was less important.

I’ve been asked by several people how we did it. My answer, as always, is that we have an awesome team. As a contributing member, I shared some of the load. Maybe my philosophy as a tech lead within the team helped as well. I’d like to think so.

agileTeamsDontAlways

My Tech Lead Philosophy

Top Tier Things To Not Forget

  • Principle #1: Respect the opinions of everyone. We are all professionals.
  • Principle #2: Make other team members’ jobs easier.
  • Principle #3: A tech lead isn’t the only person who has great ideas.

Also Good To Remember

  • Patience. Patience. Patience. Patience. Patience. Patience.
  • Give guidance by asking questions. It isn’t always possible, but it usually is.
  • Free team members to focus on sprint work by being the first point of contact.
    • I choose to address this by sitting at the entrance to our team area.
  • Encourage team members to learn by taking tasks that challenge them.
  • Take sprint tasks that don’t interest other team members when possible.

Probably Best Not To Do This Stuff…

  • Dictating solutions and stifling creativity.
  • Taking all the fun tasks for yourself.
  • Interrupting people unnecessarily.
  • Wheaton’s Law: Don’t Be A (Jerk).

————-

Obviously, I’m not perfect in any of these things. I do find that having the philosophy helps point me in the right direction. I hope it helps you as well.

Interested in technical leadership? Start by leading some coding katas for your team.

As always, write a comment below or hit me up on Twitter with questions or comments. Until next time.

Learn Like A Viking

My friend Ron Coulson (who I’ve known practically forever) has challenged himself to write a poem a day this year. He is well underway. This is #63 of 366, because, you know, leap year.

I’ll be the first to admit I’m no poet, but the subject matter here is near and dear to me — learning! I also enjoy a good metaphor and the Viking theme here is vivid and wonderful. Overall, it struck me as fantastic and I thought I’d like to share it with you all. Ron generously agreed. I hope you enjoy it as much as I did!

drinking-horn

Untitled

Let us devour knowledge in a way
That would make vikings cringe
Let’s gorge ourselves until we
Vomit certainties no one can dispute
Let truths drip from our chins
As the spittle of enlightenment
Lands in our opponents eyes
Raise your mugs, my friends
Then chug down life’s lessons
Until we are drunken sages
Then sleep
Then do it all again

-Ron Coulson (2016)

If these words have inspired you to learn, check out the new page I’ve added to the blog where I’m attempting to keep track of some of the best coding katas. Try one out. Let me know if you have favorite katas you’d like to see there.