Change

Thick Culture Begins With Temporality

Thick culture begins with developing a sense of temporality: past, present, and future. I believe that if we persist without this sense, the geek trades will never be other than the dystopia we experience today. (This conversation is a hard one. Expect a rambler of a muse, here.) Start with plain ol’ professional programming. If you’re like most geeks, your current team is working on a project with lifetime measured in years, has been in production for a while, and …

Thick Culture Begins With Temporality Go to Post »

Upstream Uptime #4: Content-Level Versioning and Diagnostics

Half of the point of upstream-centric architectures is simultaneous change, and that means the content needs versioning & diagnostics, not just our transport. The biggest single difference between a modern upstream-centric architecture and our database apps: the database app doesn’t change without our control. We choose how/when we upgrade. In effect, the database, even though it’s an upstream, feels like and can be treated like just another part of the language syntax. Whether our code works, or doesn’t, and how …

Upstream Uptime #4: Content-Level Versioning and Diagnostics Go to Post »

UDispatch #2: The Second Layer

The first layer is the handy UI-capable bulk reverse-proxy, and the next thing we layer on to it is generic traffic inspection. (I should so not be writing this up right now. I got other fish to fry. But there are some blockers I’m waiting on, and I have a little time, and I just feel like mapping it out further.) Once we have that first layer running, we’ve got on our local box 1) our downstream app development environment, …

UDispatch #2: The Second Layer Go to Post »

UDispatch #1: Start With a Bulk Reverse Proxy

UDispatch has multiple layers of functionality in it. The first thing it is: a reverse proxy on the dev box that knows your upstreams and knows they’re sets. When you’re coding in a downstream, you typically have multiple upstreams you’re developing against. Service#1, Service#2, and so on. Your code sends HTTP to those services, they answer with HTTP. These services are typically arranged in sets. That is, to use Service 1A, one must also be using service 2A and 3A. …

UDispatch #1: Start With a Bulk Reverse Proxy Go to Post »

When To Start Doing TDD

TDD Pro-Tip: TDD-blockers are everywhere for me, even now, after twenty years of practicing it, so I still try new ways to work around them, and I don’t always find them, and I wait for next time. A respondent had a great question, and this is a kind of "sideways" answer. The question: Given that we’re halfway through an app w/o an architecture that TDD’s well, should we start TDD now or wait for the next greenfield chance to do …

When To Start Doing TDD Go to Post »

Upstream Uptime #3: Making Local-Runnable Services The Norm

I recently wrote about upstream-centric architectures and how we have to alter our making when we adopt them. A key alteration: change the definition of "deploy" to include "local-runnable". In that long list of problems I encountered in a real upstream-centric app I worked with a few years ago, a great many of the first-round woes come from one simple fact: "The upstream I’m coding against lives somewhere else." Network outages, rebuild blockages, vpn passwords, version stability, and dataset- app-sharing …

Upstream Uptime #3: Making Local-Runnable Services The Norm Go to Post »

Upstream Uptime #2: The Problem In Practice

We started talking about the new upstream-centric style or architecture the other day. I wanted that to be a first swing at describing the problem, but I didn’t really get there. Let’s do that now. The problems I see in many orgs attempting this approach, service-orientation or microservices, etc., are most visible when we come not to theory but to practice. One sentence: Old-school practice works in old-school apps because it holds a large part of the app fixed in …

Upstream Uptime #2: The Problem In Practice Go to Post »

Upstream Uptime #1: Grasping the Problem

Increasingly, we build apps by composition with other apps. Granting that this approach is viable, still it comes with a cluster of related problems, and to really win with this style, we’ll have to address them. An "upstream" is an independent program that my application’s correct behavior depends on at runtime. It is typically 1) across a transport mechanism, 2) in a separate process and/or machine. We’ve of course had upstreams in our lives forever: virtually all apps that use …

Upstream Uptime #1: Grasping the Problem Go to Post »

Story-Splitting #3: Easy Customer First

A valuable trick I sometimes forget: first solve the easy customer. Before we continue, I feel we need to pull some real cases in this set of muses about story splitting. It can’t be super-concrete, because a) confidentiality and b) too much detail hides the idea. Hopefully, this will help a little with figuring out analagous ways to split stories in your case.) In a medical insurance environment, we manipulate a lot of claims data, sending out invoices, making reports …

Story-Splitting #3: Easy Customer First Go to Post »

Sociotechnicality: Odd Word, Odd Concept

I’ve described the basic concept of sociotechnicality before. I know it’s an awkward word. We don’t really have an easy word for it, because some very old and successful approaches to the world that didn’t need it. The world, however, has changed. Just about everyone I’ve spoken to has some idea of what "social" is and what "technical" is. Still, let’s take at least a second to reassert these conceptural clusters. By "social", we really mean to include every topic …

Sociotechnicality: Odd Word, Odd Concept Go to Post »

Scroll to Top