30 Minutes

Spending time on /r/Dota2 means that you'll inevitably come across "simple suggestions" to make the game better. A lot of them are great ideas, and I'd love to see them in the game, but it really blows my mind when people say things like, "It's such a small thing, it would take like 5 minutes to fix it, why can't they fix it now?" I was probably in this camp as a beginner programmer, but now that I have a few years under my belt, my first reaction is that nothing is as simple as it sounds.

Disclaimer: I've never worked on a game outside of uni projects!

In this case, the "simple suggestion" was that the icon displaying who is using the courier updates when someone issues manual commands, not just for the automated ones.

Valve, please show us who us using the courier

People feeding the courier need to be identified and reported. Can't successfully do it if we can't see who is controlling courier.

So the user requirement is a couple of sentences. Seems like a reasonable request - leading the courier to its death means that the team must go without one for 3 minutes (and the other team gets bonus gold), which is time wasted going back to the fountain to get items. The current state is the courier only displays who is using it for the automated bring me my items command, and not, iirc, when you send it to the secret shop, or control it manually (although this is sometimes a bit broken).

Starting my timer now!

So based on the requirement, what the user wants is the icon to update when people control the courier manually. So if someone used the "bring my items to me" command on the courier, but someone else selected it mid-path and sent it to the secret shop instead, the icon would have to be updated with the player who issued that command. That's fairly straightforward.

GIVEN Player X issues a command to the courier
WHEN Player Y issues a command to the courier
THEN Override Player X's command with Player Y's
AND Change the courier usage icon to Player Y's character

But what about some of the edge cases?

What if Player Y's command is the automated "bring my items to me" command, but then the player dies while the courier is en route to them? The courier currently heads home in this case, and the display changes to nobody using it.

Not a game-breaking "exploit", but someone could theoretically go behind enemy lines, use the command to bring the courier to them while nobody is paying attention, die, and have the courier die, too. Should the courier icon have retained the icon of the previous user? Or is it just obvious in this case what happened?

What does the icon show when the courier is dead? At the moment, it's just a dead icon and the time remaining until it respawns.

Should it retain the icon of the last player to control it? What if that was the person who was trying to save it? That might cause some unwarranted blame. But OK, let's add that, too.

It's 5 minutes in, I haven't written a single line of code, and already we have some scope creep - we now have to modify the dead courier panel. Never done any serious UI programming, so I have no idea how easy/hard it'd be to add the hero portrait somewhere, maybe squish the numbers a little and make the dead courier icon smaller. Whatever ends up happening, there will be some small discussion over what's best.

Imaginary 10 minutes in now. Let's write some unit tests. Don't want our new code to break the existing stuff! Plus, this is another chance to come up with more edge cases. I tend to be fairly slow while writing unit tests, I find sometimes that half my day is gone and I've only written tests. :S But like I said, I'm slow. This imaginary person is a super gun dev, and can copy existing tests and modify for their own purposes. So let's say 10 minutes. 

Then comes writing the actual code. I can't possibly guess the structure of the Dota 2 code, but perhaps you'd have to parts of code that control controlling the courier so they trigger the update icon function. You'd also have to write some new code to control the icon for the dead courier panel. You're probably well past the 30 minute mark by now. And you know what, it's not even the end!

Next, the code will go to the testers. They perform some dark rituals and look for defects in the code you've written, but also to make sure that the thing that you wrote does what it's supposed to do.. Their job is to break it in any way possible, because every bug they find now is one less bug that gets complained about on the forums a day after the code goes live. They're going to do more than take a cursory look over to make sure everything is OK (I hope). They are tasked with breaking things, and they're pretty good at it! It may not be that this feature added a bug on its own, but this feature in combination with the other things going in this patch might have caused a problem. So it'll get chucked back into development to try and work out what the cause is. Once it's fixed, it goes back for another round of testing.

The testers give their all clear, then it's scheduled into a patch, and goes live once that patch is released. This is usually over a period of days, so if you manage to do it in half an hour, grats to you! But chances are, you overlooked something, and you'll be back fixing it up pretty quickly.

I'm not saying this process is 100% guaranteed to remove all bugs, but the more bugs you ship in your code, the lower the confidence people have in your final product. It's maybe OK in the alpha or beta stage, but in stuff that's live, it really doesn't look good - especially if those bugs are game breaking. Then you might get called in over the weekend and get told, "gg volvo can't do anything right".