Cyclopedia Square

A co-worker who is annoyed with the verbosity of our verilog simulations just asked me if I subscribed to the Dark Cockpit Theory. I immediately replied, "no." I've had this argument a number of times with other engineers and I have already decided that more information is better than less. I had to google "dark cockpit theory" later because I'd never heard of it referred to that. For me it has always been the UNIX "Rule of Silence" . Same idea, I think. Just to be clear, I do like the Rule of Silence when it's software that I trust isn't going to do weird things or silently hang. There isn't a lot of code that I trust that much, though, and if it's software I don't trust, I want to know what it's doing, or at least that it's doing something . As I thought about this more, it's the same with people. When a person you trust is doing something for you, they can go do it without giving you any intermediat...

Pretty soon, all programming will be web programming. And I thought I was making extreme statements to make a point in my last two blog entries! I wonder if Mr. Atwood understands how much programming goes into all the hardware devices that surround him? That code isn’t written in Ruby or Javascript. As for my extreme statements about how readily software is changed, I leaned pretty heavily towards one idea. I’m not usually one to have an strong opinion out to an extreme. Engineering is all about trade-offs and holding to extreme ideals doesn’t seem to fit with good engineering. I discussed the Averse To Change essay with some friends and read the comments from all of my readers (thanks you two!). One thing that came up was the idea of using the right tool for the right problem as a bigger reason to use software, not just because it’s easy to change. But what is it that makes software the right tool? I’d say it’s the right tool for ...

This was written at the same time as Averse to Change . I’ve been jealous of mechanical or electrical engineers who can point at the direct material cost of their design, that concrete dollar amount, and say, that’s how much it costs. They gloat about redesigns that result in the same functionality but with a reduction in direct material cost. They rarely even have to talk about the cost in engineering time that it took to get to that cost reduction. Once I realized what the true value of software was, I realized that we too could use a simple measure like DM cost: lines of code. Not like the horribly misguided productivity measurements of old where more lines of code was better. When you realize that the ability to quickly make changes is priority number one, you see that less lines of code is better. I like this because it’s a lot like DM cost, where it’s easy to count and less is more, and even just a little less is usually worth the effort. In the ...

This was written about a year ago and left unpublished because it talked about people I was working with. I like the people in the examples, despite my disagreements about they way they work, and I didn't want to hurt anyone's feelings, so I left it hidden on my hard drive. After a conversation a couple days ago at my new job about the apparent recent death of software engineering , I was reminded of this essay that I had written. I think it needs to see the light of day, so hopefully with the passing of time since the examples took place nobody will get upset. There are certainly no hard feelings on my side because I am far from perfect myself. OK, on to the essay. Software (and the engineering that goes into crafting it) is a very misunderstood thing, especially at hardware focused shops. It is misunderstood by management, but that’s old news. I’m afraid it’s misunderstood by many of the engineers, even software engineers, as well. This leads to a lot of un...

If you need some good old pragmatic engineering cynicism to counter all the Steveys, Joels, and Pauls of the software blogosphere, go read the discipline and punish blog for a bit. Pretty insightful in a lot of places, and a good counterpoint to a lot of what those crazy programmer/bloggers are saying.

I spoke too soon in favor of Stevey's latest . I'm looking at all my C++ code now in a totally different light, and questioning everything...does that really need to be an enum there, or just an int? I was going to turn that C-function into a static function of this class, should I bother now? Do I need that error handler class like I was thinking Friday, or should I just stick a couple functions in this file? Are namespaces useless metadata too? Gee thanks, Steve! I mean, what do you want, for us to all write quick and dirty spaghetti code? After all, the experts who maintain it should be able to figure it out. Why don't we just write machine code, it's closer to the computation, without any verbose and useless metadata, right? Can we get a little moderation here? If you can't tell, I'm torn. I like what Steve had to say, but I hate it. I must be a noob still.

I think I'm beyond the noob stage Steve describes. I can definitely recall writing some comments like he describes a few years ago. I don't do it now. Usually. I admit that I did for that hairy calibration code just a couple months ago, for the algorithm that was handed down by the analog EE that I was supposed to just trust with blind faith. I couldn't do it. I had to understand how it worked. I read up on flyback regulators and peppered that code with so much metadata (now that I know that's what it's called) that comments and types were spilling out at every seam. So I have to disagree with Steve's conclusion a little here. He rightly points out that using the narrative style of commenting and other kinds of metadata are ways for us to learn about what we are doing, that it's a way to solidify our thought processes. His conclusion seems to be that this is a bad thing overall and that we should strive to avoid it. Personally, I hope I'm alw...

I took a class at work called, "Real-Time Software Design with UML 2.0." The instructor seemed to think that it was destined to be the Next Big Language . I have my doubts. When I design with code , I can type it very quickly and even somewhat sloppily into a code editor . The editor will then take care of formatting it all nicely, indenting, spacing, presenting with an nice font, colorizing the various code constructs, and so forth. I just have to get the ideas expressed and the tool takes care of most of the formatting for me. Even more, it's saved in a simple text format that is universal. Any text editor on any operating system will understand it. Once I've written the code, I then have a compiler and/or linter that will tell me if I've left off any key constructs, made any syntax mistakes, or any of a number of common logical errors. Basically, with the good tool support that is out there, I can write code as fast or faster than I can dream it up. ...

Packing for a family trip, we brought: A cell phone, plus charger A portable dvd player, plus charger A digital camera, plus charger An mp3 player, plus charger A GPS, plus charger A laptop, plus charger As I plugged them all in to charge the night before, and then filled an entire backpack with them the next the morning, an iPhone started to look really attractive. I think when they get GPS on that thing it's going to be very hard to resist.

Yegge gave a keynote at OSCON (which I didn't attend even though it's in my own back yard). You can watch it online (scroll down a ways and click on his picture). It's always weird to see and hear someone who's words you've only been reading for a while. He's pretty entertaining in person, but I still like his blog rants better. It was interesting what he said though. I've seen a few blog entries mention branding recently, you know, criticizing names like Haskell and Erlang, and this talk kind of solidified my understanding of how important brand is, even for geeky stuff like programming languages that are meant to be consumed by geeks, who, you would guess would think logically and choose on merits other than name. But they don't. I totally agree that Javascript needs a new name.

Just to show how randomly my thoughts wander at times, I was thinking of a problem in our code at work, and how some particular stuff really needed to be encapsulated into some functions, and I got to thinking about these fancy functional languages that the bloggers have been talking about these days, and I went and found a tutorial on Haskell and started reading it for a bit. At first the purity and cleanliness that it described was quite alluring to me. No side effects. No destructive updates. Beautiful mathematical recursive definitions of functions. This stuff is cool. But wait, how do you do some simple IO? I wondered. The tutorial read my mind and replied: If you are familiar with books on other (imperative) languages, you might be wondering why you haven’t seen many of the standard programs written in tutorials of other languages (like ones that ask the user for his name and then says “Hi” to him by name). The language is smart, and so is the tutorial! Yes! Let...

I confess, not for the first time, that I'm a sucker for the great software philosophers of our time, Paul , Stevie , and Joel , to name a few. Their blog entries and essays are entertaining and thought provoking. However I'm often left unsatisfied because too much of what they advocate just doesn't apply to firmware and embedded systems programming. Sure, high-level languages like lisp and ruby are neat-o, but I'm just not seeing how they are going to help me poll sensors, write memory-mapped registers, and manage real-time tasks better. Where are the embedded systems philosophers and gurus? I stumbled upon a few blogs the other day that might begin to qualify as good embedded systems blogs, and I want to write them down before I lost them. So here's a quick list with some accompanying rough first reactions: EmbeddedGurus.net - actually a collection of 4 interesting bloggers. Needs an aggregated RSS feed. Leibson's Law - looks pretty corporate...

This morning I somehow ended up on a string of random readings on the good ol' world wide web. It was one of those times where I can't even remember how I got started, but I ended up reading a few blog posts on some blogs that I've never really come across before, but were totally awesome. And I guess that's how this whole web logging thing got started. People finding cool stuff and feeling the need to write it down, because it was just so cool. So, as best as I can retrace my steps, I was looking for something emacs related, or maybe just reading the Planet Emacsen feed, but I found this wonderful emacs blog that I hadn't really noticed before. Specifically I found the imenu feature. Wow, that's just so handy. Especially when you bind it to your right mouse button . Somehow I also ended up on this googler's blog . I realized I had been there before because of Joel's story on Windows XP shutdown craziness . But what was more interesting was...