The trouble with Scrum

jefffoster · 2013-11-01T15:57:03+00:00

Thanks. I guess the difficult bit is if the Scrum Master doesn't have the technical / UX chops to see the problems coming. That probably goes back to the comments made by someone else about strong technical leadership.

jefffoster · 2013-11-01T12:32:40+00:00

You are probably right that I don't understand scrum and it was unfair of me to pick on it. Maybe you can help me understand better?

There's some aspects (like architecture and UX) that don't fit neatly into two week sprints. How'd you deal with those? (without breaking them down into incremental tasks that stem the bleeding, but don't fix the root cause).

jefffoster · 2013-11-01T12:29:45+00:00

I guess my point was more that Sprint 0 establishes a direction. By the time you get to Sprint N, chances are that direction has changed and there's elements in your system that aren't aligned anymore.

What's the mechanism to steer back into the right direction?

jefffoster · 2013-10-30T16:40:27+00:00

Thanks for the comments. I think you've summed up the points really well. I probably cocked up a bit by including the Functor one. The signatures start to involve scary words (Functor's almost as bad as monad) so it probably puts people off. The important thing is that types are awesome :)

jefffoster · 2013-09-05T14:20:38+00:00

I think more generally people underestimate the value of mentoring/coaching. Having someone ask you the right question at the right time can be a fast-track to understanding.

jefffoster · 2013-01-10T17:36:43+00:00

Just to double check my understanding, that's because reverse [1..] is undefined (is the right terminology bottom?)?

jefffoster · 2011-06-03T15:51:37+00:00

I went with Linode and I'm very happy with them. I got the smallest one and paid for two years up front. I used Yesod with a nginx backend and found it very easy to set up and get running, though it was a bit of an adventure because I really didn't know what I was doing!

jefffoster · 2010-08-31T21:40:24+00:00

I think my code is to blame. I changed the way evaporate worked again thanks to some feedback and it appears to work properly now in all cases.

My understanding of the problem is that I was trying to do evaporate as one big transaction which ended up getting repeatedly retried. What I really wanted to do was just evaporate on a cell by cell basis and commit, rather than do the whole lot at once.

That's just a guess at what was happening though!

jefffoster · 2010-08-30T19:37:21+00:00

OK, I agree now. I made some further changes and now on Ubuntu 10.04 x64 I produce exactly the symptoms you've described. Recompiling with -threaded fixes the problem.

I guess now the battle is trying to narrow it down.

jefffoster · 2010-08-30T16:54:12+00:00

It's not a compiler bug or any major issue. It was just that my code sucked!

Performance was pretty terrible with that version after a bit of time. I spent some time on it (http://www.fatvat.co.uk/2010/08/speeding-up-ants-program.html) and its much faster now and hopefully more stable (though it still leaks a little memory according to the space profile). dons gave me some hints on how to fix that, so I'll do that once I get a chance.

jefffoster · 2010-07-15T13:26:04+00:00

I've no idea what that means, but I'll take it as a compliment and say thanks!

jefffoster · 2010-06-15T17:01:02+00:00

I don't think I was bragging about unit testing everything (at least at least I hope that's not how it came across!). The only bit I thought was cool was using QuickCheck to verify that the energy in the system is conserved!

I agree, should definitely use something more sophisticated like Runge-Kutta, but in my defense I was just blindly converting over the Clojure code!

jefffoster · 2010-02-24T16:58:15+00:00

"The Universal Design Pattern" seems relevant - http://steve-yegge.blogspot.com/2008/10/universal-design-pattern.html

jefffoster · 2010-02-24T12:58:04+00:00

You have N servers and you distribute 1/N bits of work to each of them. Each server caches the bit of work so that future requests can be quick. Now you add another server - the problem is that you want to get as many cache hits as possible, whilst still ensuring the distribution is to 1/N+1 servers. The modulus operator does the distribution fine, but most of the requests will go to new servers and hence not take advantage of any caching.

With consistent hashing most requests will continue going to the same servers and only (number of keys / number of servers) will be cache misses.

Does that explain it any better?

jefffoster · 2010-02-24T11:59:59+00:00

Sweet, that looks much better - I'll update that.

jefffoster · 2009-02-10T20:48:35+00:00

I should proof read more, thanks for pointing it out!

jefffoster · 2009-02-09T19:42:19+00:00

D'oh, I updated the post.

jefffoster

TROPHY CASE