Brendan Enrick

Daily Software Development

Being a Leader

I started my career as a software developer, because I love computers and I love building things. Building software, no matter the type of involvement, is an experience worth working toward. There are few things that can provide as much joy in such a short amount of time than seeing the text you’ve written come alive. In the last 5 years of my software development career, however, I’ve been leading teams of developers rather than just typing the lines of code that go into the software. Working with a team and building great things together is something I love regardless of the type of contribution I am making.

Now that I am transitioning back (at least for a time) into a primarily development role, I want to take some time and reflect on that change. I have enjoyed all of the work that I have done in my career, and I look forward to many more years building great things with great people.

I will never stop writing code. It’s too much fun to give up completely, but I also love people and working with people. For that reason, I enjoy leading teams of developers as well. I’ve spent these past 5 years trying to improve my leadership, not just for my own benefit, but for the benefit of my teams and the software we create. As many of you know, I blog so that I can share what I’ve learned with everyone (including my future self).  Let’s talk about leadership.

Know Your Team

As a leader, it’s important that you know your team’s strengths as well as their weaknesses. This is not exactly a radical idea, but it’s one that I’ve seen ignored far too often. Every member of your team has goals, opinions, preferences, etc. They’re people. If you don’t know anything about them, you’re not leading your team. The best experiences I’ve had as a leader are always when I am communicating and soliciting feedback and ideas from everyone involved.

I make a point of getting to know my team. I make sure to lighten the mood, so I can meet the professionals as well as the people they are. If I know that certain people have tendencies toward certain things, that allows me to lead them better. It’s my job to make sure that they’re doing their job well and are happy about it.

A good friend of mine, Steve Smith, recently took on the role of CTO of Falafel Software, and I was chatting with him about that new role. He was commenting about getting to know his team and having discussions with them. I suggested he spend an hour or two pair programming with everyone he’ll be working with. This gives him the chance to talk with them and also learn how they like to work. It comes with a couple of very important benefits: it lets Steve write some code and it also lets him learn about the projects.

Know Your Projects

One of the most frustrating things as a developer is having to constantly explain and re-explain a project to a manager. Don’t be that guy. Make sure you know the project. You’re involved. Sure, you need to talk and ask about how things are going, but you should understand what’s being done. You’re not there to tell people what to do. You’re there to help people get those things done.

If you need to sit down and pair with your team, do it! Sit with the designers and help them design. Sit with the developers and help them code. Work with the team. You’re a part of the team.

When I am leading a team, I am with the team. I’m only in my office when I need a quiet space. The rest of my time, I am sitting right next to the team. If I roll my chair back, I’m bumping into a developer or a designer. That’s my ideal situation. When anything happens in the project, I need to at least be aware about it, and constantly pestering my team for status updates is not an appropriate way to do that. It wastes their time and reiterates that my time is more valuable than theirs (completely false).

Solicit Feedback

Clearly, before I make a decision, it’s a good idea to make sure that the team has a chance to weigh in on things. When you are a leader, it is likely not a democracy. Make sure you know that and make sure the team knows that. If a decision I make will impact the team, I at least alert them to it before the decision is made. This gives the chance for cries of outrage. More often, I prefer to actually have a quick discussion before making my decision.

One topic that comes up all too often is physical versus digital kanban boards. This often has to do with the circumstances of the project. Obviously if everyone involved in the project is in the same room, a physical kanban board has a lot of benefits, but if you’ve got a single remote user, you’ll lean the other way. I’ve had a few developers with strong opinions one way or the other, so I try to accommodate when I can. I know which to use for each project because of the developers who are on them, because I get to know my team.

Asking for feedback allows the team involvement in the decisions and gives them some stake in things. Make sure you’re listening and taking their suggestions to hear. I know that I never know the best approach from the start. I chose my team, because they’re smart and can help me make the right choices. Often the right choice is based on the team, so you really should ask the team.

Identify Leaders

As a leader, you need to help other leaders become better leaders. Often leadership qualities are on your team. That’s great for you! Let them take on some leadership. Give them the chance to lead some discussions, meetings, projects, etc. It will help them (and the team) to build great things. Sharing responsibilities with others will let you focus more, and will let them grow as leaders. You’ll need peers to help you lead others and people to cover for you when you’re busy or out of town.

Your team is often better at leading than you (or they) might expect. A leader who has never had the chance to lead may not know they can. If you can identify and grow leadership in your team, you will have empowered your team to make good decisions. The more your team can do on their own, the more you (and the entire team) are able to accomplish. Build more. Build better. Build the leadership in your team. It’s there already. You just need to find it and grow it.

Lead the Team

Yes, this also sounds kind of silly to mention here, but I am serious. There is a big difference between leading and directing. If you’re leading, you’re out front blazing a trail. If you’re directing, managing, or even guiding, you don’t have to be out front. When you’re leading a team, you’re setting examples. You’re doing things the right way (whatever that is for your project). You’re not cutting corners or doing a sloppy job. It’s your job to not only help, but to make sure that everyone else can follow in your footsteps to achieve success.

How you lead a team is extremely important. If you cut corners, your team will as well. If you have a sour attitude about the project, that will spread. If you’re lethargic and bored by the project, you won’t be seeing an interested, engaged team. Be the team you want your team to be. If you don’t you can’t expect any better from anyone else. This doesn’t mean you need to be the best developer, designer, tester, copy-editor, or anything else. You just need to be willing to put forth good, positive effort. You’ll be amazed at the results. When I do that right with a project, I am always impressed with how the whole teams steps up to every challenge. Whenever I’ve cut a corner, I see it repeated. It’s just not worth doing.

Set an example. Be a leader to emulate. Stay positive. Keep things moving smoothly. That is your job. Leading is hard. Doing it right is harder, but it’s very worth it. If you do it right, your team will do amazing work that will have you in awe. With that said, I’d like to thank all of the developers and designers who have ever been on my teams. I was glad to have every one of you on my teams, and you did fantastic work. (You all knew that already though!) We all achieve some great things! Now it’s my turn again!

I Joined Clear Measure

I am just about to finish up my second month on the Clear Measure team, and I am still very impressed with what this team has built considering how young the company is. I’ve known Jeffrey Palermo, one of Clear Measure’s founders, for plenty of years, and I decided to jump at the chance to work with him and his team. It is an opportunity that I could not pass on.

Role Change

Many developers who have worked with me in the past are excited to learn that I am now getting to write a lot more code than I did before, since I’ve stepped out of a leadership position and have taken on a Principal Software Engineer role with Clear Measure.

I am looking forward to the chance to delve back into the world of coding more. I’ve been able to write quite a bit of code while leading my teams, but this will give me the chance to get back to what I love. I’d been looking for a chance to make this change back to development for a while. I don’t expect that anyone can keep me permanently out of a leadership role, but I am in the industry for the development.

I’ve been leading development teams for Steve Smith and Michelle Smith for quite a few years, while we were running NimblePros and while we were Telerik Services. Easily the most difficult decision I’ve made in my entire career has been to part ways with them, primarily because it seems like such a big mistake to stop working with them. I am sure that this is not the last time I will work with those two. In fact, I am already discussing some plans for a side project with Steve.

Diving in Head First

I’ve been extremely impressed with the speed at which I was able to start writing code with Clear Measure. Many others are impressed to learn that I was building and running a solution in my first hour at Clear Measure. That’s just awesome.

Additionally, since Clear Measure had just started the project, I was able to get things running the way I wanted them to. The project is running under continuous integration and is a derivative of this Iteration Zero project. Letting the new guy run loose like that was something I was very happy about. In fact, the entire company seems to be based around the idea that people will make good choices when given the chance. I agree!

Two Dimensional Brendan

Now that I am working remotely, my team primarily sees me through a webcam. That’s certainly a change! I am a big proponent of having a team that is co-located, but for the right team you make exceptions. I think Clear Measure considers me the exception, and I consider them the exception. I’m just glad that we can agree on the situation.

I went from being in spaces like these:

Team Room 1

Notice the close proximity and lots of pair programming. No walls and everyone is constantly able to share information and ideas.

Team Room 2

In these buildings:

NimblePlex

Yep those two buildings are what I like to call “The NimblePlex”. NimblePros shifted around quite a bit between these two buildings over the years. I had 4 different offices while I was in those buildings! Long stories to explain all of those!

Now I am using this desk:

HomeDesk

It works pretty well for me. I made sure to get one that was for work and one that wasn’t. I am currently seated about 5-6 feet to the left of where I sit there. That’s important to me, having that separation.

For anyone paying attention to these pictures, I’ve got a Software Craftsmanship calendar on my desk, a Pluralsight mouse pad, an ASP Alliance coaster, and that’s a stack of books in the reflection. Can you identify the books? If you have a copy of the Software Craftsmanship Calendar, you might recognize three stars from this year’s calendar!

I did not expect to be working from home at this point, but it’s been interesting. I am able to have much better lunches than I did before. I now take 20 minutes to prepare and eat a salad most days, and I am watching Star Trek on Netflix during that time. I take a full hour for my lunch break though, so I have time to finish the episode while running on a treadmill. It’s amazing how much more energy I’ve got in the afternoon with this routine. I cannot recommend it enough. In fact, if I do move back into an office, I am looking into having a treadmill there!

Going Forward

I am never one who is without goals. If anything, I would say that I have more goals than I could possibly achieve. I’ve always thought that a good thing, since it gives me direction.

I am working on and planning some Pluralsight courses, which hopefully will be out soon. I’ll keep you posted.

As I’m sure you figured out, I don’t mind working remotely. In fact, it’s got some benefits and has been going well. My next goal at Clear Measure (aside from the success of the company and the projects I work on) is to build up an extremely talented team around me. I’ve started that process already, and Rich Hildebrand recently joined our team up here.

CodeMash 2014 Software Craftsmanship Precompiler Workshop

CodeMash 2.0.1.4 started as one of the coldest CodeMashes on record. On Monday, during the set up time for the event, the temperature in Sandusky dropped below negative ten degrees and the wind chill kept it feeling much colder. It was severely lacking in snow, but the cold was enough to cancel many of the Tuesday precompiler sessions whose speakers were not able to arrive at CodeMash on time to run the workshops.

The conference has grown to the point where it now has two initial days of workshops on Tuesday and Wednesday. Then the conference has two normal conference days filled with sessions. Considering that all of my favorite content is always the precompiler workshops on the first two days, I would love to see the conference have workshops through the entire event. I am usually one of the precompiler workshops speakers, so I might be a bit opinionated on that. From another viewpoint though, since I am one of the speakers during that time, I am often wishing I could attend workshops during the same time as mine! I love running the workshops though, so I gladly give up the other ones. I just need to figure out how to be in two plaes at once (future goal).

CodeMash Precompiler Workshop Details

For those who attended my and Steve’s Software Craftsmanship precompiler workshops on Wednesday, the weather was much more forgiving. Most people had arrived by that point, which meant that our attendance was also good. This was the fifth year that Steve and I had run this precompiler event at CodeMash. We adjust, change, and update the workshop every year. In the past, we had to teach a lot more about the basics of unit testing, but now more people have at least some knowledge of unit testing.

Over the years of doing this workshop here (and similar ones elsewhere), we've found a lot of good techniques and exercises for working with the attendees of the event. We try and experiement with lots of exercises and katas at conferences, events, and user groups, because we're looking for great ways to teach these types of events. When we run them, we are always trying to make sure that most of the event is spent coding. Through this, our goal is not to give an exercise to the attendees. Our goal is to teach them how they can continue their exercising and learning after they leave the event. That's our goal.

We use a few types of exercises: gateway exercises designed to teach you how to practice, guided exercises leading you down a path slowly with steps for freedom along the way, and open-ended exercises giving great freedom and possibilities in final implementations. As part of the open-ended exercise, we often attempt to use that as a plane up which to build a specific type of implementation. We will choose a principle or a pattern and use this plane as an area in which to practice following the principle or pattern. This shows the students how they can leverage programming exercises as places to learn new principles and patterns.

Beginning Software Craftsmanship Workshop

In the morning, we start out our session for beginners just learning software craftmanship. This course is for people familiar with programming (using any language) that want to learn more about software craftsmanship and work on programming exercises with their peers.

As we do every year, I started off the discussion by explaining software craftsmanship and giving an introduction to its concepts. I explain the software craftsmanship manifesto, what it means to developers, and how it relates to the agile manifest. Through this talk, I always make sure to emphasize the importance and reasons for deliberately practicing. As the entire audience will agree, when under a deadline they jump back to their poor practices they know aren't the best. Practice is how we drill ourselves to handle the situation in our own desired way. I make sure that the audience knows as well as discussing and working with others. If I can encourage more people to attend and start software craftsmanship groups, I would consider this talk a great success.

Introduction to Software Craftsmanship Slides

Once we had the reason for why we're all here, we start getting into some of the meat of the workshop. Steve then presented his well-honed talk on software principles. Most of them are designed for object oriented programming, but many are applicable to nearly any language or paradigm. Along the way he of course will cover SOLID, and the slides all contain images from our Software Craftsmanship Calendar. The 2014 edition of the Telerik Software Craftsmanship calendar is out, and everyone at CodeMash received a copy of the calendar.

Software Development Principles Slides

While Steve is wrapping up the end of his presentation, I start passing around sheets of paper (yes, real paper) containing a printing of the first exercise we'll be doing. For our first exercise, we were doing FizzBuzz an exercise that is simple enough that it gets people used to the idea of practicing. This is our gateway exercise. We use this to make sure that everyone is set up with their tools. As long as their setup allows them to write code and run tests, it should be good enough. We include some extra credit with these, so that most people can at least get close to finishing the first part of our exercises. Some people will finish the extra credit, which means that we can have nearly everyone reach a stage of accomplishment. 

We also ask that the entire group pair up, so that they can work on the exercise with others. This accomplishes quite a few things, including helping those who don't have a computer with them.

FizzBuzz Programming Exercise

Interrupting everyone's coding is always a challenge, but I make sure to do it nicely. A microphone helps with this! Now that everyone is set up, we take a break from the coding to talk about practices that we promote to the group. The first of these practices is testing. As is still the case, most people are testing or at least familiar with the practice. As a result, I cover this topic briefly making sure to emphasize the different types and their importance. There are still many groups forced to write integration tests instead of unit tests for example. We discuss how to avoid that situation in the afternoon when we discuss more good practices. 

The second practice that we discuss is continuous integration, however, since we don't have the time to set these up on everyone's computer, we only discuss this briefly and suggest that people try them.

The third practice is pairing, a practice that we've already had the group start in their first exercise. Not only do I cover the methods of pairing, but I point out all of the good pairing practices that everyone was using without thinking. I then point out the importance of changing partners and typists frequently. In their first programming exercise, very few people change who is typing. Since pairing is such a hard activity, we also make sure to cover all of the things that you can do to improve your pairing by changing the environment in which you're working.

Software Craftsmanship Practices Slides

The String Calculator is a guided exercise in which you only read one step at a time. Each step has parts to it, but you do them one at a time. This follows the normal scenario of receiving your requirements a piece at a time. It also keeps you following a plan and gives you a great chance to follow YAGNI. The students do well with this, and it's an exercise that does very well on paper, since you can fold the sheet over the future steps. 

String Calculator Programming Exercise

Intermediate Software Craftsmanship Agenda Workshop

After lunch, we started our second workshop. This one is a half-day workshop designed for people who attend the morning workshop or are already somewhat familiar with software craftsmanship, deliberate practice, or who just couldn't fit the morning session into their schedule. 

Steve starts off the talking in the afternoon discussing design patterns. Steve is an expert in design patterns and refactoring, so he's a great person to present this workshop with. Steve covers a lot of design patterns in this talk. You'll notice that a lot of these patterns have overlap and many of them stem directly from one or more of the principles mentioned in Steve's morning talk. This is not a session to miss!

Design Patterns Slides

Once we're done with the design pattersn talk, we make sure that we start everyone on an open-ended exercise. This year's was the greed dice game scoring exercise where you create code that will score the results of one roll in the greed dice game. It's a simple exercise, but can get a bit unwieldy if you're not refactoring or implementing a good design. We don't suggest that anyone try any specific design for their first attempt.

Greed Game Programming Exercise

We follow up this programming with even more programming practices to follow. I do this talk, which is about more advanced types of testing using mocks, fakes, stubs, etc. We want to make sure everyone knows how to do these. We sometimes do an exercise that can leverage these skills, but we did not this year. We instead showed a quick demo of doing this with a logging system that logs to the file system.

Advanced Testing Practices Slides

Back to Greed again for the final exercise of the day. We finish out the workshop asking everyone to program the Greed game scorer again. This gives the students the chance to attempt a more complex solution to the problem this time around. We had everyone attempt to implement a Rules Engine for the second attempt, which will allow them to follow the Open/Closed Principle.

Overall we received a lot of wonderful feedback from our students, and I hope that everyone who attended goes on to continue doing what we taught in that workshop. Thank you all for attending. Thanks CodeMash for putting on a wonderful event and inviting me and Steve to run one of your precompiler workshops. It is always a fantastic time! I look forward to seeing more of you there in the future. Have a great 2014!

A Developer's Guide to QA Testing

No project should be released without some level kom verification. Someone has to test that things are up to some standard. Contrary to the popular belief, this is not just an important task, it's a difficult skill. Many clients I've worked with hire pretty much any person to be a QA tester. The belief here seems to be that anyone can find bugs. Well, they're right, however, they're also terribly wrong about the role testers play in software development. Your QA testers can make or break your development team, and I think many people value the traits that will lead them toward failure.

At this point in my development career, I've worked on internal development projects, external development projects, and "product" development. I've worked on in-house and consulting projects. I've run full teams as well as augmented existing teams. I've worked with good QA testers, mediocre QA testers, and people who log bugs. Not sure which group you're in/working with? By the end of this, you'll know that (and hopefully picked up a few pointers).

Why QA Testers Are Needed

One of the biggest concerns I have regarding the success of any project is that people will misunderstand the role of QA testers (and QA testing). The QA testers are part of the development team and enable great work across the whole team. The important thing to remember is that they enable success; they're not there to impede progress. If I can stress only one thing about the them, it's that the role of QA testers is not to find bugs. Finding bugs is easy. Remember? Anyone can find bugs. That's why people hire QA testers as entry-level employees and assume that anyone can perform the task.

Your QA team are here to help the developers, designers, and stakeholders create something that everyone will be very proud to have contributed toward. They can do this by making sure that everything is built the way it needs to be, and making sure to not create roadblocks that slow the team.

Break Down the Walls Between Communication

As it is with every role on your team, communication is the key to success for QA testers. When the QA testers "throw back" a story or bug fix without discussing it with the developers first, they've failed in their task. When the developers accomplish a story or a bug fix without discussing it with the QA tester before testing, they've failed. When the QA testers evaluate a story or bug fix without confirming the behavior, reasoning, and requirements with a stakeholder/customer, they've failed. When the QA tester finishes testing a story or bug fix and does not show it to the customer (or put it in a queue to be shown), they've failed. I am trying to not focus too much on the negative aspect of things here, but I do want to emphasize that every action taken by a QA tester should be preceded as well as followed by communication with other members of the development team.

Focus on Everything that is Current

While an entire application needs to be tested, it's important that most of the testing focus be kept in context. Testing the areas of the application that are being actively worked on is the best way to ensure success. Remember that the testers are enabling development. To this end, the tester is making sure that the team get immediate feedback. This means that the tester can ask the developer what was built immediately following the tasks completion. This means that everything is fresh. Ask a developer about details of the code he or she wrote a month ago, and you'll get a mediocre response. Ask them about what they built 20 minutes ago, and you'll get a clear answer.

Keeping this focus will prevent a few things that we want to avoid.

We don't want to have a huge pile of bugs relating to aspects of the system where we're not focusing attention. This can cause context switching and thashing. Yes, those areas need testing as well, but you've already spent time testing them. The important thing now is to focus where attention is currently being placed. This is where you can provide the most, current benefit to the team. Your watchful eyes will keep things completing. If that pile of bugs gets too large, the team will lose focus and have trouble maintaining its good pace. If things start piling up, make sure you're keeping the list pruned. Talk with the stakeholders to make sure that bugs you're filing are important. Don't be afraid to eliminate some bugs you've found. Remember, if they're important enough, you will find them again later. The system may change completely before the bug is even addressed.

When you're working in less familiar territory, it's easy create a duplicate bug. If you've forgotten or don't know that bug's already found, it's easy to file a bug's twin. Another tester may have phrased things differently, making it difficult to avoid the duplicate. When everyone switches sections of the application, a context switch will refresh everyone's mind on previously filed bugs (avoiding this scenario more often).

Even though you may check with the stakeholder, not everyone will remember what features have been completed. It's easy to create bugs, which are actually feature requests. If someone believes that a feature exists, but it was never completed, a bug may be filed by mistake. It's possible that there was a good reason (possibly a priority change) that left that feature incomplete. Either way, it's not your responsibility to file feature requests. The same as we said for filing too many bugs, if it's important, it will come up again.

Track Everything

asdf

Record Your Steps

asdf

Think Carefully and Don't Jump to Conclusions

asdf

Check Before You File Bugs

asdf

Have Fun and Get To Know Your Team

asdf

Improve Your Team

asdf

2014 Software Craftsmanship Calendar

The 2014 Software Craftsmanship Calendar is now available for preorder!

If you were a fan of any of the previous Software Craftsmanship Calendars or just liked the posts about some of the months, you'll be glad to know that we continued making a new one. We are continuing to alternate between Good Practices and Bad Practices, so this year (being the 4th) is a calendar of anti-patterns.

Each month of this calendar shows something that you shouldn't do, but plays it off as a good thing. You'll also find an interesting, related quote and a definition of the anti-pattern on each month.

Go get your calendar today!

Updating Fiddler Documentation

For those of you who still haven’t seen the new Fiddler site, go check it out. I blogged about the updated Fiddler site recently, but I didn’t mention the coolest update to the site.

The old site had some documentation on the site. It was scattered around on some help pages and had a lot of good information, however, we’ve now brought that information together and organized it into a nice, usable Fiddler documentation section on the site. If something you want is missing from or incomplete, don’t worry. We are working on improving the documentation in a variety of ways. This is just the initial release.

Help Fiddler’s Documentation

If you’ve ever worked with any software product, you’ve likely run across documentation that was wrong, incomplete, or just out of date. When that happens, you’re usually out of luck. There might be a comment box, or you can ask your question on a forum.

We took a different approach with Fiddler’s documentation. If you notice something we messed up or is incomplete, let us know about it or send us a pull request with your update. No, I am not kidding. Our documentation is in GitHub. In fact, the link to each article’s content is on each article itself.

DocsPageCropped

Yep. That link will take you to GitHub. From there, you can Fork the repository and send us a pull request or just submit an issue letting us know what’s wrong. It’s simple and easy, and you won’t have to re-visit the same outdated, incorrect documentation year after year. We’ll leave that experience to other products’ documentation sites.

New Fiddler Site Released

I’ve been using the Fiddler web debugging tool for many years now. I first picked it up just after Fiddler2 was released, and it’s been an awesome tool the entire time. This is one big reason why I was very happy when I learned last year about Telerik’s acquiring Fiddler.

Having been a part of a Telerik acquisition previously, I know that Telerik is careful not to stir things up during these types of situations. For example, they’re not the type of company to step in and throw their branding everywhere. (It will be there, but just not be too overt.) It also meant that Telerik would be getting Fiddler the support, upgrades, and growth that it needs.

My favorite part of this whole turn of events is that I got to lead the team of developers implementing the new Fiddler Website. I work with a fantastic group of people who usually don’t, but probably should, read my blog (they’d see comments like these).

I always got a good laugh when installing Fiddler on my computers. The previous site was a bit outdated. I think the problem with the previous site is just that Eric didn’t have the time for updating the site. I’d say we were all lucky he was updating the product.

Thanks to the Wayback Machine, you can take a look at some older versions of the Fiddler site. I’ve included a screenshot of one of those here for you.

OldSite

This is the type of design that I am best at. I refer to this as “Developer White”. Developers have no problem with sites like these. Some of the best tools on the Internet are hosted on sites just like this (see Fiddler for the past 5+ years). They often get a laugh here or there, and aren’t always the easiest to navigate. That download link in the middle always looked like a text ad trying to get me to download some random unrelated tool.

This isn’t the first update since the Telerik acquisition of Fiddler. There, of course, was a public announcement on the site for a while before we were able to start working on the upgrade. If you visited the site last week, it would have looked roughly like this.

IntermediateSite

For anyone who didn’t know, there were two places in the old Fiddler site with scrolling marquees. I kid you not. Go check out the Wayback Machine if you don’t believe me.

Now the Fiddler site has a new, spiffy design. Consider this a prelude of a great deal more support for this product that we all love. Hooray for Fiddler!

NewSite

Please let me know what you think about the new site!

Note: I didn’t design it, and I don’t build Fiddler. I can, however, pass your feedback on to those who did.

Replaceable Employees

Some of your best employees are your most replaceable ones. To top things off, that’s what makes them good employees. Someone who is not replaceable is a problem waiting to happen, and the sooner you can replace them, the better.

While my statement runs contradictory to most of what I’ve heard from other people in my life, I don’t think what I’ve said is really all that crazy. If you’re in the software business, you’ve probably heard of the term “Bus Factor”.

“The bus factor is the total number of key developers who would need to be incapacitated (as by getting hit by a bus/truck) to send the project into such disarray that it would not be able to proceed; the project would retain information (such as source code) with which no remaining team member is familiar. A high bus factor means that many developers would need to be removed before the project would necessarily fail.” – WIkipedia January 2, 2013

It’s really just a measure of how well your organization is sharing its information. If you’re doing well, your bus factor is a large number. If you’re not doing well, your bus factor is 1.

Think about that for a minute. What that means is that you want to have employees who share their information. Sharing information means that more people have the information. This means that the employee can easily be replaced, however, you’re not likely to replace someone who shares information with the rest of the team. If you replace that person with someone who doesn’t share the information as well, you could hurt your bus factor.

Now you’re thinking about long-term benefits. It turns out that if you silo yourself off on a project and don’t share information with anyone else that you’re hurting the company. I think everyone knew that already, but these people are often said to have “job security”, because losing them would be a problem. Well I think that’s crazy, because it’s dangerous to keep that person around! If you keep that person around longer, it will only mean creating more information silos. This is an issue that can only get worse, and one you’re better off solving now.

If you’ve got employees holding this information, you can either get them sharing it or replace them. If they’re not willing or able to start sharing their information, you need to replace them now. Yes, it will be bad when someone knew has to learn what that person was keeping secret, but it could only have gotten worse. Eventually, you would have been very dependent on that person.

Keep in mind that you’re not doing this so that you can replace your team for the sake of doing it, you’re doing it in case something comes up. If an employee of yours is hit by a bus, out sick, or just on a vacation, it’s nice to know that others can pick up the slack. You keep employees who are easily replaceable. They’re your best ones.

Ball Flow Like Champs

I enjoy the Agile Ball Flow Game. It’s a challenge that emphasizes a lot of what agile practitioners find value. The theme of the game is that you’re working in a toy factory and you create toys by passing them around to the other workers. Each worker needs to touch the toy at least once, no two workers can touch the same toy at the same time, and you can’t pass the toy to the person next to you. As orders come in, you try to complete the orders as quickly as possible. If you mess up one of the toys (drop it), you have to start over creating the toy.

In the game, you want to keep track of when you start making each toy and when each one completes. This lets you track your lead time, cycle time, WIP, etc. From this information, the group can see what works well and what doesn’t. They can determine how to adjust their process to improve their toy-making abilities.

At the Hudson Software Craftsmanship meeting earlier this week, we performed the agile ball flow game. No one there had done it before, so it was a great opportunity to see how they would organize themselves and complete the solution. In total, we had 14 people at the start of the game.

Round 1

I started the group off with 20 multicolored balls. The hollow plastic variety commonly found in children’s ball pits. They’re easy to toss short distances, but can be tricky for a long distance toss.

They first created a circle to facilitate passing. One thing they did very right was passing 1 ball around as a demonstration so that the whole team could practice and get an idea of what they were going to be doing. Much better than just assuming that everything will work as expected!

They completed the full order of 20 in just over a minute and thirty seconds. A few of the balls dropped, but were picked up and reintegrated into the process. Their effective process worked so well, because most of the team had enough slack to not feel overwhelmed.

Round 2

In the second round, the team estimated that they would be able to complete things faster. They estimated the time to complete to be around 45 to 60 seconds.

As part of their retrospective, they realized that their pull model they were using worked effectively, but if they shifted forward and backward a little bit, they could pass more easily. This was their slight adjustment to the process.

It worked! They managed to keep more balls from falling in the second round and really improved their time! They noticed that their issue was in contentious passes around the circle, and they adjusted to account for it. Well done! They were a hair under 40 seconds, which is the fastest second round time I’ve ever seen.

Round 3

Kids these days aren’t just interested in those old-style toys, which means that the challenge needs to change a bit. They’re still fun, but the new thing is dart guns, so now the team needed to also pass around foam darts. With such a well oiled machine, could these darts present a challenge?

The darts are tricky, because one end is rubber and weighs a bit more than the other end. These were obviously more challenging to pass, and the group spent some time discussing how they would work.

The team decided to start with the darts to get the more difficult items out of the way first. At first, this seemed to work, but darts started falling. After starting most of the darts a second time, the group ended up with a time just over a minute and twenty seconds. Not bad, but quite a fall from round 2.

From the retrospective discussion, the group established that they needed to drop the darts into people’s hands. Tossing just wasn’t working well. They also decided that they should probably send multiple darts at a time since they were going to be dropping them, it should be safe to do.

Round 4

Armed with a new plan, the group decided to start the darts 5 at a time, which would mean 2 sets of darts traveling around the group.

Not surprisingly, only 3 darts of each set made the round trip. Still probably an improvement, but it might have been better to have done 2, 3, or 4 darts at a time instead. Perhaps something to try in the future.

This round was full of dropped items and ended with 1 dart making the rounds all alone. In the end WIP was just 1 for the whole group. The time wasn’t bad, but it was obvious that the group could do better. So far they hadn’t made any huge gaffs either though.

Round 5

This round was about being more careful and getting the passing in place as best they can. Perfect answer, team. They knew not to make big changes. What they were doing was working, and they were seeing improvement. A big change here would just upset things.

The group finished on a high note, being one of the more successful groups at ball flow that I’ve seen. They completed the challenge like champs. Not once did they try something crazy like shooting WIP through the roof (I’ve seen it!)

Agile tells us that we need to limit WIP and bring cycle times down. Those are the focuses of the agile ball flow game. It lets the group self organize through planning, spiking, testing, and doing retrospectives. If you want to teach a team about agile, the ball flow game is a great way to do it!

I primarily use Karl Scotland’s method of running the agile ball flow game. Make sure that you also use this spreadsheet template when running the game. It makes tracking times much easier.

Calendar Coder

If you didn’t get yourself a 2012 Software Craftsmanship Calendar, I hope you’ve at least been following along with my blog posts. My favorite of the months is finally here. In the 2012 Software Craftsmanship Calendar, we included our own variation on an anti-pattern. December is Calendar Coder month.

CalendarCoderSmall

Jesse Williamson had a spectacular tweet that confirmed exactly what we were looking for when we came up with this idea.

Just got trolled by my 2012 Software Craftsmanship calendar. Well played, inanimate object, well played.

Yes, that’s right. After you’ve followed along with the calendar all year, accepting guidance as the calendar turns anti-patterns into jokes that make you rethink some bad practices, the calendar turns on you. I really think that the calendar is useful, but there is no substitute for thinking. Make sure that what the calendar says makes sense. Blindly following everything the calendar says to do is just silly.

Do you recognize from which anti-pattern we derived this one?

It’s called by many names: cargo cult, angry monkeys, etc. If you’ve ever heard the story about needing to cut the ham in half before you bake it, that’s the same story. It is the practice of following along without knowing why you’re doing something. If you read the calendar and don’t know why you should do what it says, you’re a Calendar Coder. If you learn why, agree with the reasoning, and it’s applicable to your situation, then you will want to follow what the calendar says. Don’t just blindly follow along though.

I hope everyone enjoyed the calendar. If you did, the new ones for 2013 are on sale right now.

Buy your 2013 Software Craftsmanship Calendar today!