Brendan Enrick

Daily Software Development

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.


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.


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!


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.


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!

Copy Paste Programming

One of the most well known anti-patterns is copy paste programming. I am sure that every programmer has done some copying and pasting of code. It’s easy to do and can make writing code a lot faster than just writing new lines for everything.

You might have done something very similar to what you need now. All you have to do is copy the previous code and update it to fit your current needs. What could possibly go wrong?

I don’t think I need to explain why this one is bad. I think it’s easiest to just say that more code means more maintenance. It makes things messier, harder to read, and harder to change.

The month of September 2012 is the Copy Paste Programming month in the NimblePros Software Craftsmanship calendar, so consider this your reminder to stop copying and pasting code. You should know better already.


I loved how well this image turned out. I’m sorry though, it’s not OK to copy and paste your code. No, it doesn’t matter that you’re making slight changes each time you copy it. Just don’t.


One of the agile communities mocking terms of the old-fashioned Waterfall development technique is, “Waterfail”. It is called this, because the community credits this technique with being part of why a lot of projects fail.

The main difference between this technique and most agile techniques, is that waterfall does one big flow of everything. It does not loop through the process as most agile techniques do. It attempts to have everything planned out so that you’re just going through the motions toward success.

I’ve been posting each of the topics from the NimblePros software craftsmanship calendar as we get to the month. With each of these, I am mentioning that you should work on trying to follow the good practice or avoid the anti-pattern. Since this year’s calendar is on anti-patterns, it included Waterfail as something to avoid.

So for the month of August, I am going to recommend trying to move away from Waterfall. I’m not saying that you should suddenly move from a Waterfall project to some form of an Agile project. At least start looking into the possibility. Read a book on agile, go to an agile or software craftsmanship user group, access online resources for learning agile techniques, or attend a conference with an agile track.


I really liked how well this image turned out, and if you didn’t notice, we wrote “Waterfall”, but we cut part of the first “L” to make it appear to say “Waterfail”. Just one of our subtle little tricks in the calendar.

Go here for a more thorough analysis of Waterfall.

Three Years of Software Craftsmanship

Almost three years ago, Steve Smith, Rich Henning, and I founded the Hudson Software Craftsmanship Group (HudsonSC) in Hudson Ohio. We scheduled our first meeting for August 19, 2009 and we had plenty of people show up. Since that time, similar groups have sprung up in NE Ohio and other areas around the country. It’s really neat to watch as the software craftsmanship community grows. There are other groups, dojos, workshops, etc. all over the place.

Our group has been a model of other groups around the area as well. Brian Friesen attended one of our meetings as a bit of research before starting the Knoxville Software Craftsmanship Group. Brian Friesen is quite dedicated, because the drive up to HudsonSC is over 8 hours. What that means is, if you’re in that area and want to attend a meeting with a dedicated software craftsman, check their website regularly they’ve always got their meetings posted.

Our number of attendees fluctuates between highs of 20-30 people down to lows of 5-10 people. We’re usually somewhere between 10 and 20 attendees. These numbers are great for a group like ours. If you get much larger than this, it becomes nearly impossible to have a discussion.

How Software Craftsmanship Groups Stand Out

We’re not eyes-front, pay attention to a speaker kinds of groups. If that’s what you’re looking for, HudsonSC is not for you. There are plenty of groups that meet every month across the world that have this format. We focus on discussions and self-organization. Our members suggest topics they want to discuss. We try to get everyone contributing instead of just taking notes on someone else’s “wisdom”. Everyone in our group has something to bring to the table and adds value to the community as a whole. You can take notes after the meeting.

HudsonSC’s Agenda:

  • Introduction
  • Lightning Talks, Show and Tell, and Opening Discussions
  • Open Spaces and/or Group Discussions
  • Exercises (usually programming)

Our members bring laptops to the meetings so that we can write some code and pair with other people. Our group is not buried in their laptops nor is it tweeting away. When you attend a software craftsmanship group, you participate in the event. You are the speaker!

Third Anniversary

As I mentioned at the beginning of this post, it’s been nearly 3 years since we founded the group. Our third anniversary meeting has been scheduling and you can sign up for it now. The event is going to be held on August 15, 2012.

To celebrate this event, we’re going to have a spectacular evening or talking, discussions, and programming exercises.

I look forward to seeing you at our next HudsonSC. If you’re not in the area, go check out your nearest software craftsmanship group!

Sign up for HudsonSC here!

There is no “ego” in “Agile Team”

Programmers are talented, smart, skilled professionals. We put in lots of our own effort to educate ourselves and stay up on current technologies. We work hard and we feel great satisfaction in our achievements. We donate our time to charities when the opportunity arises. We give back to our local communities. All things considered, there are a lot of really great programmers in the world.

I lead a team of software developers. Does that mean I am the “best” programmer on the team? Certainly not. It just means that I lead the team. As the leader of the team, it is my job to: inspire, encourage, trail blaze, and motivate my team to be the best they can be. So who is the best programmer on my team? I don’t know, and I don’t care. There shouldn’t really be a “best” programmer on the team. Everyone on the team is great and working hard.

A team that really meshes and works well together doesn’t let egos get in the way. It doesn’t matter if you’re a rock star developer. When you’re on the team, you’re part of the team. You might be the JavaScript expert, the master of SQL queries, or the guy who can refactor anything. When you’re part of the team, you should try to use your strength, but don’t let that interfere with the team’s flow.

WP_000518Sometimes it makes sense for a more experience developer to work with a less experienced developer. A common first instinct is that the senior person is mentoring the junior person, but it’s actually going both ways.

Each of the two developers is bringing a lot to the table. Their different experiences and views allow them to each approach the problems differently, ask different questions, and apply different, existing knowledge.

If either person’s ego gets in the way, it would prevent the 2-way knowledge transfer in addition to creating friction between them.

WP_000541One Developer and one Junior Developer can pair on a task and share knowledge. Does one act like the other one is just along for the ride? No.

Your pair partner, is watching your back, guiding the team, and keeping the pair honest. Which one does that job? Both. If you had one person drive the whole time, you’re not going to see the benefits of pair programming.

If you let your ego get in the way, you might not let the junior developer write any of the code. They may not know every library, every design pattern, or even the intricacies of the language they’re using, but those guys can write some great code.

I don’t know how the Junior Developers are on your team, but ours write great code and show a high level of professionalism in their work.

RichAndEricAnd sometimes you get a Junior Developer pairing with the Developer Intern. How the pairs split up doesn’t really matter. Who is working with whom doesn’t really matter. Each and every member of the team is bringing something to the table, and it is this interaction that is making the team as effective as it is. These two are as productive a team as any other pairing that we’ve got.

Someone is probably reading this and thinking I am crazy for letting a Junior Developer and a Developer Intern pair together. They’re good though, and they really get great stuff done.

We can accomplish a lot of stuff when our team works individually, however, we can accomplish a lot more as a group. You might be the “best developer” on your team, but if you keep thinking and acting that way, you’ll be missing out on a lot. I learn a lot when I pair with any member of my team. It doesn’t matter how much experience the person has. Everyone knows something I don’t, and no one approaches the problems exactly the same way I would.

There is no “Ego” in “Agile Team”, so don’t bring yours to an agile team and expect good results.

TODO Comments - Code Audits #9

When writing software, we often have to write comments to explain why we did something.  I try to write my code such that I don’t have to comment it. In fact, anything other than a temporary (less than a few minutes) comment I write, I consider to mean that I made a mistake.

We could get into endless discussions of when we should comment, what we should comment, and how much we should comment. I’ve had plenty of discussions about comments with people with various opinions on the subject.

An interesting feature of Visual Studio is that it lets you create a list of “tasks” by leaving yourself comments that begin with “TODO” or “HACK”. In some ways I like those comments, because they build into the code reasons for why the code is the way it is.

If you write “TODO”, it tells the reader that the code is incomplete and that wasn’t intentionally left the way it is. There just wasn’t enough time. If you write “HACK”, it admits that you wrote the code badly and it needs to be rewritten.

These types of comments fit in very well with what I tell people about comments. Each one I write and leave in the codebase means that I didn’t write the code as well as I wanted to. Each one is my mistake. The more comments I write, the worse the code is.

The Bad

One codebase that I was working on had a lot of these comments. It seemed they were all over the codebase. There was the other problem that copy-paste coding was rampant, so I am sure that many of these were copied and pasted from previous locations. Heck some of the even said to remove the duplication. The irony? Those comments about removing the duplication were copied with each new instance of the code that was copied.

I checked Visual Studio’s task list of these comments just to see how bad it was.

1131. 1131 tasks that were indicated with “TODO” and “HACK” comments. That takes more than just writing a lot of these comments. That requires writing them and never going back to fix them or complete them.

The Better

Check your codebase right now. Do you have any of these comments lying around? Is it only a handful? If so, you should go try to clean them up. That’s easy and will help you out down the road.

Anytime that you’re going to write a “TODO” comment, think about why you’re putting it there? Is it something that’s really needed? If so, make yourself a note somewhere else. Add a story to go back and make the change later. Get it in the system where you really track your work.

If you know that you’re not going to get to it any time soon, don’t bother with the comment. It will only clutter up your system. If it’s not important enough for you to come back and get it soon, why are you even recording it? If it’s important later, you will be working in that part of the codebase again and you can go back later and fix the code as part of your other work.

Certainly once you get that many of the comments, you should have long earlier realized that there is something that you need to work on. That’s just a ridiculous number of TODO and HACK comments for one codebase.

Has anyone ever see more than that? Anyone think I am crazy or wrong? Tell me about it in the comments!

More Code Audit Nuggets

Keep watching for more interesting nuggets of stuff that I’ve seen in codebases.

Locks and Keys - Code Audits #8

In software development, it is common to have users authenticate using usernames and passwords. In order to handle the authentication process, we must store this information in some way. Obvious, passwords should never be stored in clear text. Toward that end, when we store them, we encrypt, hash, salt, etc. to keep them safe.

While these steps cannot protect against all forms of attack, they’re a good base of protection to have in place. We don’t want to just give this information away to anyone who wants it. Yes, some people could take the non-clear-text passwords and obtain the original password from it, but we’ve certainly set the barrier higher.

Security is all about setting more and larger hurdles in place for people to jump over. The only secure information is information that doesn’t exist, and that becomes inherently insecure as soon as it does exist. If information is accessible to someone, it means that it’s possible for someone else to access that information also.

We just try to make things more difficult and limit that damage. Or at least some of us do.

I’ve made plenty of my own mistakes in the past. Some of the applications I wrote in college have security holes, which seem glaring to me now, but I’d not even noticed at the time I wrote the code. I’m sure that most people reading this would say the same thing about their own code.

The Bad

One of the systems I had the pleasure of seeing the code for, at its core, was a customer portal. It even had its own custom ecommerce solution. (These details while talking about security issues will have some of you facepalming already.)

The developers knew that they needed to encrypt the passwords, so they wrote some sql, dbo.encrypt, to encrypt passwords before storing them in the database. Insert a password and out comes a jumbled mess that no one could read.

Users will often forget passwords, and will need some way of recovering from this situation. I recommend resetting passwords when this happens. This application took a different approach.

Also stored in the database was some other useful sql, dbo.decrypt, which would take any of the encrypted passwords and decrypt them. Well that’s obviously a security issue, but the worst thing about this isn’t just that it’s reversible. It’s that this is also in the database. That means that we have the lock and the key together. If someone gets read-only database access, but not access to the application’s source code, they still have everything.

It’s like have a lock and keeping the key inside the lock for convenience. I wouldn’t want to have to call a locksmith if I ever lost the key, so I just keep it here. It makes opening the lock faster too!

The Better

Don’t allow reversing of stored passwords. Use 1-way only when dealing with passwords. This way brute force techniques are required to figure out a password.

If the system can reverse the password back to the original, anyone who has obtained access to the system can retrieve all of the passwords.

This isn’t a new idea. You’re not the first developer to set up authentication in an application. There are plenty of existing authentication systems out there. Don’t reinvent the wheel if you don’t have to. Some systems are safer than others. Ask around. Talk with security experts (I am not one of them) about these if your application requires really high hurdles.

More Code Audit Nuggets

Keep watching for more interesting nuggets of stuff that I’ve seen in codebases.