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".

Hunger Games

Posted by james on Aug. 10, 2013

(post.rating: 7)
Rating:

IMDB   Apple Trailers

I'd read the book on a whim. I just picked it out of a top seller's list. It's like Ender's Game and Twilight combined (though thankfully just a touch of the latter). Aimed at young audiences & a bit emo (especially in the second and third books), but the protagonist is captivating. The idea of a downtrodden reluctant heroine with a deep heart, self-loathing, and hidden tenaciousness is really the key here.

Jennifer Lawrence; great choice. I know fans were a bit surprised w/ her as the lead, and worried about how she'd do. She did great.

They made this PG-13. A book about children killing, burning, stabbing, dismembering other children. How?! The book is really R-rated (very violent & graphic). I suppose if you don't show blood (or just change the color) you can get away with a lot in the US. But really... the source material is R, and a real R movie would have been intense, disturbing, and would have done awful at the box office (and alienated fans). I'd be really curious to watch that movie.

It's about what I expected, maybe a bit better. It hits the finer points of the book, Lawrence does well as the protagonist. It leaves out a ton of the self-loathing & drudgery of the book, but that's probably for the better. If they can remove that a bit from the second & third books, that can only be an improvement.

I'd watch more. This isn't amazing, but neither were the books. The books were captivating & memorable though, and this doesn't hit far off.


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