Category Archives: Software Development

Unit Test When? Why?

The topic of when to unit test came up in a recent discussion with some people who are smarter than me. I’d just finished listening to a great presentation on Software Gardening. I hadn’t considered the option of Test First as I’ll describe it below. I’m not promoting the concept, but I thought it was interesting. Also, I’ve done what I’m calling Test Now, but I’ve never really heard it referred to as anything but another breed of Test After. The distinction is meaningful, and I think it deserves to be called out. I’m going to go out on a limb and make the assumption that you understand the importance of unit testing if you are reading this.

Why have this discussion? Because we want to be lean and do the minimal amount of large-scale rework. Also, because we want to understand the benefits and downfalls of each approach. In theory, there will be “best” options for a given set of circumstances. Let’s see what happens.

The Test When Continuum

I’m introducing the Test When Continuum as a way to help explain the commonalities and differences of these various test practices. The way I’m considering them is by the absolute amount of time between writing unit test code and production code.

Assuming we have a story or feature with 10 testable units taking one unit of time to complete each, we get the following dataset.

Given the assumption that testing beforehand is always best, and the data above, our test continuum looks like this:

Test First

First off, I misspoke when I said I’ve never heard of this approach. It was proposed by the software architect team at one of my workplaces in the hazy days of the distant past. I just hadn’t heard it called Test First Development, or if I did– I blocked it out. At any rate, in this particular gig, there was a lot of top-down design (or there was meant to be). The proposal was, if the architects wrote unit tests for their platform features up front, developers could just code monkey up and make those tests pass.

I was still learning at the time, and the idea seemed intriguing, if slightly wrong, and I couldn’t figure out why. For whatever reason, my Spidey-sense was tingling. I chose to ignore it, and as it happened, the architects didn’t have the time or discipline to take this approach either. So no harm was done.

Looking back, I’m sure my feeble brain was trying to tell me a few things:

  1. Throwing design over the fence with a set of requirements creates pretty much every problem we see in waterfall-type project management of software. Stage gates, anyone?
  2. Even if the developers had taken requirements and written every test possible, the approach
    • Doesn’t allow any flexibility in design when discovery happens mid-development
    • Creates a false imperative to stick with the original design no matter the cost
  3. There had to be a better way.

Consider your tests as eggs and the code as the critters inside the eggs, and I’ll drop some amazing English idiom on you.

Test Driven

Commonly referred to, by me at least, as the Holy Grail of testing. It solves all of the problems above. Does this mean the world should just give up every other type of development and convert to TDD (yep, this is just a link to the Wikipedia article on TDD)? Under the right circumstances, maybe!

I’ll say this: the test-driven approach leads to the best and most solid code I’ve seen in most cases. If you are doing Object-Oriented Programming (not your second semester college professor’s OOP, but modern OOP favoring SOLID, composition over inheritance, minimal state, and immutability), and you follow Red/Green/Refactor creating the simplest tests and bits of code to make them pass, then you refactor responsibly with the guidance of a skilled coder, you’re probably going to produce SOLID and clean code. There are additional benefits like semantic stability I won’t get into in detail.

Test Driven works well in most general cases as long as you are operating in a greenfield/new code environment.

Test Now

What’s this? Another made up name. I’m on a roll today with the Test When Continuum and Test Now. I must be a writer to make up so much garbage.

I feel like any kind of testing done after a material code change is always referred to as “Test After”. Let’s change this because there are varying strengths and weaknesses in the approaches.

The idea of Test Now is that after we complete a small, testable unit of code, we immediately write a test and make it pass. Then we look for opportunities to refactor our code and tests. Simple. Very similar to TDD, but perhaps with a couple of benefits under certain circumstances:

  1. You’re working with people unfamiliar/uncomfortable with TDD and they are driving.
  2. Your environment is exceedingly brownfield or “legacy” (existing code without tests and hard to test).
    • I know what you’re gonna say: “Just read Working Effectively With Legacy Code by Michael Feathers and all of your problems will be solved!” (Fantastic book by the way.)
    • The problem is, getting good at TDD takes time, practice, and diligence under the best of circumstances. Now we’re going to add learning how to effectively test legacy code to the workload at the same time. It’s a difficult thing to ask. The skills are important, and prioritizing what is most important can be difficult. I can’t tell you what would be best for your team.
  3. Your organization has just bought into the idea of Test After, and you want to move a step in the right direction.

Test Now gives quite a few of the benefits of Test Driven and is a nice place to stay for a while, but stick with those TDD katas. Keep practicing. Learn from Michael Feathers. In the meantime, Test Now is the second “Lean”est approach on our Test When Continuum.

Test After

Similar Test First in more ways than one, I’ll use another egg idiom to make the point. Testing after a feature or story is complete results in an “all your eggs in the same basket” scenario. Untested production code is fragile. All it takes is a couple of false assumptions. Maybe a sub-optimal design choice. Next, your tests are revealing the need for a systematic overhaul of the feature or story. At best, you hobble along and put tech debt stories in the backlog to fix it up later. Hopefully, you have time to get to them.

Conclusion

If you hadn’t guessed, I favor testing as close as possible completing increments of code. Before the code is written when possible– and after when it makes sense. General benefits are flexibility and usually better design.

My gratitude to Ben Davidson, Craig Berntson, Kaleb Pederson, and Dwayne Pryce for their eyes and time reviewing this article!

Here’s an updated Test When Continuum:

Legacy Code Kata v3.0

You’ve been patient. Some of you have been patient. Last week on Thursday night, I presented Legacy Dependency Kata v2.2 at the SLC .NET User Group Meetup. You’ll notice the name change since then.

But wait– don’t know what a code kata is? Start here.

I’d like to give a quick thank you to the crowd that night and the one the day before at HealthEquity during one of our Lunch Learning sessions. You all are fantastic. Thanks for the great feedback!

What’s different? Not much, to be honest. Also, in some ways, a lot. But what I realized as I was going through the slides one final time, was this: this IS a major revision. I just didn’t realize it while going through all the multiple iterative changes.

What hasn’t changed? Legacy Code Kata 3.0 is still a code kata about dealing with dependencies in legacy code and getting it ready for unit testing. It still uses the same seed code as previous versions, and you can find that here on GitHub.

Changelog

So, what makes this version so great? Let me lay it out for you:

  1. Lost the lame presentation theme. I thought I accomplished this with v2.0. NOPE. You’re welcome.
  2. The intro slides have been honed down to only those 100% essential, and they were also prettied up, and some new notes added.
  3. Added the Kata Barometer (patent pending (not actually (maybe))). At any time you always know what state your tests and build should be in.
  4. Broke up quite a few slides that were too complicated and/or the font was too small to read effectively. Much more Kata Cup friendly now. What’s a Kata Cup? Maybe in a future post. Stop changing the subject!

If you want to see for yourself why this version is so much better, check out the old versions: Version 1.0 or Version 2.0.

Here it is.

A Tech Lead Is Not A Manager: Influence vs. Authority On Agile Teams

I previously wrote about how I worked on an agile team as a tech lead. The article focused on the things I recommend. Today, I’m going to take the opposite approach and share what to avoid: the misuse of authority including mistaking an influencing role for an authoritative one.

You can read the original article here.

Roles, Roles, Roles

On agile teams, a Tech Lead is far more like a Software Architect or an Agile Coach or a Product Owner or an Engineer than a Manager, Director, or another role with people reporting directly to them. You don’t have AUTHORITY as a Tech Lead, your weapon of choice is INFLUENCE. Of course, even people with authority should rely on influence as much as they possibly can. Authority is a tool in the toolbelt of some roles, and those people must use it sparingly. Autonomy is too important to take away from creative workers (and Engineers are indeed creative).

At times authority must be used by people in what I like to call “dark side” roles. Managers, Directors, Veeps, etc. must at times use the stick instead of the carrot. Usually, this is reserved for extreme cases when a team member is refusing to follow company policy or is threatening or endangering someone. In a positive culture, these things should seldom IF EVER happen.

One of the things I love about the organization at my current company, HealthEquity, is the culture of influence. Influence is the currency of the day at all levels of leadership, and it’s used efficiently and effectively.

What Does Misuse Of Authority Look Like?

Some key things to look out for: body language, word choices, and the audience. Watch for words like these coming from your mouthhole:

But, I’m the Architect/Manager/Director/Scrum Master/Tech Lead/etc…

…you have to do this.
…this is the only option.
…because I said so.
…it’s my way or the highway.
…eat crap and die.

Absolutes and personal attacks/insults are not going to work. They may sometimes achieve the immediate effect you wanted, but it’s going to come back to bite you in the end.

Avoid negative feedback in a group setting at all costs. If you MUST provide negative feedback (and yes, sometimes we must) always, ALWAYS, do so in a private 1:1 situation. Involve your people leader if you aren’t comfortable one-on-one.

Instead, look for ways to encourage, build-up, support, and assist people in doing what you believe should be done.

Shameful Anecdote Time

Once, in an earlier decade of my life, I was an inexperienced young team lead. I had responsibility for a developer who was undertaking a critical task. The task wasn’t moving along the way my manager and my manager’s leader hoped it would. There was some time sensitivity involved, and I was asked to research the issue and get things moving along. I did some investigation and found that the developer was spending a lot of time (over 50%) not engaged in his work.

I’ll admit it; I was frustrated.

Instead of following the advice I’m giving in this article, I decided to walk right up to this person’s cubicle and ask how the work was progressing. Nothing particularly wrong with the approach, although in hindsight, I should have known the discussion was likely to become sensitive. I should have invited the developer to a private location to discuss one-on-one.

Anyway, when we spoke, the developer told me how well it was going and how hard he was working and how he’d have this already late project completed just as soon as he could, but not for at least a few more days. When describing the work remaining, I felt it was completely trivial. It could have been completed THE NEXT MORNING.

I won’t go into detail, but I lost my cool. I felt pressured and I let the pressure rule my emotions. My voice rose high enough for at least neighboring cubicles to hear, if not more. I told this developer that he would finish this work by the end of the next day or there would be hell to pay.

I’ve never seen someone’s face go from zero to pure unadulterated hatred so quickly.

The developer finished the required work on my timeline, but I had ruined a relationship and completely demotivated my co-worker. As kind, cheerful, and pleasant as I could be, it never made up for my error. The individual became a habitual underperformer, and eventually was let go by our manager.

I’ve always wondered how the situation might have gone if I knew then what I know now. Would I have pulled this individual aside privately? Would I have offered my help or another’s on the team to push through the last bit of work? Would I have asked more about the situation and sought to understand why he was underperforming in the first place?

I’d like to think I would have. I’d like to think I’d have given less weight to some of the authoritarian “truths” I’d been exposed to growing up.

Avoid False Truisms Of Authoritarians

Avoid being taken in by the truisms of autocratic leaders like Bonaparte and Hitchcock. Do not let their philosophies influence your leadership style.

“Men are moved by two levers only: fear and self-interest.” -Napoleon Bonaparte

“If an actor comes to me and wants to discuss his character, I say, ‘It’s in the script.’ If he says, ‘But what’s my motivation?’ I say, ‘Your salary.’” – Alfred Hitchcock

The work we are doing in any creative or thought-related organization requires 100% of the team’s buy-in, commitment, and enthusiasm to be as effective as possible.

Leaders don’t and can’t have all the best ideas. Create psychological safety for people you work with to aid their growth and contributions.

Authoritarian leadership styles have little or no place in Agile organizations.

In closing: I recommend avoiding the “command and control” mentality in favor of “inspire and innovate”. Tech leads (and technology leaders in general) aren’t running military operations; we are engaged in creative endeavors.

When Does Counting Lines of Code Make Sense?

ALERT: I’m not pulling any punches with this one. If you are looking for a balanced argument including thoughts on some potentially good reasons to measure LoC, you won’t find it here. The best reasoning I can give for the existence this article: it gives me something to point people to when they ask for my opinion on the topic.

Counting Added Lines of Code as a Measure of Productivity

“Any process or procedure that incentivises based on creation or destruction of lines of code is missing the point entirely.”

David Adsit
Software Craftsman – Pluralsight

Counting LoC drives bad behavior and is easily manipulated. It leads to developers being less concise and writing code that is difficult to maintain. There are so many ways to write code less efficiently and these are exploited in a scenario where LoC are measured for productivity.

Here is one extremely simple example of code inflation:

Arrays.fill(array, -1);

and

for(int i = 0; i < array.length; i++)
{
  array[i] = -1;
}

The above examples logically equivalent in Java. They both work. They both do the exact same thing. In C# the first could look like the following:

array = Enumerable.Repeat<int>(-1, array.Length).ToArray();

We could also write our own C# extension method to match the simpler Java method and use it throughout the code in future improving readability and maintainability.

public static void Fill(this int[] array, int fillValue)
{
  for(int i = 0; i < array.length; i++)
  {
    array[i] = fillValue;
  }
}

Once complete, it would be executed as follows:

array.Fill(-1);

This approach would lead to a couple of additional lines when it is first written ONCE and then only one line to do the same work forever after. Assuming of course that people know the extension method exists and they use it… another discussion perhaps.

One of the reasons we use modern programming languages is because they are expressive and easy to read. Even in a current modern language, older and more verbose approaches are still valid in code (to enable us to customize better approaches on our own that are not supported by the framework) and can easily be exploited by developers looking to boost their LoC written.

Counting Added LoC as a Measure of Productivity Must be Based on False Assumptions

“[Counting lines of code as a measure of productivity] presumes that each day or week or month is the same as the last day, week, or month, and that the thought stuff we actually get paid to do doesn’t matter.”

Dwayne Pryce,
Senior Software Engineer Microsoft Research

Measuring added LoC also assumes the work completed before, after, and during the coding process to determine best/cleanest/most maintainable/efficient approaches are meaningless and that testing to verify that the code does what is was intended to do is a waste of time.

Additionally, less-experienced junior developers are always going to write more lines of code than senior people for a variety of reasons.

  1. Junior people often take the easiest, most brute force approach because they haven’t learned to do it better. Yet.
  2. Junior people are given less complex tasks to solve that can be done more quickly.
  3. Progressively more experienced people have additional increasing responsibilities (for example mentoring and training less experienced people, doing more code reviews, being involved in architecture/design discussions, taking on difficult roles like security guild, creating documentation, etc.

1 and 2 are arguably best solved by pair programming. Another discussion. Another time.

Counting Removed LoC as a Measure of Paying Technical Debt

“Simplicity is the ultimate sophistication.”

Leonardo da Vinci

Same as measuring added LoC, counting removed LoC drives bad behavior and can lead to developers writing code that is intentionally overcompact and difficult to read. However, in a large and unwieldy application, we want to remove lines that serve no purpose at every opportunity while maintaining the same functionality. If this were trivial, we could simply automate programming and developers would no longer be needed. Making things simpler is, simply put, not easy.

Counting LoC as a Measure of Quality

In the history of computer science, there has never been a valid correlation between LoC and quality in any programming language in existence. Check the textbooks, the internet, or anywhere else you can think of. This correlation does not exist.

The Burden of Unnecessary LoC is Non-trivial

“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”

Bill Gates

I’ll use a slightly exaggerated example here, but it isn’t too far off, so please bear with me. Let’s assume we have two people attempting to solve a difficult problem.

Persona A

  1. may be less experienced or expert beginner
  2. just get’s it “done”
  3. tends to solving problems hastily without concern for introducing bugs
  4. often works quickly and on their own without taking time for design discussion, planning, and refactoring
Persona B

  1. may be more experienced
  2. cares about quality and hates bugs
  3. aims to understand the scope of the problem before starting to solve it
  4. involves others (seeking real input) to suss out design flaws and make take more complex problems to a mentor

I’ve seen real life scenarios where Persona A will solve a similar problem in 2000-3000 LoC where Persona B would solve it with 200-300 LoC. That may not seem so bad. Maybe Persona A finished their effort in less time than Persona B. Now consider, from the time this code goes into production until it is replaced/removed/refactored/decommissioned, we have to pay to maintain the code that was written. When we want to make a change in the behavior of the

Maybe Persona A finished their effort in less time than Persona B. Now consider, from the time this code goes into production until it is replaced/removed/refactored, we have to pay to maintain the code that is written. When we want to make a change in the behavior of the code or add a new feature, Persona A’s code may require days of review to understand and will also require many changes to achieve. To make a similar change to Persona B’s code, it could be understood in an hour, perhaps. The changes should take considerably less time depending on their complexity.

When we want to make a change in the behavior of the code or add a new feature, Persona A’s code may require days of review to understand and will also require many changes to achieve. To make a similar change to Persona B’s code, it could be understood in an hour, perhaps. The changes should take considerably less time depending on their complexity. Of course, this scenario is hypothetical. This is my one apology for rhetoric.

Coda

For clarity’s sake, I’m in no way arguing against hiring junior people. Fresh blood is vital for tons of reasons I won’t go into here. However, the effective incorporation of junior people must be accompanied by the correct structure and support from more experienced people in order for them to succeed. I AM against hiring expert beginners who’ve been doing this work for many years and thinks the “just get it done” approach is the best/only way.

 

Holy Microsoft, Now Compile

The following is 100% parody of the good-natured Weird Al variety. Much like a good Weird Al song, I couldn’t get it out of my head, so now I’m subjecting you to my foolishness as well.

I offer up my apologies to Catholicism in general. Microsoft, on the other hand, can fend for itself.

 

Hail Microsoft, full of office tools.
Our code is with thee.
Blessed art thou among DEVELOPERS,
and blessed is the fruit of thy IDE: executables.
Holy Microsoft, Mother of C#,
pray for us sinners,
now and at the hour of our broken build.
Compile.

 

Now share this post with 10 people and Bill Gates will donate 99% of his wealth to charity.