GeePaw

Decomposition Rage Tweet Explained

Yesterday’s irritated blurt was a matter of feels, not an attempt to offer insight or ideas. I got some queries about it, so let me wipe that slate and be a little less irritated. For now, anyway. 🙂 In geekery — in all tool use beyond a certain point, but my focus here is on the modern software development synthesis — we confront problems that have a size that is "too big to eat all at once". This is hardly […]

Decomposition Rage Tweet Explained See Full Post

Showing Code Every Day Or Two

Let’s talk a little bit about showing your working code to your product person. A basic recommendation, which will seem strange and likely freak you out the first time you hear it. Look to show your new stuff every day or two. I want to address here both the how and the why. The why has three parts: 1) just-in-time tuning, 2) food-pellets. 3) cross-specialty connection. Just-in-time tuning is just feedback. But I used an odd word, as i’m wont

Showing Code Every Day Or Two See Full Post

How The Modern Synthesis Tackles Blurgs

This entry is part [part not set] of 3 in the series Blurgs

If we’re living now and always have been in the Age of Blurgs, then our strategy might change accordingly. Before I go to some ideas from the modern we got "The Age of Blurgs", and we got "Blurgs: Try Harder Won’t Work". We need some better ideas, and the modern synthesis has some. Today I want to focus tightly on "just the coding". Coding’s not all the work doing software for money requires, not even most of it at the

How The Modern Synthesis Tackles Blurgs See Full Post

Blurgs: Try Harder Won’t Work

This entry is part [part not set] of 3 in the series Blurgs

If we’re living now and always have been in the Age of Blurgs, then our strategy might change accordingly. Before I go to some ideas from the modern synthesis that are targeted at blurgs & blurging, tho, I want to point at one thing that won’t work, and why. What won’t work is "try harder", and why it won’t work is "because humans". What I mean about just trying harder not to blurg being ineffective as a plan: blurging is

Blurgs: Try Harder Won’t Work See Full Post

The Age Of Blurgs

This entry is part [part not set] of 3 in the series Blurgs

Let’s define blurgs. A ‘blurg’ is an event where a programmer understanding of "what my code does" is not "what my code does". Blurgs are an everyday part of programming, of course. We are more often "interim" than at a sign-off point. But I mean to restrict for this conversation the idea of a blurg to being a programmer-program disconnect that occurs at a sign-off point. (a sign-off point is different for different teams. Most of the folks I work

The Age Of Blurgs See Full Post

Skeptical About Method: Another Stab

I’ve said in a bunch of different ways how skeptical I am of method. In software-for-money, applying method — structure, process, technique, algorithm, recipe, formula — seems to me to be so rarely successful across contexts as to be, idunno, the great collapsed souffle of the entire geek trade. By the time our abstraction-level has gotten high enough to incorporate the successes we’ve seen, it is also so high as to incorporate many or most of the failures we’ve seen.

Skeptical About Method: Another Stab See Full Post

Please Go Find Out

So. I dropped out of the conference scene by and large for a few years for a variety of reasons. The last couple of years I have been returning to it. I’m just home from two conferences in three weeks. I am not an extrovert, at conferences, I like to hang around with individuals or small groups. And I am drawn to smart weird people, because reasons. I am one of those people who prefers intimacy and authenticity in my

Please Go Find Out See Full Post

Always Small, Always Better, Always Wrong

Always Small, Always Better, Always Wrong. This is the mantra for anyone who seeks change in virtually any genuinely complex environment. I’ve written a lot about small and better, but not so much about wrong, which is what I want to take up today, but first, a little refresher. The complex systems I deal with professionally all fall under the simple problem statement: "make software for money". Those systems include lots of different aspects and layers. Two of these, at

Always Small, Always Better, Always Wrong See Full Post

Slicing Stories? Don’t Use Horizontal Layers

I’ve had some questions & comments about yesterday’s tweet: there are a million ways to slice stories. All the ones that slice it by layers are mistakes. Michael D. Hill (@GeePawHill) May 11, 2018 That’s natural and good and thanks to one and all. When one tweets a one-off like that, all pithy and telegraphic, folks who may not “already speak the lingo” can be mystified. I’ll take a few tweets to spell it out a little further. A little

Slicing Stories? Don’t Use Horizontal Layers See Full Post

I&I: What Increment & Iterate Means

I genuinely believe that nearly all the woe in software development, the whole socialtechnical enterprise, derives from the belief that we can sidestep increment & iteration, "a little better now" and "we’ll change it again later". This applies to the purest coding geekery, and it applies to the schmooshy marketing, and it applies to the structures and process. It applies everywhere we make changes, and in software, everywhere we make changes is everywhere. When I make attacks on certainty, i’m

I&I: What Increment & Iterate Means See Full Post

Scroll to Top