A lot of lists have popped up where I frequent (digitally, at least) lately. Intended schedules, self-diagnostics, recipes, time-lapse accomplishments, etc. You know the drill. At one point in the not-so-distant past, I was probably pretty good maintaining such things as well. I suppose I need to refine my time management skills (or lack thereof) to keep things fresh.As far as I can tell, I’ve disappeared. Or at least transitioned completely. It’s still a bit rough on Alias, but I figure she’ll get there eventually. The camaraderie I shared with many just a year ago is all but extinguished for the most part. But with an interesting exception:
Transitioning from a singles ward to a family ward (via marriage, at least) swiftly severs ties to the former. The latter is often welcoming, or at least well-meaning, and that’s good enough for me. However, others who have _also_ performed this transition (whether recently, or more distantly) appear to maintain a connection. To risk being presumptuous, it appears as though the phrase “off the market” is quite literal, and applies to more than just dating.
Occupationally speaking, things are going well — we’ve continued to make progress in a lot of different areas, and we’re beginning to really gel and form confidence (which sometimes borders on ‘reckless bravado’ when it comes to me making decisions). While I have next to no experience working with teams of software developers, we’re now in a position (or at least quickly approaching one) where our future has no alternative but to try establishing these, and running them effectively. I look forward to it. The small-team leadership I managed in Utah seems to be coming out, though I wonder if I’m becoming too bossy, too abrasive (due to time constraints, not contempt). Part of me is excited to see it happen, the remainder mortified at what could go wrong. As always, I’m forced into a delicate balance of antipodes. Such are the vicissitudes of life, I suppose.
April was synonymous with Absent for me last month — Pennsylvania, where we did standard-issue labor; Cleveland, where we assembled and performed a multi-media show (complete with blast-from-the-past reacquaintance with people from nearly a decade ago), a presentation/workshop; and Las Vegas, for NAB2009, where an incomprehensible number of unexpected events happened. At least that last part makes our future look a little less bleak, though excruciatingly busy depending on what comes of it.
This month has cooled off a bit, but there’s still much going on. This week was sacrificed to the gods of FOP, Nexenta, Asterisk, and Fedora Core. Some of those covered really cool, exciting ground, but the vast majority were simply teeth-gnashing failures and time-sinks.
That latter part prompted me to think about ratios. In signal processing (and, by extension, Audio, Video, and Radio transmission, transcoding, and mixing/filtering), there’s ratio known as the Signal-to-Noise Ratio (SNR) — The rationale is that there’s always some element of Noise (be in randomness, inaccuracy, whatever) when you’re recording something, but as long as the Signal (the important information) overpowers it significantly, it’s ok. In simpler terms, it’s the amount of static on a radio station: when the station is clear, the SNR is very high (the signal overpowers the noise), whereas when it’s staticy, or unclear, the SNR is very low (the noise is as loud, or louder than, the signal).
Back to ratios, technologies have a similar (in a rough sort of way) ratio — a Solving-to-Fighting Ratio (SFR). The idea behind this is that some technologies are “efficient” in helping solve problems — they have a well-defined feature set, adequate documentation (or at least an interested community), meaningful diagnostics, and etc. Working with these kinds of tools is pleasing as a developer because you can focus on what your task actually is. The opposite side has technologies that are “inefficient” at solving problems. Their documentation is unclear, vague, or non-existent, their community doesn’t exist, or feels morally superior (“RTFM!”), or simply incomplete feature sets.
All technologies have some amount of fighting — there’s no perfectly functional, instantly intuitive tool out there (hammers are pretty close though). But some definitely invite more than others.
Tonight, I’m going to target FOP. FOP has single-handedly consumed 20+ hours of labor from smokris and I this week, not counting “pn”, “nd”, “dd”, or “tt”‘s time. Asterisk would be a close second, but I’ll save that for a later post when this idea is more well-formed (as asterisk has a chance at not sucking completely, while FOP does not).
FOP is a programming language designed in the 1980s. It attempts to be object-oriented, which is nice. But the syntax is abysmal. As in, no indenting, no scoping, goto-only flow control, and a ridiculous number of data types (I’m not even exaggerating when I say there are hundreds). All program instructions start with the ‘.’ (dot) character. Comments, useful in helping others understand what’s going on, start with ‘..’, or two dots. This makes determining code-from-comments (a vital, basic part of a programmer’s job) unnecessarily difficult. Of the 127 ASCII values to choose from, the designers weren’t clever enough to, like, pick ANY OTHER CHARACTER to denote a comment. Idiotic.
But that’s just the beginning. This week we required a significant amount of assistance from FOP developers to figure out how to write a report-generation system. Despite 3 distinct inquiries with varying amounts of information, we got 0 useful responses. I’m not even kidding. I’m going to write the abbreviated script for you here.
cwright: We need to copy this string here (points to screen) to this place here (points to where it goes in the report).
[in a real programming language, copying variables is dead simple, and a fundamental part of the language that better not suck]
(the next day — a bad sign when copying a variable takes a day to explain)
FOPers: We created this _new_ report that sort of includes the functionality you described above. We also took the liberty of changing the user interface to present this new, completely-made-up-and-therefore-useless report as a button ambiguously labeled.
[when something as simple as variable copying is misunderstood by the developers who _work with the language_ in question, there’s a fundamental design/organizational problem that needs to be resolved. This is equivalent to me coming to your house, asking you where the bathroom is, and having you take a day to reply. Except when you reply, you point to your back yard, because you’ve heard that dogs use the backyard for a bathroom.]
cwright: thanks, but we needed it in _this_ report that, like, we need for running the effing factory.
FOPers: oh, here’s code to copy a variable. Because the types are different, and FOP has hundreds of different types with no actual type conversion (except for some of the time, which is random), you have to do it with this pattern: [provides 14 lines of code].
[when it takes 14 lines of code, including a write to a file, and a read from a file, just to copy a member variable of an object to another variable, there’s a fundamental design decision that would get even the worst windows programmer fired. I’m not kidding about the file read/write either.]
cwright: cool, we copied that pattern, and it all works, except for this one case right here:[describes broken case]
FOPers: oh, you’ll want to add [2 dozens lines of code] to [file that doesn’t exist] so that [event that isn’t defined, and never happens] can copy it.
cwright/smokris: ok, we looked all around, but the file doesn’t exist, and your code doesn’t apply. Here are the events that we have going on. When clicking the Green button in the R column on the left side of the Production screen, an event is generated that performs what we need to modify. But it’s not clear if we modify it there, or somewhere else. We’ve narrowed it down to 2 possible files.
FOPers: Green button? I don’t understand. can you send a screenshot?
[Not finding the Green Button with the directions we provided is like not being able to find the steering wheel when sitting front-facing in the driver seat of a car.]
I completely wish I was joking about the verbose, lengthy exchange above, but it’s actually that bad. Needless to say, it prompted smokris and I to spend half of the car ride hom drafting a list of Axioms when writing software (as we start training new codernauts). It basically amounted to “don’t be stupid to the user” and “don’t be stupid to whoever has to maintain this after you”. Much more interesting, so perhaps I’ll discuss that in more depth in the future.
Wow, if you’re still with me at this point, you should win a medal 🙂