TheJach.com

Jach's personal blog

(Largely containing a mind-dump to myselves: past, present, and future)
Current favorite quote: "Supposedly smart people are weirdly ignorant of Bayes' Rule." William B Vogt, 2010

Signs of Fear Driven Development

Note this is sort of a draft/WIP post... I intend to update this sporadically as I notice or re-notice new signs and perhaps rewrite in a more organized manner one day. If you're skimming, the signs are in bold text.

I've written a bit about FDD before but it's probably worth calling out separately and compiling a list of signs you, your team, or your company may be suffering from it. And possibly some suggestions for ways out.

Today's trigger for the post was actually another software evolutionary branch that got cut off with the demise of the Lisp machines. Take a look at this tweet and its replies:

See Full Post and Comments

Blog rewrite notes - supported actions

Last time I wrote about a minor itch to rewrite this blog from PHP to Lisp. I started off discussing the database schema, this time I'll briefly mention a few of the operations the code has around the data.

(Like many websites, ultimately this is just a nicer looking interface to a database.)

Websites can also be modeled as functions mapping routes to responses. This is how my code is structured. Every request (unless whitelisted otherwise) goes through index.php. It uses the first segment of the route, such as /view, to determine a more specific "service" to handle the rest of the route if it can. The services I have are:

See Full Post and Comments

Time for a blog rewrite?

I wrote this blog from scratch over a decade ago. It's still serviceable, and pretty easy to go in and edit stuff or add new things. I still like the little micro-framework I use. The language is PHP.

But a decade has come and gone, and the PHP I liked then is not the PHP in fashion now... My server is running PHP 5.5, but the code is effectively capped at 5.3, and even then uses very little features beyond the basics that PHP 5 added. That is, while other PHP projects I've worked on used things like namespaces (!) and big frameworks (!) like Yii or Symfony, this old blog is just fine with a handful of PHP 5 classes.

So what's got me thinking about a rewrite? I've heard the upgrade from PHP 5 to PHP 7 is relatively painless (my concern without looking at it is that I have to go through the code again to spruce up potential unicode issues, which I last did in 2011...). However even if that's so, and I test it out locally and do the migration work (I don't even have PHP on my gentoo system right now, partly because v5 isn't in mainline portage anymore) then I still have another obstacle: Ubuntu.

See Full Post and Comments

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