12 October 2016

Groom your Backlog!


No matter the brilliance of a given development team, it's always more efficient to Analyze/Groom/Think about requirements before you're in the meeting where you commit to delivering those requirements.  

I've been developing software with groups of fairly brilliant people for some time.  The above is my genuine experience.

When a group of people encounter a set of requirements and expect to scope and commit to them in realtime while reading the document, it wastes everyone's time.

Generally, productive discussion results, yes, but that discussion is unbounded.


  • One person pre-grooms the story.  In times past, that's a business analyst or architect, but a member of the development team is fine.  Just be sure before you go into the pitch/commitment meeting someone is warmed-up to present the story.  This is analogous to an intern or resident presenting a case in a hospital to the other doctors during rounds.  
  • The group scopes the story in 5 minutes or less.  If the 'grooming owner' has done his job breaking-down the story, then that should be enough.
  • Repeat until done.
  • Keep metrics on how fast you can get through everything, and if the analysis was sufficient for the sprint.

28 September 2016

Skills I'm glad I have

Too long for a tweet.

Too short for a blog post.

These are some tech-related skills I'm glad I have.  They come in awfully handy:

  • Touch typing.  You'd be surprised at the number of people who work with computers for a living who can't actually touch type.  
  • Markdown.  Markdown is incredibly handy for tossing-off documentation and forum responses.  I've actually considered hosing this blog entirely and converting to posts hosted on Github, formatted in Markdown.
  • Vim.  I've rediscovered a love for Vim in the past few weeks.  I've intentionally avoided installing Sublime Text 3 on my work machines, just so I'd get better with Vim.  This thing is a frickin' katana for text editing (duh...)
  • Ruby.  A surprising number of production programmers don't have a scripting language under their belt, which is a shame.  Ruby is both light enough for scripting and powerful enough to do basically anything you need.  (Just write RSpecs for anything > 100 lines, m'kay?)
  • Unix command line.  I'm blessed to work at a place that's all *Nix, all the time, so getting better with unix commands and pipes is a must.  Just off the top of my head:
    • sed
    • tr
    • tree
    • find and its many switches
    • xargs
Next up: A post about the things I wish I knew better.  Hint: JavaScript is definitely on there.

23 September 2016

"When Can Test Start?"

A few quick thoughts on a subject I've seen at least 10 times in my career:

"Okay, when are you done enough for me to test this thing?"

Let's parse that a bit, because the ensuing arguments are one of definition

  • "Okay," Acknowledging that stuff is just great or else I wouldn't be talking.
  • "when" I'm going to ask you for a date. 
  • "are you done" Done as is: Things won't change between the time I hit submit on the bug and I go to the bug review meeting and look like an imbecile.
  • "enough" I'm not a total douche.  I'd like to test this, not make you look like a fool by filing 15,000 bugs.
  • "for me" Hi, I'm a professional software tester.  Yes, we do exist.
  • "to test" I was born to test and break things.  I can make your code cry.  You need me.
  • "this thing?" At the end of the day, your work of art is a piece of business value and I'll not insult both of us by implying otherwise.
The above is the way a real QA professional sees that question.  I think.  Because, I'm not a QA professional, and God HELP YOU if I were.  I maintain my decade-plus assertion that great testers are born, not made.

So, what's the problem?  


  • You'd like to release your Thing on Date X.
  • You'd like to make money or save time or whatever.
  • You want some reasonable assurance that it works.
  • The QA team says they need Date X - days to test things.
  • That milestone is either imminent or sadly in the rearview mirror.
To wit: You're an engineer and you're staring at either a Project Manager or a QA professional and they ask you that question:  "Okay, when are you done enough for me to test this thing?"

This is like an opening move in chess, I'd argue, and there are several (well-studied) responses

Your Responses

  1.  Deflect.  That is, attack the premise that you're ever "done" with software.  Said differently, imply there are plenty of testable features:  "There's plenty of stuff to test.  Why haven't you started already?"   I've been there.   I've done this.  It doesn't work.  If your shop cares about milestones, this is a one-way ticket to escalation.  For one thing, you've established a Dev > Test primacy that excites the Lizard Brain in all of us, particularly test managers.  Particularly if they have an axe to grind.
  2. Lie.   "Sure, we'll be done by ______." While given with the best intentions, any sort of answer that fits that pattern given on the spot is a lie.  Take a breath and understand that.  You might have a 50/50 shot of hitting a date given on the spot, and if you miss again, there goes your credibility.  
  3. Stall.  In effort to avoid 1 & 2, a natural is, "I'll get back to you."  This is perfectly acceptable in many circumstances, including here, but realize:  If someone uttered that original question, their Spidey Sense that you're going to be horribly late with crappy deliverables they have to somehow pull out of the fire goes off.  Better: "I'll get back to you this afternoon." 
  4. Work the problem.  Assuming everyone is trying, all sides want to meet the goals.  The Testers really want to test, because they've lived through working 70 hour weeks trying to test stuff that delivered late.  They're sensitive to that not happening again.  So, call a meeting to look at the situation from both test and development perspectives and see what's testable and when the late stuff will be available.


1)  Deflection by fit-throwing: roll your eyes.  Swear appropriately.  Go off by yourself in a huff.   Your hapless manager/team lead will try to rope you back in and they'll forget all about the test kerfuffle.  You're acting like a 2-year-old.   Please be better than that.

2) Lie by legalism: "I don't believe our schedule committed to exactly ______ by ."  This will send everyone back to their various documentation and buy you time.  It's a damned dirty trick, and everyone sees through it.  You'll probably win the battle--no one maintains that kind of documentation, unless there's a government contract involved--but again your credibility is toast.

3) Work the problem....until they quit.   This is inviting them into a meeting.  Then another meeting.  Then a meeting you have to reschedule.  Eventually, they give up.  Again, past a certain point, people know you're all smoke and mirrors.   You don't want that on your reputation.

4) Fire all your testers.   "We can automate everything, and we don't need them.  We need developers, and the budgets are tight."  You're rationalizing.  Call me in exactly 18 months when all your customers find the issues you didn't add to the automation suite, but a good tester would've found in 1 day.

5) Put the testers on the development team.  Bah, just fire them.  Admit you want them to STFU so you can keep hitting dates, and doing this removes any sort of counterbalance to the "ship it" mentality of a development manager.

* * *

I've lived through some theme and variation on all the above.  The RIGHT answer is: Work the problem, bombard your test group with progress and status before you get close to a milestone so there's zero surprises.   

That's right, if someone even asks the question in the middle of your project, take it as a sign your development process has failed, and act accordingly.

20 September 2016


I'm homesick.

"Home" is hard to define:

  • The place where your feet are.
  • The place where your wife and kids are.
  • The place where you feel at...well....home.
I don't feel at home in Austin.  All the social and physical trappings of having roots here just aren't here yet:
  • We don't have a real house.  We have an apartment with a yard.  It's nice enough, but nothing about it feels like 'home' except for the occupants.
  • We don't have a church.  Realistically, we're not even close.  Everywhere we've visited, coming up on 10 churches at this point has been some combination of too.  Too loud.  Too small.  Too doctrinally unsound.  Protestantism, as ever, remains a mixed bag once you go somewhere else.
  • The water here is genuinely terrible.  For one thing, tap water is hot, not cool or cold.  There seems to be mix of limestone and sulfur in that's just hard to take.  Everything reasonably potable is filtered or bottled.
  • I don't have the friends and colleagues I left behind.  I knew this was part of the deal.  I felt called to come to Texas, but I guess I didn't appreciate having people who really knew me.
There are positives, of course.   My wife and daughters seem to be flourishing, amid the many homeschool groups and activities of Greater Austin (Cedar Park and Round Rock, in particular).  We're able to save for the first time in our life,.  Work couldn't be more stimulating.

Sometimes, I mope.  It's a thing for me to just hit a depressive cycle every so often and I guess just looking down and seeing no safety net beneath us has me homesick.  I miss being able to relax, though I'd suppose that's my own neurosis.

15 September 2016

Java8: Loops Not required

So, during my job-hunt, I spent at least an hour a day on HackerRank.  I highly recommend the site for anyone learning to code, sharpening their skills, or learning a new language.

Anyway, so at my new job we use Java8 extensively.  I'd had cursory exposure to Java at my last gig, but mostly in the "Why won't this frigging library run with my Java 1.7 JVM?!" variety.  So, it was time to learn something new.  Narturally, I thought of HackerRank and it's Java tutorials.

So here's one that's interesting: Java List.

Some things of note:

  • One can eschew loops completely now.  The new Streams API + lambdas make it possible to mimic the expressiveness of Ruby, with Stream.forEach( ) feeling awfully similar to Ruby's each {}
  • The Stream parallelStream() is pretty much as easy as concurrency on JVM is likely to get.  The only downside is the global JVM fork/join pool for the streams.
  • It's awfully easy to get sucked into multiple transforms that seem to make code harder to read.  As I gain experience with the Collectors, this seems to be getting better.