Welcome to RocketMonkeys.com!

This is my personal site, where I store my rants, pictures, and movie reviews. Have a look around, register and leave comments.
-James

Show: all [rants] movies pictures

Page: Previous << [0] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 >> Next

Don't make any diagonal moves (ie. make many small changes)

Posted by james on July 25, 2015

Don't make any diagonal moves (ie. make many small changes)

While developing, it's always tempting to combine two changes at once. If you're fixing a bug in your code, and there's also an upgrade to the library you happen to be using, it's tempting to combine the two. "I may as well do both while I'm here, it'll save time."

It's true in a short-sighted sense; there is overhead to making changes, so combining changes will save overhead.

However, similar to products that have total-cost-of-ownership, there's a total-cost-of-dev for changes. This includes testing time, bug fixing time, predictability, reliability, and most imporatntly risk.

Let's assume some very random and meaningless numbers:

Change #1: 2 units of time
Change #2: 3 units of time
Overhead for a changeset: 1 unit of time

So making these changes separately:

Change #1: 2 unit
Overhead: 1 unit

Change #2: 3 unit
Overhead: 1 unit

Total: 7 units

Making the changes together:

Change #1: 2 unit
Change #2: 3 unit
Overhead: 1 unit

Total: 6 units

This saves 1 unit of time. That's good.

However, let's think total cost of dev...

Separate changes:

Change #1: 2 unit
Overhead: 1 unit
Testing time: 1 unit
Bugfix time: 1 unit

Change #2: 3 unit
Overhead: 1 unit
Testing time: 1 unit
Bugfix time: 1 unit

Total: 11 units

And combined changes:

Change #1: 2 unit
Change #2: 3 unit
Overhead: 1 unit
Testing time: 2 unit
Bugfix time: 4 unit

Total: 12 units

The trick here is to assume that 1) combining changes increases the risk of bugs, since the overall changeset is more complicated, and 2) that debugging in this case is more complicated & time consuming than if the changes were separate & smaller.

In the original example, say you make a bugfix, but in testing find that this introduces another unrelated bug. If you've also decided to upgrade the library itself, how do you know if the new bug is from your fix or the upgraded library? If downgrading the library is non-trivial, the debugging gets much more complicated & time consuming.

Even if you ignored the added complexity of debugging, there's also the fact that the amount of time saved (ie. the overhead) is trivial compared to the overall time spent. Saving a few minutes on something predicatable does not seem like a smart choice if it adds complexity and time to the already-unpredictable process of debugging. If anything, we should increase the amount of predictable time (on things like defensive programming & process) to reduce the unpredictable time (ex. spending days fixing issues on Production due to a "very simple fix" like upgrading a library or fixing a small bug).

Debugging is about removing assumptions

Posted by james on Oct. 22, 2013

Debugging is about removing assumptions you've made. When a developer gets a ticket for a bug, they immediately start diagnosing what could be causing the problem. Then they are constrained by their own assumptions.

"This is failing on the server, but working on my computer. The code is exactly the same. This can't be happening."

"I ran this same SQL query on the test server, then ran it on the prod server. They should be exactly the same server version, but it says that a certain keyword is causing a syntax error."

In almost every case, the reason the dev can't find the problem is that they're making assumptions. Remove all assumptions.

"This is failing on the server (is it? Are you looking at the right site?), but working on my computer (is it? Did you rebuild the site? Did you paste the URL into your browser, forget to hit enter, and you're looking at old code?). The code is exactly the same (Did you forget to update your repo? Did you rebuild? Is the web server holding onto a cached copy?). This can't be happening (It is)."

But many devs don't start reaching into those assumptions and testing them. Test your assumptions. Try changing the connection string to the DB. Use a different browser, clear out cache first. Rebuild the site with a debug logging statement to see that you are definitely looking at the latest code. Intentionally add an error to make sure it actually fails in a way you can see. Start commenting out lines one at a time, especially the ones that you know for a fact are "safe". They're not.

It basically boils down to this: test, don't assume. If you *think* the code is the same, *test* that the code is the same. If you think that the server has the same version, then *test* that that's the case. There is no substitute for testing. Thinking very hard, remembering, assuming, guessing; those are all other ways of saying "not testing".

Warm Bodies

Posted by james on July 4, 2013

This was more or less exactly what I expected, given the previews. Or at least, exactly what I hoped for.

A zombie movie, told from the zombie's perspective, as a emo-ish monolog. Sounds worse than it is. They stradled a fine line between satire (Shaun of the Dead) and indie-ish emo drama (Zombieland). Could have been a bit more one way or the other, but the simple POV shift made this interesting.

Not much new here besides that. The plot is ridiculous enough you just have to take it all with a grain of salt. Bonus points to Rob Corddry for not being the annoying jerk character here that he is in every other movie ever.


Page: Previous << 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 >> Next