I spoze we should talk about scaling. There are a bunch of branded solutions to the puzzle of how to organize development of large apps with large teams. I don’t know of one that is worth the bits consumed in its logo. Yesterday I mentioned assumption-boxing, that’s when we express a problem in such a way that we bind ourselves to one or a small family of possible solutions. The assumption in all the scaling brands I’ve seen: that effectively […]
Scaling Software See Full Post
“We were doing TDD just like we’re supposed to, but at some point it started hurting, so we not only quit, we told everyone else on the interwebs that TDD doesn’t work.” I met Kent Beck after a couple of years reading and writing around him, at the first ObjectMentor Extreme Programming (XP) Immersion, a wonderful week I’ll never forget, where I met so many awesome geeks and coaches. (Kent Beck, Mike Feathers, James Grenning, Bob Martin, Ron Jeffries, Martin
It happens that there are sometimes very complex changes you want to make to your code. These might involve changes to dozens of existing classes, and to the heirs of some of those, too. How do we approach this kind of situation? Recall that managing mental scope is the very heart of programming well. But any such change is sure to blow all hope of narrow mental scope right out of the water. We can only manage mental scope if
Making Complex Changes See Full Post
Alright, pre-coding design. By that, I mean, the serious thinking one does before one starts typing code into the computer. The first puzzle of pre-coding design is to identify when to start & went to stop. Start When You Have A Story When to start: when a story has been selected for implementation. That starting condition will be tricky for noobs, so let me blather for a minute. There’s no time to discuss stories in general, but in short, by
How Much Design? When To Start & When To Stop See Full Post
How to Steer a Horse Coaches come to me and ask me questions that start with "How can I get them to …" There’s a quote, I’m having a hard time finding a reference, but it’s something like this… (reference appreciated) "The easiest way to steer a horse is to want to go where the horse wants to go." I find that the easiest way to "get them to do X" is to find them wanting to do X and
Getting Them To Do X See Full Post
(Note: Lightly edited and adapted from a twitter thread, where I’m @GeePawHill. Noobs be advised, I speak freely there.) Accuracy in estimating software development times is a powerful example of forty years of "try harder" not producing any positive results. Now, given some small change X and some substantial knowledge of the current state of my software, I can usefully estimate short-term work, from a few minutes up to a 50% hit-rate around about a week. This is because I
Estimating: Stop Trying Harder See Full Post
Information and Behavior The most common difficulty confronting young coaches may be their oversimple grasp of the relationship between information & behavior. In this oversimple version, behavior derives primarily from the information possessed by the behaver. It’s quite alluring then to treat info as a surrogate for behavior. That leads to thinking every situation can be resolved by applying more/different/better info. (this is hardly unique to coaches, of course, but most of us aren’t focused on behavior to nearly the
Information Behavior Isn’t Simple See Full Post
