Tag Archive

lego

Using LEGO to teach technical practices

Years ago now, Bryan Beecham came up with the idea of using LEGO to teach the concept of Test Driven Development (TDD). Since this is a topic most often used by developers, previous trainings had focused on demonstrating this technique on actual code. However, Bryan wanted to introduce it to a different audience; he initially wanted to explain TDD to management and then later to other non-developers on the teams. To do this, he needed to be able to illustrate the concepts away from the actual source code. And thus was LEGO-TDD first created.

LEGO Exercise: Collaboration

Most teams are a bunch of individual silos that have become good at passing work between each other. This exercise is designed to show how real collaboration is different from the way we normally work.

LEGO Exercise: Continuous Integration

Demonstrates the problems that occur when we don’t integrate frequently enough.

LEGO Exercise: Technical Debt

Demonstrates the kind of debt we accumulate if we don’t refactor as we go. This exercise will let the attendees experience the pain of dealing with technical debt, rather than just understanding it intellectually.

LEGO Exercise: Clean Code

Demonstrates the value of keeping the code clean.

LEGO Exercise: Test Driven Development (TDD)

Demonstrates the concepts behind TDD. How we write the test before we write code and how that forces our design to emerge.

LEGO Exercise: Simplicity

This exercise demonstrates the value of keeping the design simple and the code small. We’ll generally do this exercise before starting into any of the others as it’s really foundational for all Agile technical practices.

Back to Top ↑

jira_api

Jira API: Board details

Next we’ll look at the API to get information about a board. Boards are fundamentally broken, in my opinion, because they aren’t a real thing in Jira. They’re a view into issues at a point in time, which means that they don’t show up anywhere in the history. You can’t tell what board an issue was on when a status change happened, and you can’t assign an issue to a board.

Jira API: Statuses

The issue history gives us both the name and id of any statuses that the ticket has moved through. Sometimes that’s enough but often we then need to know more about that status, such as what status category it belongs to and for that, we need to call a different API.

Jira API: Issue history

If you want metrics out of Jira, the single most important thing you need to access is the issue history and it’s not obvious how to get that. Just about all the metrics you’ll want to collect will need data from the history - you might need to know when an item started or when it entered a certain priority or when the flag was set or cleared.

Jira API: Intro and authentication

I’m the primary author of the jirametrics tool that extracts data from Jira and generates reports. This tool evolved to satisfy my own pain of not being able to get useful data out of Jira with the built-in reports and along the way, I’ve learned more about Jira internals than I ever wanted to know.

Back to Top ↑

kata

Test driving prime factors in Go / Testify

This article will show how to “test drive” the prime factors kata in Go with Testify. Testing in Go is built right in, which is great. It’s a very bare-bones implementation though so adding Testify to the mix makes it a lot easier to write your tests.

Test driving prime factors in Java / JUnit

This article will show how to “test drive” the prime factors kata in Java with JUnit, an xUnit style unit testing framework.

Test driving prime factors in Elixir / ESpec

This article will show how to “test drive” the prime factors kata in Elixir with ESpec, a spec style unit testing framework.

Test driving prime factors in Ruby / RSpec

This article will show how to “test drive” the prime factors kata in Ruby with RSpec, a spec style unit testing framework.

Back to Top ↑

prime_factors

Test driving prime factors in Go / Testify

This article will show how to “test drive” the prime factors kata in Go with Testify. Testing in Go is built right in, which is great. It’s a very bare-bones implementation though so adding Testify to the mix makes it a lot easier to write your tests.

Test driving prime factors in Java / JUnit

This article will show how to “test drive” the prime factors kata in Java with JUnit, an xUnit style unit testing framework.

Test driving prime factors in Elixir / ESpec

This article will show how to “test drive” the prime factors kata in Elixir with ESpec, a spec style unit testing framework.

Test driving prime factors in Ruby / RSpec

This article will show how to “test drive” the prime factors kata in Ruby with RSpec, a spec style unit testing framework.

Back to Top ↑

tdd

Test driving prime factors in Go / Testify

This article will show how to “test drive” the prime factors kata in Go with Testify. Testing in Go is built right in, which is great. It’s a very bare-bones implementation though so adding Testify to the mix makes it a lot easier to write your tests.

Test driving prime factors in Java / JUnit

This article will show how to “test drive” the prime factors kata in Java with JUnit, an xUnit style unit testing framework.

Test driving prime factors in Elixir / ESpec

This article will show how to “test drive” the prime factors kata in Elixir with ESpec, a spec style unit testing framework.

Test driving prime factors in Ruby / RSpec

This article will show how to “test drive” the prime factors kata in Ruby with RSpec, a spec style unit testing framework.

Back to Top ↑

TrunkBasedDevelopment

Why we branch the code

Branching is a great workaround for problems elsewhere in the system that we are unable or unwilling to fix.

CI is not a server

We often hear things like “we’ve set up CI”, which makes no actual sense when you consider what CI is. It’s not a server or a tool, Continuous Integration (CI) is an ongoing practice whereby we keep the code continuously integrated. That sounds simple but has more subtlety than you might expect. Many places today that think they’re doing CI, actually aren’t, and as a result aren’t getting the benefit they could.

Too many branches

Most companies have too many active branches in their code repositories. “Active” meaning we’re doing actual development on them.

Back to Top ↑

elixir

Test driving prime factors in Elixir / ESpec

This article will show how to “test drive” the prime factors kata in Elixir with ESpec, a spec style unit testing framework.

Prime factors in Elixir

In the last article, we showed how pattern matching could solve FizzBuzz. It’s a deliberately simple example so let’s look at something a little bit more complex.

Exploring Elixir

I’ve long advised people to learn multiple programming languages, as each new language you learn will make you better at all the ones you already know. Not just languages with different syntax, but languages that challenge how you look at problems.

Back to Top ↑

bugs

Zero Bugs (Defects)

For many people, the notion of Zero Bugs seems like an unsustainable dream and yet the teams that do it are tremendously successful.

Defects / Bugs

Surprisingly, there isn’t much agreement on what a defect is or how they should be addressed. This page explains our position on defects and how we feel they should be dealt with.

Back to Top ↑

technical_debt

Technical debt and productivity

Technical debt is made up of all those things in our system (architecture, code, documentation, etc) that are working but are of sufficiently poor quality that they cause us to move slower when implementing new functionality. Perhaps we need to do additional testing before we can add something new or we need to refactor the code to make it cleaner or more extensible. Perhaps it’s just hard to read or understand and therefore difficult to know how to add the new functionality.

Technical vs Architectural Debt

I was first introduced to the idea of splitting technical debt into two distinct parts during a conference talk given by Rebecca Wirfs-Brock. She talked about there being a real difference between simple cleanup such as renaming or adding clarity and architectural restructuring.

Back to Top ↑

ContinuousIntegration

CI is not a server

We often hear things like “we’ve set up CI”, which makes no actual sense when you consider what CI is. It’s not a server or a tool, Continuous Integration (CI) is an ongoing practice whereby we keep the code continuously integrated. That sounds simple but has more subtlety than you might expect. Many places today that think they’re doing CI, actually aren’t, and as a result aren’t getting the benefit they could.

Back to Top ↑

go

Test driving prime factors in Go / Testify

This article will show how to “test drive” the prime factors kata in Go with Testify. Testing in Go is built right in, which is great. It’s a very bare-bones implementation though so adding Testify to the mix makes it a lot easier to write your tests.

Back to Top ↑

java

Test driving prime factors in Java / JUnit

This article will show how to “test drive” the prime factors kata in Java with JUnit, an xUnit style unit testing framework.

Back to Top ↑

pull_request

Pull requests are not a quality step

I found myself quoting Deming in a question about Pull Requests (PR’s) today.

Back to Top ↑

ruby

Test driving prime factors in Ruby / RSpec

This article will show how to “test drive” the prime factors kata in Ruby with RSpec, a spec style unit testing framework.

Back to Top ↑

waste

Technical debt and productivity

Technical debt is made up of all those things in our system (architecture, code, documentation, etc) that are working but are of sufficiently poor quality that they cause us to move slower when implementing new functionality. Perhaps we need to do additional testing before we can add something new or we need to refactor the code to make it cleaner or more extensible. Perhaps it’s just hard to read or understand and therefore difficult to know how to add the new functionality.

Back to Top ↑