GeePaw

A Question Of Humbling Proportion

The road to hell is lined with convenient parking spaces. I said recently that we need fewer addresses and more routes. These slugs are attempts to get at what I think keeps going wrong for us — in the trade, possibly in entire culture. There are numerous systems for software development out there competing in mindspace. (Stock word for these is "methodology," but I resist. I’ll call them "methods", as to my reading, methodology is the study of methods.) Every […]

A Question Of Humbling Proportion See Full Post

Create Experiences Not Arguments

Change Pro-Tip: When I can give people an experience, I get dramatically better results than when I give them reasoning. I’mo tell you one of my stories. Twenty years ago, with a considerable amount of "Shut up, I’m the pro from Dover", I got permission to do TDD in a corner of the app I was working on, an app that walked remote groundstations through reconfiguration using a "console". My buddy and boss Gary was unimpressed, but I had permission,

Create Experiences Not Arguments See Full Post

Seek Judgments Not Numbers

Change Pro-Tip: I try to prioritize getting human judgments — opinions, reactions, feelings — because the quest for numbers holds too many easy traps. When I go to the doctor, she asks me how things are going. Here’s an answer I never ever give: "2.354". Could I? Sure. I could take all the numbers from all the parts of me. I could roll them up. I could make a spreadsheet. I could by averaging produce 3 decimal points of precision.

Seek Judgments Not Numbers See Full Post

Finding the Pivot Mount

Refactoring Pro-Tip: When I choose a side-by-side approach, I start by finding (or making) the "pivot mount". the place where the final switchover can take place safely. (So, I re-read that last muse, the one driving this, and I blanched. I didn’t say that very well. The price we pay for extempore musing, I spoze. Still, it’s a worthy topic, so let’s see if I can keep my promise to talk about how, even tho I change terminology from the

Finding the Pivot Mount See Full Post

Refactoring: Side-by-Side v. In Situ

Refactoring Pro-Tip: As soon as I move beyond small-scope refactorings, I ask whether my change would be easiest side-by-side or in situ. Before we even start this conversation, remember remember remember: easiest nearest owwie first, and keep repeating it. This conversation happens after we’ve found everything we can do in a scope of one or two classes. We write code iteratively in the modern synthesis. Our designs don’t burst Athena-like from our heads, fully-grown and ready to provide wisdom to

Refactoring: Side-by-Side v. In Situ See Full Post

We Haven’t Seen It All

I was on the road half to two-thirds time for for about 25 years, nearly always visiting or working with software teams. I’ve worked with teams as small as 2 and as large as 500. I’ve worked in the US, much of Europe, and even a bit of China. The orgs involved might be centered around software, product or service companies, or they might be IT departments, embedded in far larger organizations. The kind of software? Oh, every kind. Embedded

We Haven’t Seen It All See Full Post

Change the Problem

I’ll tell ya a story. Once upon a time there was a team that had it pretty good. They were internal-facing in a VBCA, supporting a variety of analysts of different types, with about 3 dozen small projects clustered around a large but mostly stable analysis model. The work was mostly about fronting the analysis model in several different ways to several different other teams, each of whom had different (fairly cool and interesting) needs. So they rolled C#, and

Change the Problem See Full Post

About Interruptions

I saw the five-minute meeting with developer thing again. Not offering it here cuz I don’t much want to give it the publicity. The gist: when you interrupt a developer the time-loss is far greater than the duration of the interruption. There are three cases being made. First, that developers are a special class of people in this. Second, that the value gained by the interruption weighs less than that lost by it. Third, that cost-of-interruption for developers is an

About Interruptions See Full Post

HTTP Clients #3: The Cost and Benefit of Fat

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

So. We’ve talked now about cost & benefit for thin-client, i.e. browser solutions. What are the cost & benefit of fat-client, i.e. app solutions? There is one primary cost for a fat client, as opposed to a thin, and it’s obvious: It doesn’t write-once-run-anywhere. Now a couple of things. We’ve already pointed out that a thin client doesn’t do that, either. But — play fair — thin clients usually run at least "okay" in more places than fat ones do.

HTTP Clients #3: The Cost and Benefit of Fat See Full Post

Scroll to Top