the well-bred grapefruit

“So somehow we went from this to this - system thinkers...

Thu, 11 Mar 2010 09:54:53 -0500

“So somehow we went from this to this - system thinkers who were reinventing the world, to a priesthood of folks in black turtlenecks and designer glasses working on small things.” (via Tim Brown urges designers to think big | Video on TED.com

)

via reprog.files.wordpress.com (if you don’t know who this...

Tue, 09 Mar 2010 16:41:29 -0500

via reprog.files.wordpress.com

(if you don’t know who this is)

"Maybe it is was an idea waiting to happen, or waiting to be popularised, but it seems we largely..."

Tue, 09 Mar 2010 16:37:31 -0500

“Maybe it is was an idea waiting to happen, or waiting to be popularised, but it seems we largely have Dijkstra to thank that the languages we do our work in are largely expressed in block-structured loops and conditionals rather than a maze of twisty little GOTO statements, all alike.”

- Where Dijkstra went wrong: the value of BASIC as a first programming language « The Reinvigorated Programmer

"…we should answer Question 9 by checking the last option — “Some other race” — and..."

Tue, 09 Mar 2010 15:19:07 -0500

“…we should answer Question 9 by checking the last option — “Some other race” — and writing in “American.” It’s a truthful answer but at the same time is a way for ordinary citizens to express their rejection of unconstitutional racial classification schemes.”

- Sending a Message with the Census - Mark Krikorian - The Corner on National Review Online

listening to "Mike Doughty - (You Should Be) Doubly (Gratified)"

Tue, 09 Mar 2010 09:36:57 -0500

listening to "Mike Doughty - (You Should Be) Doubly (Gratified)":

I wait for guests and they are 15 hours late

"So how much shorter are your programs if you write them in Lisp? Most of the numbers I’ve..."

Sun, 07 Mar 2010 20:24:47 -0500

“

So how much shorter are your programs if you write them in Lisp? Most of the numbers I’ve heard for Lisp versus C, for example, have been around 7-10x. But a recent article about ITA in New Architect magazine said that “one line of Lisp can replace 20 lines of C,” and since this article was full of quotes from ITA’s president, I assume they got this number from ITA. If so then we can put some faith in it; ITA’s software includes a lot of C and C++ as well as Lisp, so they are speaking from experience.

My guess is that these multiples aren’t even constant. I think they increase when you face harder problems and also when you have smarter programmers. A really good hacker can squeeze more out of better tools.

As one data point on the curve, at any rate, if you were to compete with ITA and chose to write your software in C, they would be able to develop software twenty times faster than you. If you spent a year on a new feature, they’d be able to duplicate it in less than three weeks. Whereas if they spent just three months developing something new, it would be five years before you had it too.

And you know what? That’s the best-case scenario. When you talk about code-size ratios, you’re implicitly assuming that you can actually write the program in the weaker language. But in fact there are limits on what programmers can do. If you’re trying to solve a hard problem with a language that’s too low-level, you reach a point where there is just too much to keep in your head at once.

”

- Revenge of the Nerds

Bonus points to any one who can explain all the different things that are horribly wrong with this quote.

"Thursday morning, employees at a Best Buy in South Brunswick walked into the store to find a pile of..."

Sun, 07 Mar 2010 09:17:46 -0500

“Thursday morning, employees at a Best Buy in South Brunswick walked into the store to find a pile of debris, a hole in the roof, and a bunch of missing laptops. Theft, to be sure — but how did the plunderers avoid the spider web of alarms? According to Police Sgt. James Ryan, the thieves managed to climb a gas pipe to scale the building, and used some type of suction device to lift a hole in the roof. Ryan speculates that they then lowered themselves through the hole into the store, managing somehow to keep themselves ten feet above the floor at all times, evading the store’s motion sensors. They even kept behind store banners throughout the operation, thus shielding their faces from security cameras. Upon swiping $26,000 worth of Apple laptops, they scurried out the same way they’d come in.”

- ‘Mission Impossible’-Style Best Buy Thieves Swipe Laptops, Baffle Cops

Code Kata #2, First Solution

Thu, 04 Mar 2010 16:03:51 -0500

I know, I’m a few years late on this.

But still. Better late than never, right?

My first solution is posted here.

zapnap: Sesame Street vs Twilight

Thu, 04 Mar 2010 09:22:24 -0500

zapnap:

Sesame Street vs Twilight

An Appropriate Engineering Analogy

Wed, 03 Mar 2010 10:00:49 -0500

Typically I despise the “software development is engineering” analogy. The process of developing software is so very little like building a bridge or building a house (in any modern sense, at least) that it often seems to cause more harm than good to make the comparison in the first place. But last night Erin was watching a show on HGTV, and I realized that there is a rather striking analogy that makes sense:

Looking over poorly-written software is much like looking over a poorly-constructed house.

On the outside, the house may look fine; it may even be the nicest looking house on the block. If you talk to the people living in the house, they may say that they love the house, except for a couple of minor things that need fixing (after all, they hired you for something, right?).

Once you get in and start inspecting the house’s internals, though, you start to see problems. Electrical wiring is backwards. Gas lines are run through dangerous and/or illegal areas. Drainage is poor at best, and you see signs that the foundation has been eroding away. There are patches of insulation that are flat-out missing from the walls. Load-bearing structures aren’t built with the appropriate materials. The plumbing is a tangled mesh of rusting copper. The house is unsafe, and unless it receives a lot of attention from someone who knows what they’re doing, it won’t really be safe any time soon.

Software can be a lot like that. On the outside, it can look like a very attractive piece of software, and the users can really enjoy using it (except for a couple of things that they’d like you to change, but that’s easy, right?).

Once you get inside the code, though, you can find a fragile mess. Poor error handling, convoluted logic that doesn’t cover all the use cases. There are comments in the code that are less than useless because they’re totally wrong about what the code does or why it’s doing it. Application data isn’t always handled safely. The application tries to behave concurrently but most of the operations aren’t thread-safe. To top it all off, there’s no documentation and even less automated tests, which means you have no idea how the program is supposed to work, and even if you did know that, you would have no way to verify that it was working properly.

In both cases, when you take this information to the client, the typical response is going to be “but it works, why should I pay you to fix it?” Of course, when you’re talking about houses, the response is “because your house isn’t up to the code that’s mandated by law, and above that if some of these safety issues aren’t resolved, you and your family are exposed to serious risks to your health and safety.” When you’re talking about software, the best answer you can give is “Well, I know it hasn’t caused you any problems yet, but it’s highly likely that it will in the future unless you let me rework it for you.”

In other words, where the opinions of a general contractor can be backed by physical evidence and codes and regulations, even though the house appears safe, the opinions of a programmer can only be backed by the opinions of the programmer unless there’s a demonstrable problem with the software. There’s no easy way to convince a client that there are fundamental flaws with their code, and even if you do there’s no way to convince them it’s worth training unless they already trust you and have bought into your expertise on coding.

Wouldn’t it be nice if we - as an industry - had a set of codes and regulations we could leverage to improve software? I’m not sure what those regulations would look like, or how we’d enforce them - software developers can’t agree on how many spaces to use for indentation, much less on whether they should write automated tests - but I think it’s something worth thinking about. Nothing unnecessary or specific - no “you must use x testing library,” or “you must have all your software developers in one room,” because those only serve specific agendas. Nothing that requires ‘certification’ or anything else that can be used to make money; probably just some sort of open-source document that programmers can recognize as an authority on, generally, how things should be done. Imagine how much better our industry could be if we tried to standardize on disciplines that take steps towards preventing disaster projects, and were able to use those standards to convince clients that their software needs to be made better?

Would it mean that the client would always let us make these changes? Of course not. There’s a lot less risk in the statement that “your program might crash often” than there is in the statement that “your house might burn down.” Also, I’d like to hope that no codes we create would ever be legally binding. What it would do, however, is lend strength to what you bring to the client; rather than it being you saying “You should pay me to fix these problems that you don’t really understand, but trust me, they’re problems,” there can be an industry-sanctioned document that says “Here’s the problem this programmer is telling you about, here’s why it’s a problem, and here are the risks you should consider before you decide whether to let him fix it for you.”

Just a thought… maybe a crazy one at that. But, just like a contractor who comes in and works on a house, your reputation becomes tied to every piece of software you touch. Wouldn’t it be nice if you had some better tools to convince clients that the code they have needs to be fixed?

My PDF Problem

Tue, 02 Mar 2010 12:27:54 -0500

This started as a conversation on Twitter, but I’m finding it far too difficult to explain everything to everyone in 140-character bursts, so I’m going to write this out in a blog post and hopefully that will help everyone else help me :)

I’ve recently been convicted, as you may have noticed, that I don’t do enough reading. Specifically, I don’t do enough reading related to my career in Software Development. I’m not keeping up with my field, and that’s going to come back to bite me if I don’t remedy it.

So I’ve compiled a rather large list of books that I would like to read. Some of these books I already have in hard copy form but just hadn’t gotten around to reading. Several I’ve already acquired in PDF form. Several others I have yet to acquire.

Let me lay a few things out:

I don’t want to read things on my laptop, this much I determined recently. This puts me in a bit of an odd spot with respect to the books that I already have in PDF form - I don’t want to go buy them again, but I don’t want to read them on the computer. This is largely because of the “glow” factor - I find it more difficult to sit and read on a computer screen, especially when I’ve already been working on one all day. This is more of a factor when I consider that my current favorite time to read is when I’m winding down for bed.
In several cases, PDF copies of books are as much as $20 cheaper than hard copies. While I would normally prefer to have hard copies of some books, a lot of the technical volumes I’d like to get are transient enough in value (how long is the book on Clojure going to remain accurate and useful, really?) that I don’t mind getting a cheaper digital copy.
Some books are only available as PDF.

Given all that, my first thought was that it would be nice to have an eReader of sorts, perhaps like the Kindle or the Nook. At first blush this seemed like a perfect solution - I could read PDFs without worrying about “glow,” and ultimately the costs would recoup themselves when I purchased PDFs rather than hard copies of books. There’s also a convenience factor in that I don’t have to start collecting stacks of books that will likely be useless in a few years.

But so far it seems like PDFs suck in general on the Kindle (but not the Kindle DX), and that the Nook just seems to suck in general when compared to the Kindle. There’s this crazy thing called the iPad coming out sometime soon, but it “glows.” It also does a lot more than I would really want or need it to do.

The DX is almost $500, which makes it almost prohibitive (I’m still considering it from a convenience angle, but I’d have to go through a lot of PDFs in order to make it worthwhile financially).

So, any other angles/reviews/etc. I should be aware of?

97 Things Every Programmer Should Know

Tue, 02 Mar 2010 11:17:19 -0500

Also available online here.

Some great ‘things’ in there; some not so great. Overall, a good short read.

"Good programming is not born from mere technical competence. I’ve seen highly intellectual..."

Tue, 02 Mar 2010 11:04:57 -0500

“Good programming is not born from mere technical competence. I’ve seen highly intellectual programmers who can produce intense and impressive algorithms, who know their language standard by heart, but who write the most awful code. It’s painful to read, painful to use, and painful to modify. I’ve seen more humble programmers who stick to very simple code, but who write elegant and expressive programs that are a joy to work with.”

- You Gotta Care about the Code - Programmer 97-things

Pac Man: The Movie Just… wow.

Mon, 01 Mar 2010 11:55:39 -0500

Pac Man: The Movie

Just… wow.

listening to "Flight of the Conchords - Foux du Fafa"

Mon, 01 Mar 2010 10:09:13 -0500

listening to "Flight of the Conchords - Foux du Fafa":

Baguette!

"Don’t be afraid of your code. Who cares if something gets temporarily broken while you move..."

Sun, 28 Feb 2010 22:27:40 -0500

“Don’t be afraid of your code. Who cares if something gets temporarily broken while you move things around? A paralyzing fear of change is what got your project into this state to begin with. Investing the time to refactor will pay for itself several times over the life cycle of your project. An added benefit is that your team’s experience dealing with the sick system makes you all experts in knowing how it should work. Apply this knowledge rather than resent it. Working on a system you hate is not how anybody should have to spend their time.”

- Don’t Be Afraid to Break Things - Programmer 97-things

"If we accept that code is design — a creative process rather than a mechanical one — the software..."

Sat, 27 Feb 2010 21:06:35 -0500

“If we accept that code is design — a creative process rather than a mechanical one — the software crisis is explained. We now have a design crisis: The demand for quality, validated designs exceeds our capacity to create them. The pressure to use incomplete design is strong.”

- Code Is Design - Programmer 97-things

Douglas Adams - Dirk Gently's Holistic Detective Agency

Sat, 27 Feb 2010 17:58:41 -0500

Proving once again that Douglas Adams was a creative genius. He is sorely missed.

"Technical debt is like a loan: You benefit from it in the short-term, but you have to pay interest..."

Wed, 24 Feb 2010 19:06:50 -0500

“Technical debt is like a loan: You benefit from it in the short-term, but you have to pay interest on it until it is fully paid off. Shortcuts in the code make it harder to add features or refactor your code. They are breeding grounds for defects and brittle test cases. The longer you leave it, the worse it gets. By the time you get around to undertaking the original fix there may be a whole stack of not-quite-right design choices layered on top of the original problem making the code much harder to refactor and correct. In fact, it is often only when things have got so bad that you must fix it, that you actually do go back to fix it. And by then it is often so hard to fix that you really can’t afford the time or the risk.”

- Act with Prudence

listening to "The Raconteurs - Together (official video)"

Tue, 23 Feb 2010 14:31:43 -0500

listening to "The Raconteurs - Together (official video)":

You want everything to be just like the stories that you read, but never write