Getting a sense for how big design spaces can be

I was recently reading Design Beyond Human Abilities. It has some neat points about how to define design, but that what all definitions seem to encompass is the idea of activities you do before building something. Furthermore, the author lists three strategies for how you go about design. He calls them three "metadesign spaces" -- in each space there are non-overlapping designs you can come up with using the assumptions of the meta space.

The work comes originally from Adrian Thompson and others. The three metadesign spaces I'll characterize by the terms "Abstract", "Iterative", and "Evolution". In the first, abstraction, the key assumption is that there is a tractable inverse model. That is, you can look at an example of the thing you want to build, or get sufficient data about it, and then work backwards to produce an abstract plan -- a blueprint, say -- and from this abstract plan more or less any competent craftsman in the field can go off and build a pretty near exact replica of the original thing.

A lot of things can fall under this category (hence, blueprints) and some software is among them. The idealized "waterfall" methodology works ok for it -- you do your design up front which involves gathering all the requirements of the final thing someone wants into a formal plan, then execute.

See Full Post and Comments

Shell shocking events

Imagine it's the start of your work day and you've decided to dig into a recently filed bug. You go to pull the latest version of a project on github, only to discover that you can't.

Why not? Turns out the company network has decided to block requests to github. No one knows why. There's a bunch of headless chickens running around in ops trying to at least restore service (and figure out why), they give updates every 30 minutes. Hours will pass before it's resolved.

What do you do during those hours? Technically you don't need the latest version of the project to spin things up, it's unlikely this bug is only present for the latest changes. Some days, you might just soldier on. Spin up the local copy you had, debug, you can eventually make a pull request with the fix whenever the network issue is resolved.

See Full Post and Comments

Honest Products

What makes me want to pursue a particular line of work, or not? A lot of things ultimately weigh on my moral calculus, including a very powerful "need money now, don't care" switch that can override many so-called principles...

One of the dimensions is the idea that my work is directly for making an "honest product". But I don't have a full definition of this thing... Sometimes it helps to look at the product's relationship to the company. Why is it being made? Just to make a profit, or some other reason? Perhaps it's a loss leader? Perhaps it's "free"? Does the company make anything else? Get its money from other products, or from other entities that aren't even products?

I currently feel I work on an honest product. Someone wrote a book about it, even. It's not my company's bread-and-butter, but we do sell a separate license (or licenses -- the book knows better than me!) for it. The people who purchase the product make use of it in a variety of ways, but it's all for direct purpose, which I think gets closer to what I mean by "honest".

See Full Post and Comments

Quote dump on perfectionism

I once wrote a ramble on the idea of "the best is the enemy of the good enough". This is a common phrase to try and get people out of "perfection paralysis", where they never do anything or show anyone anything (not even explicitly labeled work in progress!) because it's not perfect or at least "done". The idea is to ask, is it at least "good enough"? Then ship it!

My rejoinder then, and now, is a warning against the common phrase. "The good enough is the enemy of the better." But seeing that, we also see that "the best is the enemy of the better" as well. We have three values, and they're all enemies of each other, which means you need to evaluate the tradeoffs when deciding what level you want to achieve for any particular thing. Here are some of my current thoughts about the three.

The good enough: it's some artifact you've put out there. It might not measure up to your tastes, but it's something. It may not be perfect, but you don't always need perfect. Maybe you can make it better later, but it might just be good enough that you can abandon it and move on to something else. If you always settle for the good enough, though, you'll never create a perfect magnum opus. But maybe that's fine.

See Full Post and Comments

Does anime need a gateway drug?

I got into anime really late. Oh sure, I'm a 90s kid, I watched Pokemon after school and on the occasion I was somewhere with cable (most commonly my dad's) I'd enjoy watching Dragon Ball Z on the evening Toonami list (or renting episodes from Blockbuster/Hollywood Video). I watched Yu-Gi-Oh for a time, too, and a few others at random on the public networks. But I preferred American cartoons. Extreme Dinosaurs, Street Sharks, Arthur, Simpsons... And many more (on both public broadcast and when you get into the cable networks like Nick). Notably I've never liked Sponge Bob, which I use as evidence against me being a "millennial". 90s kid!

I have chat logs from June 2009 (just before I moved out onto my own for college) of a friend saying: "Maybe I'll watch Neon Gensis Evangelion."
My response was a condescending: "I'll pass on this annie may."
"Ooh, nice show. I'm watching Japanese version. Not dubbed."
"*needs dubbed*"
"Father is baaad. Hasn't seen son in 3 years. And now he asks him to come so he can pilot some machine thing. That he doesn't know how to. And might get killed."

Well, I never got around to watching it at that time. I was pretty anti-Japanese-the-language then too. My high school even offered Japanese classes, much raved about even by fellow slackers because a lot of time was spent watching anime in class, but I took French and Latin instead. Not for practicality, really, but for intellectualism.

See Full Post and Comments

Ramblings About Love 3

Deciding to publish here, too, because I'm nuts... The layer of indirection has already been broken before (it's not a secret) but breaking it further is still almost like removing an extra layer, and this just increases the probability of its breakage being nothing but a self-inflicted footgun wound. Oh well. I'm near the point where such things can't matter, anyway.

With some shenanigans this might end up being later grouped into the July month, but it was August. So much of my introspective writing comes from August for some reason, a lot of (though not all) references to "late summer" or "early fall" are just encoding around late-July/early-August. Anyway the idea is to encourage me to write a few more posts in August that aren't so conveniently grouped with this one by month, and maybe push this guy off my front page, where to be honest it's unsightly...

The content's probably not going to be that surprising to anyone who's read my about page in its entirety, but the about page is dense for a reason, and the outcome of having it more widely read is probably just a similarly self-inflicted footgun. Oh well. YOLO? Maybe something good will happen.

See Full Post and Comments

Why you should fear your automatic refactoring tool

Okay the title is clickbait. I actually encourage people to not let themselves succumb to fear-driven development. Fear is the mind-killer, stop fearing!

No really. All too often I come across people or comments about being too fearful to change software until they had "some tool" or process. The tool and processes vary, but the fear doesn't. I argue that even with no tool but your brain, you can code fearlessly. This isn't to say that tools don't help, especially when it comes to boosting confidence in correct results. I am saying that the physical sensation of fear that plagues certain programmers is entirely to do with their psyche.

If you're possessed by fear unless you have some particular tool or process, ask yourself, what if I took that tool or process away? And said you can't have it back? What are you going to do? Will you be able to move forward? The art of fearless coding is to change your perspective from an emotional one to a logical one. Instead of being fearful about the effects of some possible change, ask yourself instead how confident you are that this specific change will produce good effects over bad effects. How can you improve your confidence? Maybe you think back to the tools I took away -- what if you don't have those particular tools, how can you improve your confidence?

See Full Post and Comments

Older Posts