You’ve found a problem:
“Our test environment is down all the time”
You want to make sure you fix it as well as prevent it from happening again.
A popular approach is to use the Five Whys root cause analysis technique. People who are new to Five Whys often run into a couple problems right away.
Up or down the stack
The first problem is which kind of “why question” to ask. Given the problem above, you could ask the following questions:
- Why does/did this happen?
- Why does this matter?
Both are valid questions, but they each travel in different directions. Repeatedly asking the first question allows you to get down closer to the root cause(s) of the problem:
Repeatedly asking the second question will send you up to find the actual harm that the problem is causing:
The item that is your initial problem is very likely the cause of someone else’s problem.
It can be helpful to traverse in both directions when doing analysis, but in general, if you assume you’ve identified a valid problem, focusing on “Why did this happen?” will be the most beneficial.
How many whys?
The second thing that people get hung up on is the number of whys. This one’s pretty simple. It’s just a guideline, so keep askin’ till you can’t ask no more. It may be 3, it may be 10, but chances are that if you haven’t gone at least 5 whys deep, you haven’t found the root cause. Keep thinking!
After some hair pulling, I realized that it was a Custom Provider, and more specifically, a Custom Lightweight Resource (LWRP).
As it turns out, if you actually RTFM, then you’ll find this little nugget:
To ensure that an embedded lightweight resource can notify the top-level resource add use_inline_resources to the top of the file that defines the lightweight provider that is associated with that lightweight resource.
As such, I modified my provider thusly:
action :create do
When I talk to IT people doing traditional software development about developing software with Zero Defects, I often get blank stares or snickers of disbelief. Do I live in a fantasy land filled with bug zapping faeries and defect free code? Maybe, maybe not. Read on…
In the traditional software development model, developers build a feature and hand it off to QA to be tested. The QA team tests the feature and discovers a defect. The defect is logged, prioritized, and at some future date, addressed by the development team.
Delays are inherent to this system due to departmental and hand-off/communication issues. Developers have moved on to new features and don’t want to be interrupted. Likewise, QA doesn’t want to interrupt the developers.
At some point after all known “SEV 1” defects are fixed, a decision is made to go into production. The remaining known “low priority” defects may or may not ever get addressed.
In the agile software development model, developers and QA staff work closely together to define acceptance criteria before development begins. They communicate at least daily and whenever questions or issues arise. If QA discovers a problem, it is immediately fixed by the developers before the story is accepted. There is no need to log or prioritize the defect.
At some point, a decision is made to go into production. There are no known defects.
In either model, defects will inevitably be discovered in production. In the agile model, new stories will be created for them, which will be immediately prioritized and fixed rather than being placed on a defect list.
We started by trying to follow this article about using Jath . It seemed promising, but had some holes. Most notable, we were hesitant to make modifications to the core backbone.js. Doing this would have prevented us from easily upgrading to new versions, etc.
The current release version of Backbone (0.5.3) does not allow for easily adding the options we needed to the ajax request inside sync(). While perusing the Backbone source, we discovered the the current master version on GitHub had some enhancements that made our lives easier. Downloading the master version, we were now able to pass the new parameters in the options hash.
Be sure not to override the incoming options with a new hash. You must simply append (extend) to the incoming options.
The last step is to get the incoming XML converted to JSON so the rest of Backbone can understand it. Below is an example using Jath as described in the above link.
My first barefoot run was at the Recreation Center in Saline, Michigan (just south of Ann Arbor) back in January 2010. Since then, I’ve run there many times as well as run a 5K and a 10K. For most of the summer I ran outside, but as it began cooling off, I went back to the Rec Center treadmills.
Today was the first negative reaction I’ve had to my barefoot running.
As I approached the treadmill in my flip-flops, a few people glanced my way as they usually do when seeing something unusual. One woman in particular gave me a bit of a surprised look. She had a baseball cap on, so I’ll call her Cappy. I kicked off my flip-flops and hopped up on the treadmill next to Cappy. No sooner had I started the machine than she hopped off, leaving all her stuff behind and disappeared around the corner.
A few minutes later, she returned and began running again. A couple minutes after that, a Rec Center staff member came over:
Staff: “Do you have anything else to put on your feet”?
Me: “No.” (I wasn’t going to run in flip-flops).
At this point, Cappy took out her headphones to (presumably) listen in.
Staff: “Our rules say you have to wear shoes”.
Me: “I’ve been running here for almost a year without shoes.”
Staff: “It’s for health reasons.”
Me: “My feet are cleaner than most people’s shoes.”
Me: “I don’t think there are any Michigan Health Regulations against being barefoot.” (not sure if this is true, but I think I heard it somewhere).
Staff: “Ok, go ahead and keep running. I’ll go talk to someone.”
Me: (thinking) Damn, now I have to keep running.
I finished my run and after I got off and wiped down the machine (which most people wearing shoes don’t do. ewwww!), the staff member approached and showed me the rule book. I said that I’m pretty sure they’re not allowed to have that rule since it’s a publicly funded center (again, not sure). She offered to have the Director call me about it, which I agreed to. She also conceded that it was not a health problem, just a rule.
I also suggested that if they wanted to keep that rule, perhaps they should add the following rule as well: If you workout with shoes on, you may not put your sweaty feet on the locker room floor without appropriate footwear. She appreciated the logic, and was very polite through the whole encounter. Kudos!
Sooo…. I have a couple questions:
- Is the “must wear shoes” rule legal, particularly since this is a publicly funded center?
- Is there anything in the Michigan Health Code
It would be great to have answers before I talk to the director.
Yesterday, I picked up the “box set” of Kent Beck‘s Test Driven Development screencast series. For $25, you get about 1.5 hours of “over the shoulder” perspective from one of the masters. I figured that even if it was horrible (unlikely), it was an opportunity I couldn’t pass up.
Here then, are some observations I had after watching the first screencast:
I was immediately surprised to see Kent’s Eclipse setup. He uses a non-monospaced font in the java editor, which I had not seen before. It seems a little easier on the eyes than the monospaced”Menlo” that I use in my editor. After watching, I played around with some new fonts, but couldn’t find one that looked good. I should probably find out which one he uses.
Kent also keeps his JUnit view minimized, and simply monitors it’s progress by the red/green color of the icon. I’m used to keeping the view open so I can see the errors that show up. Maybe that’s a smell that I’m having too much red during my TDD.
I was interested to see that Kent described TDD as having the following 3 steps:
- Developers write automated tests as they go
- Tests are written in advance of the code
- Design a little at a time
I’ve always described the TDD steps as Red/Green/Refactor and I found his description to be a little harder to think of as “steps of the process”. During the screencast, he also didn’t emphasize things like “now let’s write a failing test”, “let’s get it to pass”, etc. It was much more casual. Perhaps this style makes it more accessible to newcomers.
The first test that Kent wrote was actually what I consider an “Integration Test”, as it hit a network resource. It sounds like he’s going to address this in “part 2″, and I suppose it wouldn’t make much sense to immediately introduce mocks when trying to explain the basics.
Kent appears to use something like the “TDD like you meant it” approach, which I’ve also begun to favor recently.
Overall, it was really nice seeing how fluid and natural his style of development was and I’m looking forward to picking up some more tips from the next episode (in a few minutes).
On the XP list over the past few days, a cute little poem has emerged, first written by Tim Ottinger and enhanced by Tom Rossen:
Software that’s coded by monkeys
Is redundant and smells rather funky.
It’s cluttered, and fragile,
Nowhere near agile,
But it’s dope to a waterfall junkie.
I like it.
Fitting these pairing sessions into my schedule has been a bit trickier than I expected. A lot of recent difficulty has occurred due to people’s summer vacation schedules. Now that school is about to begin, I hope the frequency improves.
After some timetable negotiation, I was excited for the opportunity to spend a day at Healthmedia (a company providing Healthcare-related services) in Ann Arbor, by invitation of Helene Gidley, Matt Long, and Brad Neighbors.
Upon arriving, I sat with Matt for a bit and he gave me an overview of the application his team was currently working on, showed me their story tracking system, and generally oriented me.
Shortly thereafter, many people arrived in the team area and conducted their standup, after which most of those people left. I found this a bit odd, but it’s hard to make any sort of judgements with such a small dataset.
My first pairing session was with with Shilpa Nalgonda. We worked on some java code dealing with surveys and worked through discussing and then writing an outer level Acceptance-style test to drive our inner loop of TDD. We discussed test method naming and mocks. The team was using EasyMock, which I’ve never used due to my dislike of the record/replay syntax. I prefer using Mockito, as I think it a more natural DSL.
I also got into a discussion with Lyudmilla Mishra and a couple other folks regarding their move over to start using a dependency manager (Ivy) for their builds. It was interesting to hear about some of the issues they had to consider from a healthcare/HIPPA perspective. I shared my experiences with Ivy and Maven (Maven, FTW!).
Brad, Helene & I went across the street to Grizzly Peak for some lunch, which was great as usual.
After lunch, it was more pairing with Shilpa, joined by Brad for a bit of tripling as well. Brad shared some of his experience using the Builder pattern for creating test objects. I had combined Fluent API and Builder in my mind, but Brad reminded me that they were actually different things for different purposes.
During this pairing we experienced the pain of the current dependency management setup firsthand, having to wait 5 minutes between changing a domain class and being able to use the changes in the service layer. Hopefully, this will get solved with the Ivy implementation.
We finished off the day with some informal retrospecting between myself, Brad, Lyuda, and Matt. I provided them with my observations of the day and a few suggestions (visible task boards, introduce WIP limit, develop end-to-end rather than in architectural layers). All in all, a great bunch of people who I’m sure I’ll be seeing around the Ann Arbor Area.
Yesterday, as part of the 2010 Michigan Pairing Tour, I had the opportunity to spend a day at the new offices of BillHighway in Troy, MI. They have a very nice setup including an area with leather couches, a large screen TV and XBox + Wii consoles.
BillHighway “bills” themselves as a “Quickbooks for Communities”. One of my longtime friends works there, and I’ve had the privilege of getting to know their CIO over their past few years of impressive growth.
BillHighway is primarily a VB.NET shop. I’ve never spent more than 5 minutes looking at .NET code, and the last time I used VB was about 12 years ago. It promised to be an eye-opening experience.
In the morning I paired with André LaMonde, a VB.NET hacker. We were working on standardizing some of the UI components to be in line with a new Look & Feel for their site. I was briefly thrown for a loop by the unfamiliarity of Visual Studio and strange syntax, but quickly recovered and was able to follow what was going on without too much trouble.
Unit testing is not regularly practiced by the team, so we had some good discussions about some of the challenges that dealing with legacy code bases brings about, and some strategies for integrating tests going forward. We struggled with NUnit for about 15 minutes, then bailed out and were able to get some tests up and running with the framework built into VS 2008.
Overall, I had a great time, and picked up some 3l1t3 .NET skillz. I’m looking forward to the next stop!
Last Friday was the first stop on the 2010 Michigan Pairing Tour.
We decided to write some tests around code that he had written to post Facebook status updates. This led use Mocks for the Facebook API, and refactor some of the code to be more testable.
During this refactoring, Ilya brought up the question of whether we should favor writing testable code at the possible expense of simplicity. I think that writing testable code generally results in simpler code (not gold plating, etc, etc), but I replied that it’s only important to write testable code if you care if it works.
After lunch at a nearby Sushi bar we tackled a different project that had a lot of concurrency going on. Ilya has a lot of experience with java threading and he has an excellent handle on how it all hangs together. I learned quite a bit from him in this segment, include exposure to the Guice DI framework.
We were able to bring a couple consumer/producer classes under test. This again required some refactoring–mostly along SRP lines–and resulted in a simpler and cleaner design.
Overall, it was a great experience, and exactly what I hoped to get out of the pairing tour. I’m looking forward to my February date which is tentatively scheduled for next 2/12/2010. I’ll post more details when it’s confirmed.