Planning Poker is a Finger Pointing at the Moon

And boy, do people hate planning poker.

It comes up all the time with friends and coworkers. When talking about life as a dev, work processes, management, or the industry as a whole, eventually someone mentions work-costing, and people hate points being assigned to work they have to do.

Planning poker is one common name for the act of a group choosing those point values for future work, to determine the time and the effort the group believes will be required to perform the work.

And people have legit issues with it: the method their team follows, its accuracy in finding costs, how frequently it’s done, the way the points get used, and the reasons they have to do it. But most concerns are targeted at the ineffectiveness of costing, which misses the true, hidden point of the task — and you can’t blame them for missing it! They see the finger, not the moon.

Buddha’s no moon

The finger and the moon are an old zen metaphor: those who seek the moon and find people pointing fingers to the sky shouldn’t mistake the fingers for the thing they seek. They shouldn’t mistake a temple, or an idol, for the end result of the teaching. The finger is just a thing that helps them get to the thing.

Planning poker is often discussed as a way to determine the cost of work, and that’s how it’s sold. Many companies only bother to do it because certain strata of management want to know what things cost and when they’ll be finished. Planning poker puts numbers to work, so why not use it? Some people want to use the costs it produces to forecast future project timelines, while others want to measure their teams’ (or, frightfully, individuals’) relative productivity by their completion of certain numbers of points in given time periods. But planning poker isn’t really good for or about any of that — it’s just a finger, pointing at the moon.

The moon here is all the parts of your work that you don’t even know exist until you’re working through the middle of them. It’s all the hidden costs that an optimistic Product Owner would never consider. You can’t have one person sit on their own in a room and just see all these things, so what can you do?

You can build a temple with a finger in it pointing at the moon, i.e. a process that naturally leads to the discovery of these unknowns. That’s planning poker.

Planning Poker is not itself a Heavenly Body

Planning poker has many variations, but it’s typically done by having cards in roughly fibonacci number increments from about 1 to 33, which every member of a small development team has a copy of while attending the session. A story or task to be costed is selected — it may have a prior general assessment as “large”, “medium”, etc. from an initial triage lookover, and after some discussion of the task, everyone privately chooses a card with a cost from their own set. They all reveal simultaneously to avoid a big group-think in first selection.

On any appreciably complex story, at this stage you will find a cost disparity between team members. Someone who is junior might think something they don’t understand is more or less expensive than makes sense to the rest of the team. Someone who is feeling pessimistic that day might put in a high cost, or vice versa with an optimist, or just someone who knows more or less about the problem space. Now that the cards are down, the discussion begins — the finger has pointed.

“Junior Dev Danny, why do you think this story will take 3 points?”, quoth the scrum master.

Danny now has to fumble around and rationalise their cost. They might have good reasons, and they might not. Everyone sitting in the room listens, and other members of the team can agree or disagree and give their own reasons. You do this a few times with the outlier costs, write down the most legitimate concerns and new stuff that fell out in the process, and what you’ll find is this:

  1. Your cost will average toward a meaningless number.
  2. You ended up with a far better description of the task.
  3. Everyone on the team better understands the work to be done.

If you asked everyone to just improve the description, or just read through all of the tasks? Especially without the meeting? You would end up with shit. No one cares enough to read closely over all of the tasks. People hate that stuff and it would be culled from your process simply by never happening.

But if you get everyone in a room and ask them to assign point values for the sake of finding out the cost to the business? Well, you still end up with shit on that front. No one cares enough to do a great job by themselves, if it’s even possible, and people hate this stuff and want to remove it from the process because they feel it’s a waste of time, even as they make use of the way better descriptions and feel good knowing what the whole team is working on. As a byproduct of the process and its shit, we all get to see the moon.

Caveats

There are some caveats here. Being evaluated in any way by the points output gives a lot of awful incentives to game them, even subconsciously, which leads away from good discussion. Also, doing punishing amounts of discussion over small bits of work builds enough process-hate to get people to check out and stop even listening, which also leads away from good discussion. And trying to evaluate work that is too remote (e.g. if you’re on a team that is too large, or is handling many totally unrelated projects, or is trying to work 6 months into the future rather than on stories for the next few weeks/month) will let people zone right out during the process.

For these discussions to happen you need a right-sized, reasonably focused team that’s only having the meetings they need to have, and they have to be able to talk without fear of being penalised for wrongness. This is sadly a tall order for some places!

So whatever you do with the numbers that come out of planning poker, please don’t measure your team by them in any sort of performance-review capacity, and though they’re better than nothing at all, please don’t trust the numbers to tell you the exact launch date.

But keep doing the estimation!

Keep watching the skies

It gives a key time to teach junior developers about your systems. It gives product, design, and QA people more confidence and context in the work being done. It gets everyone on the team invested in every task. And it uncovers a huge amount of work that you otherwise wouldn’t see until you were standing in the middle of it! This lets you adjust course before you have momentum built, while you’re less invested in work you’ve already done, which may even have been the wrong work to do in the first place if you’d only sat down and talked it through as a team.

These things are absolutely key to producing good software in a reasonable period of time and making life less miserable for everyone. It has saved teams I’ve been on so much hassle, so many times. We found the moon.

Planning poker absolutely helps us all to find it, even though it mostly sucks at accurate cost estimation, and people can grossly misuse the numbers it produces.

Installing Rust on Windows in 2018

Rust is a systems programming language in a similar space to C++ that I’ve been meaning to try out for some time. Reddit’s roguelikedev community recently began doing a community-wide roguelike-tutorial follow-along, and a member of the community conveniently ported the old python tutorial to Rust! I’ve got a repo to follow along here. So it begins. 😀

Or so it would have begun   D:

It turns out that installing Rust can be a pretty painful and laborious experience, particularly if you try to be clever and thrifty like I did. So here’s how to properly install Rust on Windows, using the MSVC++ toolchain, in 2018 — first a summary, then I’ll explain my mistakes briefly, and then I’ll show some screenshots to make it even more clear.

A note on my Windows version:

I used this process to install Rust on a Windows 7 machine. I expect that Windows 8, 8.1, and 10 have similar requirements, options, and results, but I can’t guarantee it will be identical. Things are most likely very different if you want to use Rust via the Windows subsystem for Linux.

How To Install Rust on Windows in 2018

  1. Download and Install the MSVC++ Core Build Tools, and select just the main Visual C++ Build Tools option, then proceed. It will include the Windows 10 SDK (yes, Windows 10 is fine even if you’re on 7 or 8) and in the background it will include the Windows C Runtime (often called the CRT).
  2. Install Rust using rust-lang.org’s rustup_init tool, follow its few prompts, and wait very patiently through the installation of rust-doc that can run for 20+ minutes without any indications of progress.
  3. Restart any shells you had open to give them access to your updated environment variables. You should be ready to run rustc --version and check that things worked.

That looks easy! What did I do wrong?

First, I made the mistake of customising the Build Tool installation — it wants to download and install 3-6 GB of data and I thought I knew better. Then, during the very long rust-doc installation my first time through, I grew concerned that it had crashed and cancelled my installation halfway through. Then later, I trusted that I had the same understanding of the phrase “Core Build Tools” as the Rust installer. I proceeded to wade through old github issues for hours while slowly uninstalling and reinstalling repeatedly, and tinkering until it worked.

So, some rules to avoid these pitfalls:

  • Do not customise the Core Build Tool installation! (unless you know you have to)
  • Do not cancel your rust installation halfway through! (if you do, you’ll likely need to do a full uninstall to get back to a working rust)
  • Do not trust that your idea of some jargon-y phrase like Core Build Tools is the same as the person who wrote the documentation! The Rust installer thinks of the “Core Build Tools” as the Core Build Tools and the Windows C runtime and the Windows SDK.

Screen by screen: How to install Rust on Windows

So first, download the MSVC++ Core Build Tools (the file is called vs_buildtools.exe):

The download is on this page, but not here at the top:

an image of several links which are (not obviously) not the build tool download links

It’s here, quite far down:

an image of the correct download link for the vs buildtools file

Launch that tool once you have it — as of June 2018, this is its name and icon:

an image of the build tools icon on windows

It should look like this when run, and it will spend a bit of time downloading a bigger version of itself and seeming to disappear before giving you anything useful:

an image of the build tools self installer

Once it finally opens up, only check off this one thing, and just accept that it’s going to be a multi-gigabyte download.

an image of the build tool options, with only one option checked off

Once that’s done, you should be set for Visual Studio requirements! Now to install Rust. First, download rustup-init.exe from rust-lang.org:

an image of the rustup-init.exe download link on rust-lang.org

Then run it and follow the prompts:

an image of the initial output of rustup_init.exe

And wait… a 5 up to a 20 minute wait for rust-docs to finish is totally normal. :/

an image of rustup init at the long-running rust-doc step

Hopefully, finally, success!

an image of rustup_init after successful install

Close your open terminals, open a new one up, and try running rustc --version:

an image of rustc --version returning its version

Then make a sample app by running cargo new --bin your_app_name, and try compiling+running it from within the new directory using cargo run --release as in the image below. I’ve added a few cat+ls calls to the image to show context, but you should see pretty similar things:

an image of cargo generating, compiling, and running a new project

If your project ran like the above, you’re all set. You can finally live on as a happy rustacean. Congratulations! 😀

Did something go wrong? Here are some quick problems/solutions:

advapi32.dll not found:

This is the first DLL in the list that the linker looks for, and this pretty firmly means that Rust can’t find your Windows SDK. Usually that’s because the SDK is not installed. You should download the MSVC++ 2017 Core Build Tools, install them as shown above (they’ll include a Windows SDK by default), and then try reinstalling Rust.

user_32.dll not found:

This also means that Rust can’t find elements from the Windows SDK — maybe it’s old, or has been modified. Try following the same directions for the advapi32.dll problem above.

mspdb110.dll not found:

There’s a theme here: Rust’s linker can’t find things because they aren’t there or they’re broken. This one (I think) is from the C Runtime. Try uninstalling your MSVC++ and following the instructions above.

Some other kind of link.exe-related error:

This is probably also due to a Windows SDK, C Runtime, or Core Build Tools issue. Try the above MSVC++ installation step again before anything else — if you’ve done that already, maybe there’s an old MSVC++ hanging around in the way? Look in Add/Remove programs — careful though, you likely don’t need (or want) to remove anything called a “Redistributable”.

The Rust installer says no MSVC++ is installed:

If you definitely want to work with MSVC++ and are getting this, make sure you’ve followed the instructions above, and if you have it is possible that Visual Studio has been updated and moved things around again. Until a newer version of Rust comes along to fix the issue, if you can find a file called “vcvarsall.bat” inside of a folder similar to C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Auxiliary\Build, running that on your command line with an argument to specify your architecture should set the correct environment variables for Rust to find your MSVC++ installation.

Remember: that will only set the variables for the single terminal window you run them in, and it’ll need to be re-run if the window closes. I have a previous post (see Windows CMD Aliases) that may give you some ideas about automatically running code when you open a terminal on Windows.

If you want to, you can just hit continue here. To do so, you will need the MinGW compiler installed, and Rust will then target the GNU toolchain on Windows. This will mean that you can’t link against libraries built with MSVC++, which might be a dealbreaker.

The MSVC++ download link that Rust’s Installer gave me says it’s expired!

This is a weird one and should only be happening for a few weeks.

Someone thought a random Hubspot account could be a good place to host a file that the installer linked to, and it ended up not being so good a place. There is already a merged PR to fix the issue and point to the link from Microsoft, which is what I use above. Follow the directions there and you’ll be okay.

If for some reason you need the 2015 Visual Studio Core Build Tools, you can still get those through my link to the 2017 tools above, but you’ll have to wander into customising what you install. Remember that you need a Core Tools option, a Windows SDK (8.1+), and a CRT (C Runtime) at the minimum for Rust to work.

Rustup/rustc/cargo complains that it has no default target:

You might just not have a target set. You can tell rustup to target msvc++ by running something like rustup default x86_64-pc-windows-msvc. If that doesn’t work, you may not have fully installed Rust, perhaps due to a lack of permissions, or due to a pre-existing Rust installation that got in the way.

You should try to uninstall rust using rustup self uninstall, and once you get it gone, reinstall it. Maybe try a custom location if you don’t have access to the .cargo folder it was trying to install into. When it’s done, it should look something like the screen above with green text that says it was successful.

Other problems / these solutions didn’t work:

Sorry! This was just the set of problems I ran into and can recall after a nearly sleepless night. If you’re stuck, don’t forget that Google is your first and best friend in the world of problem-solving, but you may be able to get interactive help from humans on the Rust Community Forums, or on IRC on irc.mozilla.org’s #rust-beginners channel. You should likely glance over the community’s code of conduct before jumping into these spaces. 🙂

Conclusion

Hopefully this has helped you get off the ground with Rust on Windows! If I can save anyone some time out of this, that would make my painful experience far more worthwhile. Go forth and Rust! And keep an eye out for my own wicked Rust roguelike, The Glass Oak!

searching for special chars in vim and setting aliases in windows cmd

Vim Spells

This morning I was looking over the old reading list and noticed that A Night in the Lonesome October had some strange characters floating around, which I wanted to delete. I felt that deleting them all using vim’s search/delete seemed like a good plan, but I couldn’t recall a way to copy the line containing the special character from the text buffer over into the command-mode search/replace/delete string. I wanted to do it without using my mouse or shell, and knew there must be a way — ahoy, to the internet!

This stackoverflow question had exactly what I needed in one answer, and then a great improvement right after. The initial solution is to yank into a letter-named register using "ayw (" = specify that a register name follows, a = overwrite the ‘a‘ register, y = yank, w = a word, so all together that command says “yank a word into register a” — you could also use, say, "ayy to yank a line, etc), and then to use CTRL-R followed by the register (in this case, a) to paste from the register straight into a command-mode string. The followup that improves this in general use is to avoid named registers and use the implicitly-filled ‘0‘ register, so you can just, say, yw as normal to yank a word, and then use CTRL-R 0 to pull from the 0 register which got filled implicitly by the yank command.

I also didn’t quite remember what the command-mode string to delete a line matching a pattern was. I tried :%d/search term/ first, but I only got trailing-characters-errors as a result, so I turned back to the internet. Google quickly turned up this vim wikia tip that it’s %g/search term/d. %g to globally search and execute a command on matching lines, and /d to specify delete as the command to be issued.

I haven’t ever really used registers in vim, so this is one more of those thousand steps up the mountain in my ongoing (decade-plus-long) vim user story. These are such arcane tools, but at least when you get them to do the work you want, it does still feel like wizardry. With luck, I’ll remember these pieces a bit better next time and cut Google out of the loop. 😀

Windows CMD Aliases

In a mildly different zone of computer use, I was missing a few of my common command-line aliases in the windows shell, cmd. I tend to use ‘s‘ for git status, ‘d‘ for git diff to see the unstaged changes, and ‘c‘ for git diff --cached to see what’s staged to commit. I have some simple alias commands in most of my unix home dirs, but recalled windows being a bit stubborn here last I looked.

Thankfully, the god-emperor of the internet Google quickly served up this fine stackoverflow, which listed a few interesting options:

  1. doskeys in an alias.cmd that gets loaded via the shell shortcut with /K
  2. doskeys in an alias.cmd that gets loaded via a registry key
  3. .bat files in an aliases folder that you add to your PATH.

These are all pretty cool ideas! I was only vaguely aware of doskeys before reading this post, so that’s a keeper at the least.

After some thought, I opted for the registry editing route — here’s why: I use at least 2 shortcuts to open cmd, and I don’t want to have to modify the launch string in both. Moreover, I definitely don’t want the potential to forget to modify one or to end up with different launch strings in different places, so the shortcut-editing answer didn’t fit my needs. The .bat-files-in-a-dir solution is aimed at reducing the computer-load of repeatedly loading all your aliases, and I only have 3 simple ones to add for now. On top of that, a .bat for each of them seems like overkill.

Over 1 Billion Yaks Shaved

All of this is, as usual, procrastination. I’m in Paris for a few weeks and taking a few grey morning hours ostensibly to look at making start on a javascript clone of Into the Breach that fuses in some more Advance Wars-esque ideas (resources, construction, territory, different map sizes) and I need to a) break that problem up a bunch, which is hard, and b) sanely upstream all of my tetris (playable link) work on creek into creek itself before I go spawning new projects like baby spiders in the wind.

Those are daunting tasks. So instead of working on them, I chose to give the world yet another blogpost with a few links deep into the stackoverflow hivemind.

I also noticed that viewing individual blogposts seems to have grown some content-type issues after the migration I did a few weeks back, so I might have to fix that before I do anything else. The procrastination show must go on!

update: fixed! Configuring nginx for wordpress just took me a lot of reading and trial and error. 😀

Hello from Hong Kong!

I’ve just migrated hosts and this blog is now running on a different operating system, web server, php version, and database version, and all of its content got pooped out into a file and slurped back up in between, so I need to make a post to test that things are actually working.

So far so good! By the way, I’ve been travelling for the last few months and am presently in Hong Kong. I’m leaving tonight to go to France, and will likely head home in the next month or so via a few other euro-countries. So far I’ve been through some limited spots in England, Iceland, Germany, Greece, Singapore, Indonesia (Bali), and China (Shenzhen). Lots of amazing things to see, but it’s been just about enough whirling of the winds!

In other wyatt-tech-news, I’ve been working on a tetris clone on and off while travelling, which you can play with here if you’re so inclined.

Progress Ratchets

Let’s just get this out of the way:

  • Ratchet (device), a mechanical device that allows movement in only one direction

When going back to play an old video game with blocky polygons and low framerates, or watch an old movie with badly lit CG, or when looking at an older monitor with a lower resolution, the advances we’ve made for these technologies are obvious.

But when we first saw higher framerates, fewer polygons, better lighting or higher resolutions, it typically wouldn’t stand out as “exceptionally good”. When watching my first 720p HD video, I didn’t think “wow, this is so high res!” Similarly, not much later when watching 1080p for the first time, I just enjoyed the content.

These types of changes are only noticeable in one direction — improvement in framerate, resolution, etc. are nearly imperceptible, but degradation in the same is obvious. We experience discomfort now trying to play Smash Bros 64 with its slow, laggy gameplay, but when we first saw Smash Bros Melee, no one said “whoa this is too smooth!”

Did 480i->1080p change our lives? No, but we’d be unhappy to go back. Did 2004-era cellphones change our lives? They seemed important, but it wasn’t a huge deal when they were off — people just missed calls or texts. Compare that to 2014-era cellphones: many people express feeling alone or lost if their phone drops its network connection, let alone turns off.

A caveat to this could be something like 48 or 60fps video. It looks noticeably different, and (to my eyes) noticeably bad. There’s something about the way objects track and light looks at that rate that doesn’t sit right. Perhaps it’s an uncanny valley effect where film is now so realistic it starts to convince us it’s really real, but fails to finish that job and leaves us unsettled.

My personal bet is that a century of making films at lower speeds has led to techniques in lighting, editing, framing and motion that applied well to 24 frames per second and helped to craft the cinematic feel. Those tools and techniques just haven’t had time to be adequately adapted to higher frame rate filming, but they will be eventually. What I think we’re experiencing discomfort over isn’t the frame rate change itself (or an uncanny valley because it’s all too real), but more likely the failure of our tooling and techniques to keep up with this change, which has produced a noticeably, objectively inferior product.

Any change could be bucketed:

  1. noticeable going forward or backward
  2. noticeable only forward
  3. noticeable only backward
  4. totally beneath notice

Innovations that are only noticeable going forward may be things that sound like a big deal, but if you regress you probably wouldn’t notice a qualitative difference. One could further differentiate changes that depend on other advances to be useful, as with 24->48fps film relying on new techniques, or old vs. new cell phones relying on big screens and small, high capacity, fast-charging batteries.

There are implications here for innovators. When working on something, innovators aim to create value — if that value is not noticeable at a glance, it will require much more convincing to get it into the hands of users. If that value is not noticeably lost when slipping back, it’s unlikely to be an innovation with staying power. If it’s obviously better at a glance, and you notice it missing right away, it’s likely a pretty big deal. And if there’s some other thing missing which an innovation requires, now may be an opportunity to get ahead of the game by working on that missing thing, or setting the stage for when it becomes available.