Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 1

Ground Rules for User Demos

November 17th, 2010 · 2 Comments

User demos are a great way to get early feedback on the direction of a feature that is under development or has been recently finished, but they can very easily become dreaded interactions between customers and developers if a few simple ground rules aren’t observed.

  1. Developers need to be clear about what is and isn’t finished.
  2. Customers need to pay attention to what is and isn’t finished and take that into account when they are providing feedback.
  3. Demos are NOT a replacement for acceptance testing – they should not result in a story being accepted or rejected.
  4. Demos are a means of getting EARLY feedback about a feature. Users should expect to find things they don’t like and be prepared to address them CALMLY.
  5. Developers should expect users to find things they don’t like and be prepared to address them CALMLY.
  6. Sometimes a developer will show a user a feature that is not finished. When that happens, users need to be extra careful to be NICE and to limit their feedback to the questions the developer is trying to find an answer to.
  7. When a developer shows a user a feature that is not finished, they need to be clear about 1) what’s left on the to-do list 2) what they need feedback on.

Demos should be used for collecting valuable early feedback and re-directing development with a minimal amount of wasted effort. Customers need to be real careful that they don’t turn demos into “punishment” sessions for bad developers who did a poor job reading their minds. They need to be willing and able to see the application in a tentative state and must avoid insulting or demeaning language at all costs when things aren’t up to their standards, no matter how disappointed they may feel. Failure to do this will end early user demoes almost immediately as the developers figure out how to deal with animosity in healthy ways.

→ 2 CommentsTags: Uncategorized

So long, Indy!

November 10th, 2010 · 5 Comments

In a few weeks my family and I are going to move to the Chicago area. This is a big deal for us – we’ve lived in the Indy area for almost 9 years and we’ve loved every day of it. We are going to miss the friends and family (some biological, some adopted) that we have made here and hope that Chicago isn’t too far to warrant an occasional visit. Just thinking about our impending move hurts all of us inside, but we are convinced it is the right thing to do for all of us.

Thanks to everyone who made life in Indy awersome for me and my family – our neighbors, our friends from church, my colleagues from my days at Liberty Mutual, and my friends in the Indy tech and ruby scene. I’ll especially miss Indy.rb and am sad that I won’t be able to keep participating in Indy Hackers & Founders after this month.

I’m also disappointed that I won’t be able to lead the charge to create an Indianapolis Lean Startup Circle ( as I had originally planned. This brand new meetup is going to need a new organizer – please contact me if you are interested.

This has been a really tough decision for me, and it was one that by necessity had to be made in a very short period of time. I hope it won’t be the end of the friendships that we’ve formed over the last nine years.

To my indy.rb pals… You’ll still be able to find me in #indyrb, at least until you guys kick me out for being a foreigner.

→ 5 CommentsTags: Uncategorized

Why Testers Should At Least Consider Learning to Code

September 21st, 2010 · 3 Comments

About six years ago I found myself in the middle of a major crisis. An enterprise service bus that I had designed and built was falling to pieces in production. Performance was going through the floor and it was shutting a major part of our business down. The CIO gave us his office as a situation room and we had directors dropping in every half hour or so for updates. I was told to take anyone I wanted off of any project in the company and put them to use. I picked an architect, a performance tester, some devs, and a tester named Mike Kelly.

At one point in this ordeal, I needed some data from the logs. Specifically, I needed to pull all the timestamps out of the log for specific lines, then dump them in a spreadsheet, do some math, and make a chart. I started explaining to everyone in the room what I needed, and before I was even done, Mike Kelly turned his laptop toward me and said “You mean like this?”.

Anytime I see the “should testers code” debate, I think of that moment. Mike Kelly wrote a ruby script in just a few minutes that parsed the logs, pulled out the the timestamps, and dumped them in a csv file. Over the next day or two, he ran that same script probably a dozen times as we tested various theories about what was going on, until we finally isolated the problem and fixed it.

I’m not saying coding will make you a good tester. Or that not coding will make you a bad tester. Talent, practice, curiosity, and constant learning will make you a good tester. If Mike Kelly couldn’t code, he would still be the first tester I called if I had a testing problem I couldn’t handle myself.

But the point is he can code, and because he can code he is more versatile than he would be if he couldn’t. This is why I think every software tester should at least consider learning to code – even if all you do is learn some simple scripting tricks (the one Mike used to pull timestamps out of logs is only a few lines of ruby), you will be better off as a result.

Being able to code comes in handy, but it’s not a deal breaker in becoming a good tester. Interestingly, it also seems to be becoming a requirement in more and more testing openings. I’m not sure that’s a good thing – it could be a culture smell. It makes me worry that an organization has an undisciplined development approach, or a lot of tech debt if they need testers to write code. Or they could have a misguided belief that some “enterprisey” test management tool is going to save them – all they need is testers to come in and configure the thing. At any rate, buyer beware. Go into those gigs with your eyes wide open.

That said, the job I currently have came to me because I’m a tester who can also code. I started out paying down technical debt on TriSano by writing UATs using RSpec and Selenium. After I figured out a basic approach, the devs added UATs to their very disciplined dev approach and I stopped doing them and focused on something I’m much better at: exploratory testing of new features as they were delivered.

I almost never write automated tests anymore, except when I find an easy bug and decide to fix it myself and need to update or create a test in the process.

In the process of writing those tests, I began to discover something that I had forgotten: how much I like to code. Sometimes I like it more than testing. My interest in learning to code again sprang directly from the work I did automating those tests. I dived into Ruby on Rails and loved it. That led to launching TroopTrack 2 1/2 years ago.

Today, I would feel just as comfortable applying for a developer job as I would a tester job or a project manager job, and I like the versatility that comes from having skills in more than one software development discipline. It feels… well rounded.

You might decide, as a tester, that coding isn’t right for you. Perhaps you don’t like it. That’s cool. I’m not saying you have to learn to code to be an awersome tester. I’m just saying that you should think about it. Maybe even try it. If you pick up the coding hammer and it feels like a tool you might like, put it in your tool bag and use it when the time is right.

→ 3 CommentsTags: Uncategorized

Rails Workshop Topics

August 12th, 2010 · No Comments

I’m noodling teaching a 3 or 4 day rails workshop. Here are the topics I want to cover:

  • Rails Basics
  • REST
  • Plugins/Gems (will_paginate)
  • Deploying with Heroku
  • Authentication
  • Testing
  • Localization/Globalization
  • Mobile
  • Print

I think the course will be based on my demo app, – over the course of 4 days we’ll build out the app with all the features mentioned above.

What am I missing?

→ No CommentsTags: Uncategorized

Looking for Some Crazy Sales Entrepreneurs

July 27th, 2010 · No Comments

TroopTrack isn’t “hard-wired” to Boy Scouts. It has an admin interface that I can use to create a unit type (currently Cub Scout Packs and Boy Scout Troops), define achievements for each unit type (Pins, Badges, Belt Loops, Etc), roles, training, positions, etc.

Over the past two years, I’ve had a number of ideas for other ways to use TroopTrack. For instance…
– Civil Air Patrol Units
– Old man clubs (elks, rotary, etc)
– Karate schools ( is available)
– Church youth groups
– Home schooling organizations

There are probably lots more.

I’m looking for a partner who will explore these opportunities, get good at configuring TroopTrack, set a few of them up, work with me to make the public TroopTrack pages support multiple products more effectively, and then figure out how to sell the accounts.

For each of these, you’ll get to set your own price and take a large chunk of the revenue from your particular unit type. A civil air patrol captain I met said he thought $2500 per unit was a pretty good price. A karate school might be willing to pay $200, I don’t know…

We can also sell a stand-alone license to organizations like church youth groups. In those cases, they would have a dedicated TroopTrack instance that supports only their organization. Then, we can also provide a business intelligence tool (like Pentaho) for creating any kind of report they want on their units. The price would vary depending on the size of the organization, but you would get to set it, as long as I can still make a profit after the cost of hosting.

Your responsibilities would be level one support for all your customers. In other words, you would look at all the support tickets and emails from your customers and take care of any non-coding issues, such as:

  • Adding new achievements
  • Resetting passwords (soon to be automated)
  • Questions about how to do something
  • Etc

Remember, this is software as a service, so once you sell a customer you keep getting revenue for as long as we keep them happy.

There you go. Let me know what you think. If you want to try this, send me an email:

Peace out.

→ No CommentsTags: Uncategorized

Things I Hate: A Quality Metric? And Beyond…

July 26th, 2010 · 2 Comments

I’m Running Out Of Things To Hate
If I were to give a name to the “theme” of the work I’ve been doing on TroopTrack for the past year or so, I would have to call it “Getting Rid of Things I Hate.” Here’s what I’ve been doing:

  • Making controllers restful
  • Making the user interface easy to use and consistent
  • Fixing bugs
  • Removing or simplifying needless complexity
  • Replacing home grown bits with plugins/gems as appropriate

My prioritization process has gone something like this:

  1. What parts of the app make me want to punch my monitor?
  2. What do I have a good plan for fixing?
  3. What will matter to my customers?

A year ago the list of answers to #1 was really pretty long. Today, it’s down to just two bits – TroopTrack’s homegrown authentication system and the user_profile controller and views. This is not to say that TroopTrack is now perfect, but the remaining problems do not reach my punch-the-monitor threshold required to be on the list of things I hate.

Is This a Quality Metric?
I think it is. It might be a good idea to keep a list of all the things people (including you) really, really hate about your product. Consider opening this list to developers, product owners, testers, and yes, customers. Set some threshold for what you mean by “hate”. It needs to be stuff that is more than just irritating. It needs to inspire rants, push people to take walks to calm down, tempt ex-smokers to reach for a pack, etc.

Getting Past Hate
I think I will have 0 punch-the-monitor features left by mid-September at the latest. Then what?

Will I take a break and just tweak the app for a bit? Will I launch into new development for features I haven’t thought of yet? Will I focus on marketing and business development, something I’ve completely ignored for the past year?


One thing I’ve been thinking about lately is the applicability of TroopTrack to other things. Even though it is currently focused on Boy Scouts, it has the capability to support any organization that has similar needs to a Boy Scout troop. Some examples I’ve thought of include:

  • Paramilitary organizations like the Civil Air Patrol
  • Church youth groups
  • Home school education providers
  • Girl Scouts
  • Scouting program outside the U.S.

TroopTrack has finally reached the point where adding support for these organizations is simply a matter of configuration, not coding. Perhaps it’s time to start adding support for them as well.

Another thing I’d like to do is really flesh out the capabilities of my web page editor. I want to create a catalog of hooks back into the application so they can make data-driven web pages using their troop data. I also want to give them some more flexibility in the design and layout of their pages. I don’t really know how to do this yet, so it’s a good opportunity for some learning. Perhaps I will finally conquer the dreaded javascript.

→ 2 CommentsTags: Uncategorized

What is a tester’s job?

July 20th, 2010 · 5 Comments

Melissa Bugai (@melbugai) from Atomic object asked the question “What is a tester’s job?” in twitter today. After a few 140 character attempts at succinct answers I gave up and decided to write a blog post about it.

A tester’s job is to make the product better
I admit this is a simplistic claim, so I think I’d better explain what I mean.

Being a tester is much more than just finding problems. I’ve seen testers who are extremely good at finding bugs but fail to turn those bugs into substantial improvements for the product they test. Why is that?

Sometimes it’s because the tester is not a good bug advocate. They aren’t able to convince developer’s, managers, and stakeholders that a bug needs to be fixed. They try, are ignored, and then become irritating jerks when the bug is exposed in a production environment and begin taunting everyone else.

Sometimes it’s the result of crying wolf. A tester thinks every single bug they find, even the obscure boundary bug that only happens when you paste 10 million characters in a text field, is critical and must be fixed now. They escalate on everyone who tells them to chill out until everyone is sick of them and their bug reports are all ignored.

Sometimes it’s because the tester is out of sync with the development team. Maybe they are testing so far behind the dev team that they’ve lost interest in the area the tester is focused on. Or perhaps they have gotten ahead of the dev team and are testing stuff that doesn’t make sense contextually.

These are skill issues that can be taught, coached, and improved. More concerning to me is the third reason this happens.

Sometimes it’s because a tester doesn’t believe it’s part of their job.

“I just find the bugs. What you do with them is none of my business.”

I don’t care for this detached approach to testing software. You can’t coach a tester into caring about the product they test – first you have to remove their head from the dark body cavity in which it is embedded.

But… but… you argue. If they find the same bugs as a tester who cares what difference does it make?

Well, that’s not likely. They won’t find the same bugs. Their testing will be cursory and focused more on creating the impression that adequate coverage has been achieved than finding the bugs that matter the most in the context of the product development effort.

It’s sad to see a tester with otherwise good skills who is so ambivalent to the outcome of their work that they don’t even try to see it in the larger context of effectiveness as an individual CONTRIBUTOR.

A tester cannot succeed independently while the team fails

A tester who doesn’t make the product better is failing. It might not be entirely their fault – maybe the organization has unhealthy incentives to ignore them. Maybe the developers are sensitive jerks who can’t take criticism. Maybe the managers don’t know a critical bug from a mis-spelled word in a EULA. Whatever. It doesn’t matter. If all that stuff conspires to make you fail as a tester…

You still failed. You did not accomplish your job.

Sorry. It’s a cold cruel world kids.

→ 5 CommentsTags: Uncategorized

The Best that You Can Hope For

July 20th, 2010 · 1 Comment

A True Story
Years ago I lived in a small city called Nobeoka on the eastern side of the island of Kyushu in southern Japan. Nobeoka, as I remember it, is built on a coastal plain wedged between the Hyuga-Nada Sea on the east and steep mountains in every other direction. There was only one train track through the city, coming down from Saiki in the north, through Nobeoka, then along the coast to Hyuga in the south. Southbound trains would stop in stations so that northbound trains could continue on their way back toward Fukuoka, the largest city on Kyushu.

Nobeoka was the first Japanese city I called home. I lived there for six months and it served as my indoctrination into a world that was both completely alien and totally fascinating. I loved the food, the language, the land, and the people. Every morning, as I rode my bike through town, I marveled at the ingenious ways in which the Japanese had merged their world with the natural (and sometimes harsh) beauty that surrounded them. Green was everywhere – it surrounded the town in every direction but the east, blanketing the mountains that pinned Nobeoka against the sea.

One thing that took a bit of getting used to was the toilets. Although I understand that Western toilets are very common in Japan now, in 1992 rural Japan they were neither unusual nor were they commonplace. At any given public restroom, you had a 50/50 chance at best that you were going to push a stall door open and find yourself face to face with a squatter.

Many gaijins are bothered by squatters. It can take a bit of getting used to if you haven’t grown up squatting in the brush on campouts to relieve yourself. Some gaijins had mental lists of which department stores and restaurants had western toilets and which did not, but that wasn’t me. I didn’t care. Once I had figured out the basic mechanics of the thing I was pretty comfortable with it.

Except for one time. One day, I rode my bike about 20 miles out of town to call on a family that lived fairly deep in the forested mountains around the town. The ride was spectacular and exhausting, winding up mountainous roads with steep drop-offs on one side and walls of rock and exploding greenness on the other. At last we arrived at the house we were looking for, a beautiful home in an idyllic forest glade. The house was old, at least a hundred years, probably much more.

We enjoyed a fairly luxurious amount of food in this setting, sitting on cushions around a low table, chatting with the family and eating an endless stream of Japanese favorites as the day wore away and the evening sky fell. Just as my stomach was starting to become uncomfortably full, our host presented us with a plate of about ten disks of round cuts of meat, each about the size and thickness of a large coin. The meat was almost thawed – soft and red around the outside, still a bit frozen in the middle. A small amount of blood pooled around the edges of the meat, thin and watery. Shika sushi, the host informed us. Deer meat. Raw deer meat. “I shot it myself,” he added.

I’d never had shika sushi before, and I haven’t since, but I wish I could. It was delicious. The other gaijin who was there with me wasn’t so keen on the stuff, so I was able to eat more than my fair share. I won’t lie. I loved it. It was like nothing I had ever tasted before. My brain told me it was gross, unsafe, and unhealthy, but my tastebuds told me a different story. My intestines, on the other hand, told me that it was the last straw. It was time for me to go to the bathroom.

I’ve always been prone to overeating, even when I was young. I still am, and it shows. That night was no exception, and out of some perverse sense of politeness I waited until my need was urgent to inquire about the location of the toilet. In a house this old, I could hardly expect a western toilet, but what I found instead terrified me. It wasn’t that it was a squatter. I was fine with that. The problem was the tiny closet the squatter was in. It wasn’t build for 6’1″ Americans. It was built for somewhat shorter Japanese people. The ceiling was practically on top of me, and the room was just barely wider than I was, and not much deeper.

I stepped into the room, pulled the door to, and proceeded to squat. I stopped half-way down when my knees banged against the door and my butt hit the plumbing behind the toilet. I pulled up and looked at the squatter in disbelief – the room wasn’t deep enough, or I was too tall. I couldn’t squat OVER the toilet. My knees would bump up against the bathroom door, pushing my butt out of range of the squatter’s gaping hole no matter what I did.

My intestines let out a rumble. They were unhappy with me. I had taunted them with relief and then denied them. They weren’t having any of it, but what was I supposed to do? I couldn’t use that bathroom, not without missing the toilet or … Was there another option? I knew there was, but I didn’t like it. The bathroom was too close to the room in which people were still enjoying each other’s company. The bathroom door might even have been visible from there. Still… what choice did I have?

In the end, I did the only thing I could do, as quickly as I could manage it. I opened the door, letting it swing as wide as it needed to, then squatted over the ceramic hole in the floor and took care of business. It was loud, it was humiliating, and soon it was over.

When I was finished, I collected my wits and prepared to face my friends. I decided that our hosts were probably embarrassed that their bathroom was so small and unlikely to comment. Only the American I had come with would be interested in humiliating me, and maybe he hadn’t noticed. There was a chance no one else was going to say anything about what had just happened, so why should I? I put on the most dignified face I could manage and stepped back into the main room as if nothing had happened.

No one said a word about the incident. Not then, not ever. Apparently my gastrointestinal exuberance had gone unnoticed by our host and by the other guest. Thank goodness. I knelt back down on the cushion, took a sip of my water, and helped myself to a dumpling. It was a great evening.

The Moral of the Story
What does this story have to do with software? How does it apply to Software as a service, testing, agile, or anything else I usually write about on this blog?

Not much. But I think it relates to yesterday’s post about how crappy some of my TroopTrack code is. Things don’t always work out the way they ought to. Sometimes you have to part with convention and do things a different way, just to make things work. Sometimes, you just have to do what needs to be done and not worry about what that means.

Sometimes, the best that you can hope for is to simply avoid the worst case scenario.

In my case, I had to settle for being happy that I didn’t wind up with a brick in my shorts and a 20 mile bike ride home.

→ 1 CommentTags: Uncategorized

Sharing My Code Feels Like That Dream Where I Show Up at School in My Underwear

July 17th, 2010 · 3 Comments

Lately I’ve had a couple of people volunteer to help out with TroopTrack. These are usually scouters who are also programmers. One of them is also a designer with a lot of Rails experience – I find that really, really exciting because there are plenty of places in the TroopTrack UI that make me want to put my fist through my monitor.

I was thinking about these requests and feeling a little embarrassed by the notion of nearly complete strangers poking around in my code. Some of the code really, really sucks. That’s a bit humiliating to me. Also, there are hardly any tests, which is a complete embarrassment given I’m a freaking tester.

The fact that there aren’t many tests is also a total hassle, as it means a lot of regression testing for me whenever I change something. It also means an unfortunate number of regression bugs as well, which drives my users insane.

When I think about other Rails devs poking around in the code, all sorts of insecurities kick in, but mostly it boils down to two things:

1) What if they decide I’m a crappy coder?
2) What if they decide I’m a weak loser when I blame some of the bad code on other people?

Ah, well, it’s nice to have insecurities sometimes to remind you that you’ve still got plenty of room to grow.

So, specifically, here’s my TroopTrack dirty laundry. This is the stuff that I find emabarrassing:
1) Some of the controllers are still not RESTful. I’ve converted most of them, but a couple are still crazy.
2) The home grown authentication really sucks. It needs to be ripped out and replaced with AuthLogic.
3) The before filters for limiting access based on roles are inconsistent and out of control.
4) The UI metaphor is inconsistent.
5) There are a few places where cascading deletes were implemented in the database
6) Just plain crappy code and missing tests, as I already mentioned.

There are other problems that I don’t really find quite so embarrassing – features that aren’t totally mature, etc – that I consider a normal part of software development.

So, what to do about this? I thought about it and decided to put all my dirty laundry right on the README. That way, if someone decides to contribute, digs into the code, and gets all mad about it, I can honestly say that I tried to warn them.

Software is hard. Sheesh.

→ 3 CommentsTags: Uncategorized

10 Seconds… Go: Exploratory Testing in a Nut Shell

June 17th, 2010 · 4 Comments

The Doit

Step 1: Take a tour of the feature
A tour is an exploratory testing exercise that helps you create a mental model you can use for planning your testing where you simply clicky around the feature and get a sense of what it does. A typical tour is aimed at answering questions like the following:

  • What does the feature do?
  • How does the feature vary by user?
  • What other features are related to this feature or impact the way it operates?
  • What capabilities are included in this feature?
  • What setup activities are required to make the feature operational or to customize it?

It’s important to take notes during your tour as you find the answers to these questions. These notes will provide the information you need for the next step: writing session charters.

Step 2: Write some session charters
Writing session charters is easy – all you really have to do is capture the mission of the charter. A mission is what you are trying to accomplish in a 30-90 minute testing session. Examples of missions include:

  • Try to find bugs in the happy path of adding a new person
  • Look for XSS bugs in the event data entry views
  • Look for bugs creating forms using IE7

Use your notes from step 1 to create these charters. You can record them in a spreadsheet, a wiki page, a notebook, whatever. Just leave some room for notes.

Step 3: Test away
Doit! Grab a charter and start testing. As you test, try to think of different variations of what you are doing that might matter and try those too. If you think of something else that should be tested that isn’t captured in the charters you’ve already written, pause for a minute and write a new mission down. Make notes of any bugs you’ve found, but don’t go submit a bug report yet.

If you encounter something related to the mission you’re on that looks strange or interests you for whatever reason, focus on it for a while until something else distracts you (that is consistent with your mission of course). Following your instincts in this way helps keep you mentally engaged and avoid “brain-dead testing.”

Step 4: Isolate and document bugs
After you’ve done a charter or two, go back over your notes and highlight any bugs you’ve found. Take each one and try to isolate them. An isolated bug is one for which the simplest path to repeating it reliably has been identified. Once you get there, then document it in whatever way your team reports bugs.

There are good bug reports and there are bad bug reports. Good bug reports:

  • Include information for reproducing the bug
  • Clearly identify the part of the system in which they occur
  • Clearly identify the outcome of the bad behavior (system crash, user confusion, etc)
  • Include the reason you think it is a bug (see oracles below)
  • Include supporting information such as screenshots and stack traces

Step 5: Take a nap

Testing this way requires energy. Most testers can only manage 3-4 charters per day before their brains start to melt and their productivity dips. It’s important to take breaks between charters and mix in meetings (the few we have) as well as other work. For instance, if you are planning on doing 3 charters, an expense report, a call with your boss, lunch, and some development, don’t plan on doing all 3 charters in a row after lunch. Instead, mix them in throughout the day to give your brain some time to recover.


Stay out of ruts

Use your domain knowledge
In TriSano, this means knowing things like

  • which diseases occur most frequently
  • which forms are longest
  • what reports are used for
  • how tech-savvy the users are

This could be different for your app, but what matters is that you have some sensible understanding of the problem your solving and how the solution is used in the real world. When you test, take this knowledge into account and put it to use by modeling real scenarios in your testing.

Pretend to be someone else
Here are some people you can pretend to be:

  • A slow reader
  • An angry user
  • A malicious user
  • A new user
  • A distracted or bored user
  • A user with a disability

Use oracles to find bugs

An oracle is a theory of error that tells you something is wrong. Here are the oracles I use most frequently, captured by the mnemonic “HICCUPPS”.

A bug could anything that is inconsistent with one of the following:

  • History of the product
  • Image of the product
  • Claims made about the product
  • Comparable products
  • User expectations
  • Purpose of the product
  • Product itself (i.e. similar things work differently elsewhere)
  • Statues or internal standards

For more information on HICCUPS, check this out:

→ 4 CommentsTags: Uncategorized