Post-mortem (literally) of the Knight Capital bug

It was a process error. Worth reading!

The secret of success: suck less

A really nice point by one of the authors of BugZilla: suck less over time.  This should be incorporated into any software maintenance process.

Code management at Intuit

Intuit has been around since 1983, and offers a series of financial management products that largely share a single codebase.  A codebase of 10 million lines of C.  Dr. Dobbs interviewed one of their managers about how they do that, but here's the gist:

• A single massive codebase and build system that manages multiple build variants (localized versions, versions on different platforms, actual different price-point product complexity variants, etc.).
• Continuous integration and testing.
• Automated QA.
• Rapid iteration in small teams of five or six, which I find somewhat surprising.

A couple of posts about hating programming

A post last week, "I want to fix programming," suggests that declarative programming (keeping around the "why" of what you're doing instead of the "how") would be a step up from what we're doing, and adds a couple of neat magic keywords that indicate how it might be done. Color me unconvinced, though, because just saying what you're doing and hoping the compiler is going to get it right might require a little too much from the compiler.

His specific case is a sort algorithm - he just specifies what he wants from the sort, and the compiler would do the sort. Well, I still think the answer there is to tell the compiler: "sort this stuff". Now I don't have to look at his constraints and say, "Well, wait a minute, that's a sort." If I were talking to a colleague, I wouldn't say, "All the elements of this list should match those in the other, with the constraint that each element in the list is less than the one after it." I'd say, "We'll sort this list." Then I'd look up a sort algorithm, and later, down the road, if it turned out that sort was a performance bottleneck, I'd maybe look for a better sort algorithm.

Just specifying the constraints is not enough. You're still losing information if you don't have a machine-readable set of semantics of what you're doing. (I say that as though this was already achievable with today's tools, when of course it mostly isn't, but you see my point.)

This week, we have a response, "Yup, programming is borked," and makes the cogent point that formalization of requirements is the key - and then still goes off the rails with brand-new syntax that's not human language or anything like it. He's got some interesting ideas, and is looking at authoring systems for non-programmers, which I find pretty fascinating, but I think he's still getting lost somewhere along the way.

I remain convinced that a hierarchical set of semantic views, preserved in the final program, is the way to go. Each part of the program not only has formal syntax defining it, but a conceptual framework indicating what it does, why it's done that way, changes that were made along the way, related tests (which can be seen as constraints) or even constraints (which can be seen as tests) - the whole ball of wax is right there and amenable to software manipulation. Changed requirements can then drill down right to the code that must be changed, and with sufficient sophistication, you could imagine that tools could make suggestions or even rewrite the formal syntax to conform to the requirements.

That's the goal.

Analyzing github projects by language

Interesting little project attempting to compare project behavior between languages.

Ninja - a new build system from Google

Now this is cool - minimalism always cuts closer to the semantics of a domain.

Ooh - also gyp (Generate Your Projects), a "meta-build" tool.

Norvig: How to Write a Spelling Corrector

Now here's a thought-provoking essay. It would be interesting to analyze the thought processes at a higher level of detail, but it's also useful just for thinking about how to go about doing NLP.