Skeptek.com » Development Management

The Five Stages of Operations Grief

Keith Forsythe — Tue, 07 Dec 2010 02:50:43 +0000

I think I’ve spotted a trend. I’ve been developing software for over 10 years now, and I have observed a humorous pattern (well humorous sometimes) when it comes to telling your operations guy something is broken in production.

My current ops lead Philip is a perfect example of this behavior. Tell him something is busted in prod, and he delivers a series of predictable responses. So without further delay, I give you the Five Stages of Operations Grief:

Me: “Philip, user’s arent getting any email from our website.”

Denial: ”Wasn’t me.”
Anger: “You want me to wake up NOW and fix it?”
Bargaining: “Can it wait till I wake up?”
Depression: “I can’t believe I have to wake up and fix it.”
Acceptance: “Sigh…. Try it now.”

Here’s another one for the outsourcing horror story collection

Keith Forsythe — Tue, 31 Aug 2010 02:17:57 +0000

My friend Matt often complains about some of the outsourced staff he gets stuck with on his consulting projects. He sent me this IM conversation that really illustrates his point:

Matthew/Chicago/: Srini I’m in a room filled with 20 very concerned UAW workers trying to run their new line financial pareto reports for the US financial accounts. This is one of the BTO transition items I have to get setup for the client ASAP.
Srinivasanu/India: Yes Matt this is Srini.
Matthew/Chicago: Yes Srini I know. I am inside of the report we are stuck on the case number selection field which has been searching for results for approximately 5 minutes without a result.
Srinivasanu/India: Yes Matt. Are you connected into the internet?
Matthew/Chicago: Srini yes I am connected to the internet. There are no values showing up in the prompt selection. The report is failing. People are not happy I’m in a room filled with upset union workers. I’m wasting their time.
Srinivasanu/India: Matt can you see if you can get to the Google.
Matthew/Chicago: Srini I’m connected to the internet I’m speaking to you on the internet.
Srinivasanu/India: Yes Matt internet is not issue.
Matthew/Chicago: You and the team marked this as a passed item in your SIT testing according to the client. Note the test cases all mentioned a specific value to search on 12501 for example case number 2 does not work. The users are trying to do the same it is not working.
Srinivasanu/India: Matt yes I test the field and when the field didn’t return value I skip it.
Matthew/Chicago: Srini did you skip everything that was not working and just mark it passed?
Srinivasanu/India: Yes Matt.
Matthew/Chicago: So you have no idea what you’re doing? Is this a correct assumption?
Srinivasanu/India: Yes Matt.
Matthew/Chicago: I think I’m in the Twilight Zone.
Srinivasanu/India: I not get message Matt.
Matthew/Chicago: Get up now walk over to Prasad and let him know you are no longer on my project. Tell him to get the entire team in a conference room in 10 minutes and to dial in my line. You’re not invited. Do you understand this?
Srinivasanu/India: Yes Matt I think there is a problem.

Don’t Mix Brainstorming and Estimating Effort in the same Design Meeting

Keith Forsythe — Fri, 01 May 2009 13:01:44 +0000

Recently, Derrek Long, my system architect, asked me to read a few pages from the book I.M. Wright’s Hard Code by Eric Brechner. He had observed issues our company was having with mixing brainstorming and scope cutting in the same meeting. Brechner describes over a few page in Chapter 5 how to avoid getting FOCKED, or “Failing to Orchestrate Collective Knowledge Effictively for Design”. Essentially, Brechnar preaches to have very specific goals for a meeting, and to avoid at all costs mixing goals, especially when the goals are completely opposite to each other.

After reading Brechner, and thinking about it for the last few weeks, I’ve expanded this idea out a bit further as to why mixing brainstorming and estimating effort during initial design meetings between the business stakeholders and development is a bad idea.

Discussing effort for each idea discourages creativity when brainstorming. People will be less likely to offer “out of the box” or “half baked ideas” that need to be flushed out if they are afraid they will be scolded for coming up with something “too hard”.
Dev often will give a big estimate when they don’t like an idea. So waiting to estimate the idea at a later time demonstrates that dev still put in the due dillagence to consider the idea and the estimate isn’t just based on dev not immediately liking it.
Initial estimates given 10 seconds after hearing an idea in a brainstorming meeting will be less accurate. Dev needs time to absorb the idea, think it through, and then offer an estimate of effort. Even spending 5 or 10 minutes considering an idea results in the developer spending 100 times more time considering the idea and will result in a more accurate and reliable estimate.
Other ideas presented later in the meeting might add further clarity to earlier ideas or might prevent the idea from needing estimation altogether.

I would love to hear from other people their experience with keeping brainstorming and estimating separate. If you have techniques you employ to do this, let us know!

Tips for Hiring QA Engineers for an Internet Startup

Keith Forsythe — Sun, 14 Dec 2008 17:41:46 +0000

The one position I continue to have trouble hiring for is QA. I manage a development team of 8 others. 5 Ruby on Rails developers, 2 Java and C# developers, and a system administrator. My team is quite sharp. Finding a QA person that can fit in to a Internet Startup Agile Development team has been quite a challenge. And if you are a small company, like mine, you only get one person for this role. The person you hire needs to be a rockstar. No budget to have multiple people.

So what makes a great QA person? Well I believe you should look for the following qualifications:

QA Vocabulary. Nothing is more annoying than a QA candidate who can’t tell me the difference between white box and black box testing. There is a good set of software QA terms here http://geekswithblogs.net/srkprasad/archive/2004/06/02/5795.aspx and here http://www.aptest.com/glossary.html
QA testing skills. I usually take a story that is ready for testing and have the candidate take a shot during the interview. I find it useful to leave the candidate alone while they do this.
Resumes that have grammer/spelling errors… trash ‘em.
Extension of the product manager. I don’t get to review every story that is developed and release, but the QA engineer does. So your QA person is an extension of your product people/person. It is critical the QA person get a feeling for what your product manager likes and dislikes.
Hard Ass. You need to make sure that your QA candidate can stand up to manipulative developers that try to convince the QA person to “it’s not a bug, it’s a feature”. The QA person needs to not roll over everytime they are steamrolled.
Flexible schedule. That’s right, the QA candidate needs to be comfortable with working long days and nights, especially just prior to a release.
Relevant experience. Hiring a QA person for web testing that only has tested windows clients is not a good idea. You are a startup, you need results fast. Your not in training mode.

And of course, finding this person sure isn’t easy… so good luck!