Ambiguous Requirements in the Simplest Places (and how to fix it)

Below is a photo from New Mongolian BBQ, a favorite dinner place for the family.  This is a really interesting example of an ambiguous requirement as demonstrated by an ambiguous API.  As part of the instructions at the start of the line, a patron is suggested to use two bowls – one for meat, and one for vegetables.

IMG_20150201_184436When the patron gets to the end of the line for the their Mongolian to be cooked and they are presented with this spot for two sets of waiting customers.  The first question that comes to mind is I have two bowls.

The two immediate options that I see for what this means is

  • Customers front and back, bowl 1 and bowl 2.
  • Customer 1 and customer 2

Judging from the customers choosing randomly from the two options above.  I generally opt for bowl 1/bowl 2 if there aren’t any bowls already up when I arrive.

So how do we take the ambiguous requirement and make it mostly obvious to most patrons?  My suggestion would be to place a thick line to separate the two customer spots.  This would rely on human nature to want to have their bundled things bundled together.  If you look carefully at the picture, this might be the intent since there is already a slightly larger gap between the front and back.

Any other suggestions on how to resolve this ambiguous requirement?  Any similar simple but confounding ambiguous requirements issues that you have found?  Post a comment below.

If you aren’t yellow, you aren’t pushing hard enough.

Came across great execution: balancing order and chaos blog post by Mike Abbott on uncapitilized.com.  In particular the following quote

If the environment at a startup isn’t crazy, then something’s wrong.

This reminds me of an adage that I use fairly often.

If you aren’t yellow, you aren’t pushing hard enough.

For those unfamiliar with the Red/Yellow/Green (RYG)status colors, otherwise known as the Traffic Light Rating System (apologies for the British-isms in the wikipedia article), which is commonly used in project management to rate the status of a project.  Very quickly, here are some broad guidelines on what RYG means..

GreenProject in great shape, no issues, no concerning risks

Red Project in troubled state, needs help, impactful risks realized, late, overbudget
Yellow Project in okay to not-so-bad state, some issues, some risks, needs care and feeding, might become late, might go over budget
Green Project in great shape, no issues, no meaningful risks, no concerns… All good!

Quite often, project go through their lifecycle going something like the following…

Green, Green, Green, Green, …, Green, Yellow, Red

The optimistic behavior isn’t usually intended, it is human nature to assume that issues are under control, unknowns can be ignored, risks are mitigated and under control.   It’s only at crunch time close to the end when integration is occurring, latent issues or risks are discovered that a project moves to yellow.  Since they collapse on top of each other, the project quickly goes from yellow to red.  Project resets occur, scope is thrown out the window, crap products ship…

Realistically, a good project will ferret out risks, issues, assumptions and dependencies early on in the project.  If after a thorough analysis, the project would generally be yellow.

If the project is still green, the project is a slam dunk.  If you think it’s a slam dunk, then the team can push harder.  Pushing harder brings in some yellow through any of the RAID items above, but they also bring in an element of chaos that Mike talks about in his blog.

Thoughts, comments, counterviews?

Estimating for Software is Like Estimating for Skinning a Cat

As I’ve mentioned a few times, estimation is an imprecise art.    There are ways to increase accuracy of the estimation either through consensus based estimation or other methods.    This post explores why estimations are hard and why the software world struggles to find tools, techniques and methods that provide for consistent and accurate estimations.

I’ve recently been playing with Codewars (connect with me there) and have been intrigued by the variance of the solutions that are provided.  In particular, you have the “smart” developers who come up with one-liners that need a PhD to decode, tight code, maintainable code, and then clearly hacked till it works code.  This variance is likely the underlying reason for the difficulty in getting consistently accurate estimates.

Read on for more some of the examples that I have pulled from the Convert Hex String to RGB kata.  The variance is quite astonishing.  When you dig deeper into the differences, you can begin to see the vast differences in approaches.  I’m not going to dig deeper into my personal views of the pro’s and cons of each one, but it did provide me a lightbulb moment as to the how software in particular always going to be difficult to estimate accurately.

Read more of this post

I’m on IPv6, are you?

After reconfiguring the lounge room to move the TV to another corner, I had to do a little bit of rewiring.  As luck would have it, when I reset theResidential Gateway (RG) it didn’t come back.  As part of replacing the RG, I though I’d dig a bit deeper into the getting IPV6.

So after:

  • Call out to ATT,
  • one missed appointment,
  • a visit from an ATT tech,
  • a new RG,
  • another visit from a tech,
  • a fixed outside line,
  • another call to ATT,
  • an email to customer service,
  • seven emails with customer service,
  • a new visit from a tech
  • a new RG

I am finally on the other internet.

screen-shot-2015-01-16-at-9-15-00-pm

Read more of this post

Getting a Remote Running with Kodi under Ubuntu

[UPDATE] I’ve aborted this effort after a rework on the home network.  I’ve ultimately opted for a Raspberry Pi Complete Starter Kit, with Noobs and Raspbmc.  It worked with the remote out of the box and now I’m up and running.

I use kodi (formerly xbmc) as a home media system.  It was setup working nicely with a Harmony One remote control.  For a few reasons, I updated some packages on the Ubuntu 12.04 system and ended up on Ubuntu 14.10.  As part of this upgrade xbmc became kodi.

Unfortunately now, kodi recognizes only some of the remote commands.  Left, right, up and down and play work well.  Others (OK, Back, etc) don’t.  Debugging and resolving this has proven to be a much bigger challenge than it has been in the past, where i have worked things out without too many hoops.  Unfortunately both Linux and kodi have changed quite a bit over the years and a lot of the online documentation, blog posts and so on are out of date.

My modus operandi is less about hacking things heavily and more about the simplest path to get things working.  I’d rather remove a package than heavily configure and customize a set of files.   This is my way of looking at if I can get things to “Just Work”.

This blog post is intended to be both a narrative on how to get things going, but also serve as a current reference for people out there who run into this sort of problem.  Read on for more details on what I have done.  This post will carry a lot of questions as I resolve issues, and will be updated over time.

Out of the box, we have a remote that does up/down/left/right/pause work.   However the OK, back and other buttons don’t work.

Read more of this post

Finally – a Granted Patent – US 8838868

After many months, and many years – I finally have a patent credited to my name.  The patent is for an extension of the magnetic coupled connectors (such as magsafe connectors on Macs) to include diagnostic information through the magnets themselves.   Of course watching how the sausage is made has been eye opening on a number of fronts.  Read on for a quick review on the inspiration behind the patent and any interesting observations on how things went down.

Screen Shot 2014-09-28 at 9.53.35 PM

Read more of this post

New #bymoonlight images

New images, with a supermoon sunrise.

Follow

Get every new post delivered to your Inbox.