November 13th, 2014
A Bridge To Nowhere:
A bridge builder was completing his inspection of Zjing's Bridge when he spied master Kaimu standing nearby.
The builder said to Kaimu: "I have heard your monks speak of themselves as 'software engineers.' As a true engineer I find such talk absurd…"
"In my profession we analyze all aspects of our task before the first plank is cut. When our blueprints are done I can tell you exactly how much lumber we will need, how many nails and how much rope, how much weight the bridge will bear, and the very day it will be completed…"
"Your monks do no such things. They churn out code before your customer has finished describing what is desired. They improvise, reconsider, redesign, and rewrite a half-dozen times before delivery, and what they produce invariably crashes or proves vulnerable to attack. If I were to work in such a fashion, no one would dare set foot upon this bridge!"
[Via The Tao of Mac / links]
July 21st, 2014
Michael Lopp remembers how playing Mtrek set him on the path that led to his becoming a software engineer:
Mtrek is a real-time multiplayer space combat game loosely set in the Star Trek Universe. Sounds pretty sweet, right? Check out a screen shot.
Designed and written by Tim Wisseman and Chuck L. Peterson in the late 80s at University of California, Santa Cruz, Mtrek is completely text-based. To understand where an enemy ship was, you had to visualize the direction via the onscreen data. If this wasn't enough mental load, it was absolutely required to develop a set of macros on top of the game's byzantine keyboard commands in order to master a particular ship. Furthermore, if you weren't intimately familiar with the performance characteristics of your particular ship, you'd get quickly clobbered.
After months of playing, I learned that one of the the game's creators, Chuck L. Peterson ("clp") was a frequent player. After one particularly successful evening with my Romulan Bird of Prey, I mailed clp and asked if there was anything, however small, I could do to help with the game. Without as much a signal question to vet my qualifications, he gave me a project. […]
By way of contrast, consider Robin Sloan's piece, posted earlier today, on The secret of Minecraft. Twenty years from now, will we see a generation of coders inspired by Minecraft?
July 2nd, 2014
Craig Mod answers the question – especially relevant in the light of yesterday's post – How are apps made?
The first pass should be ugly, the ugliest. Any brain cycle spent on pretty is self deception. If pretty is the point then please stop. Do not, I repeat, do not spent three months on the radial menu, impressive as it may be. It will not save your company. There is a time for that. That time is not now. Instead, make grand gestures. General gestures. Most importantly, innumerate the unknowns. Make a list. Making known the unknowns you now know will surface the other unknowns, the important unknowns, the truly devastating unknowns – you can't scrape our content! you can't monkey park here! a tiny antennae is not for rent! You want to unearth answers as quickly as possible. Nothing else matters if your question marks irrecoverably break you. Do not procrastinate in their excavation.
June 17th, 2014
Never mind Swift, the programming language of the future is clearly ArnoldC:
Programming language based on the one-liners of Arnold Schwarzenegger.
Although the one-liners of Arnold Schwarzenegger are fairly well known the true semantics of the uttering is yet to be understood. This project tries to discover new meanings from the Arnold movies with the means of computer science.
TALK TO THE HAND "hello world"
YOU HAVE BEEN TERMINATED
Be sure to consult the wiki for further details.
[Via Waxy.org: Links Miniblog]
May 11th, 2014
Basecamp partner and Ruby On Rails creator David Heinemeier Hansson outlines the lessons learned from developing three generations of of Basecamp client apps for mobile devices.
The short version:
Decisions based on computing speeds quickly decay
The longer version (i.e. the full post) spells out just why there's no one right answer to the problem of using a mobile device to view data being pulled from a server.
I love this sort of walkthrough of software architecture decision-making.
April 30th, 2014
Imagine joining an engineering team. You're excited and full of ideas, probably just out of school and a world of clean, beautiful designs, awe-inspiring in their aesthetic unity of purpose, economy, and strength. You start by meeting Mary, project leader for a bridge in a major metropolitan area. Mary introduces you to Fred, after you get through the fifteen security checks installed by Dave because Dave had his sweater stolen off his desk once and Never Again. Fred only works with wood, so you ask why he's involved because this bridge is supposed to allow rush-hour traffic full of cars full of mortal humans to cross a 200-foot drop over rapids. Don't worry, says Mary, Fred's going to handle the walkways. What walkways? Well Fred made a good case for walkways and they're going to add to the bridge's appeal. Of course, they'll have to be built without railings, because there's a strict no railings rule enforced by Phil, who's not an engineer. [Multiple additional constraints, pet ideas and poorly described extraneous features omitted – see original post for the full, hideous and hilarious set…] After the introductions are made, you are invited to come up with some new ideas, but you don't have any because you're a propulsion engineer and don't know anything about bridges.
Would you drive across this bridge? No. If it somehow got built, everybody involved would be executed. Yet some version of this dynamic wrote every single program you have ever used, banking software, websites, and a ubiquitously used program that was supposed to protect information on the internet but didn't. […]
In all fairness to programmers everywhere, this is at least as much about how programming is organised on large-scale projects ((And in particular how the specifications are arrived at long before anyone gets to write a single line of code as it is about issues resulting from programmers' proclivities.
February 17th, 2014
I bookmarked Mike Hoye's Citation Needed weeks ago but never got round to posting a link here. Unfortunately I've forgotten where I came across the link to this piece in the first place, but I can't let that stop me. If this is the sort of thing you like, you'll enjoy this a lot:
"Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration." – Stan Kelly-Bootle
Sometimes somebody says something to me, like a whisper of a hint of an echo of something half-forgotten, and it lands on me like an invocation. The mania sets in, and it isn't enough to believe; I have to know.
I've spent far more effort than is sensible this month crawling down a rabbit hole disguised, as they often are, as a straightforward question: why do programmers start counting at zero?
Now: stop right there. By now your peripheral vision should have convinced you that this is a long article, and I'm not here to waste your time. But if you're gearing up to tell me about efficient pointer arithmetic or binary addition or something, you're wrong. You don't think you're wrong and that's part of a much larger problem, but you're still wrong. […]
December 26th, 2013
I'm always interested to read about the reasoning behind the decisions software developers make:
It took more than a year and three distinct attempts to get Google Docs in Basecamp … and still, the damn thing almost didn't get built. Why was it so hard?
We knew we needed it. Integration with Google Docs was a super-popular feature request, and usage in general is on the rise. Since Basecamp is a repository for everything project-related, it made sense to show the same love to Google Docs we show to any other type of file you can store in a Basecamp project.
Problem was, we don't really use Google Docs ourselves. […]
November 17th, 2013
15 Sorting Algorithms in 6 Minutes. Be sure to turn the sound up – it's half the fun of watching how each algorithm works.
February 13th, 2013
It turns out that we might have a new culprit to whom we can apportion a share of the blame for the financial meltdown of 2007/8. After the investment banks, the credit ratings agencies, ineffective regulators, politicians who preferred to look the other way and a section of the public that was in thrall to the idea that living on credit was a good idea, bring on Microsoft, for making Excel so temptingly easy to use any time you need to juggle some numbers. James Kwak takes up the tale:
I spent the past two days at a financial regulation conference in Washington (where I saw more BlackBerries than I have seen in years – can't lawyers and lobbyists afford decent phones?). In his remarks on the final panel, Frank Partnoy mentioned something I missed when it came out a few weeks ago: the role of Microsoft Excel in the "London Whale" trading debacle.
The issue is described in the appendix to JPMorgan's internal investigative task force's report. To summarize: JPMorgan's Chief Investment Office needed a new value-at-risk (VaR) model for the synthetic credit portfolio (the one that blew up) and assigned a quantitative whiz ("a London-based quantitative expert, mathematician and model developer" who previously worked at a company that built analytical models) to create it. The new model "operated through a series of Excel spreadsheets, which had to be completed manually, by a process of copying and pasting data from one spreadsheet to another." The internal Model Review Group identified this problem as well as a few others, but approved the model, while saying that it should be automated and another significant flaw should be fixed. […] After the London Whale trade blew up, the Model Review Group discovered that the model had not been automated and found several other errors. […]
Truth be told, this isn't really Excel's fault. If Lotus 123 for Windows and the rest of the IBM/Lotus SmartSuite had won out in the early/mid 1990s against Microsoft's Office bundle, they'd be saying exactly the same thing about Lotus 123 in that report. The real issue is that spreadsheets by their very nature just beg to be used as a quick, interactive tool for iterating your way to a solution that's 'good enough'. As various commentators at the associated Hacker News thread explain, the difficulty is that – unlike a formal programming environment used by someone who has learned the hard way that all programs have bugs so you need to test for them – spreadsheets provide almost no real framework for testing and debugging unless the user (who as often as not knows nothing of programming beyond creating Excel spreadsheets and has a worryingly elevated view of their own competence) implements one for themselves.
The two articles are fascinating; I'm going to be following some of the links in that Hacker News thread for days to come. I had no idea there was such a thing as a European Spreadsheet Risks Interest Group, but there's no denying that there absolutely should be one.
[Via The Browser]
February 9th, 2013
I read not one but two pretty good pieces today on the practicalities of developing software. I'm not a software developer by any stretch of the imagination but I have just enough of a programmer's mindset to appreciate the amount of effort it takes to think through all the little bits and pieces that make a bit of software usable as well as functional:
- Hilton Lipschitz has made multiple posts exploring the decisions he made in designing his app TimeToCall. He covers the whole process, from his having the idea to write an app to help users arrange telephone conferences across time zones, right up to the point of polishing minor but important user interface details about translating the phrases used in the Japanese language localisation of the app without breaking his user interface.
- Mark Bernstein posted a piece describing the amount of thought that had to be put into adding a tab bar to Tinderbox. This is more focussed on a single user interface element than the Lipschitz piece: multiply the number of design considerations Bernstein describes for his one feature by the number of steps in the project Lipschitz recounts and you start to realise just how many decisions go into the making of even a comparatively simple application.
Neither article is aimed solely at programmers by any means – Lipschitz and Bernstein both explain in plain English the problems they're trying to resolve and the pros and cons of the different approaches they considered, so I think even people who've never written a line of code in their life will have no problem following either post.
One more, unrelated thing (courtesy of Hilton Lipschitz's Twitter feed). If you have access to a command line, go to it right now and type either tracert 188.8.131.52 (if you're running Windows) or traceroute 184.108.40.206 (for the rest of us.) Then watch and wait…
[Hilton Lipschitz posts via Brett Terpstra. I'm afraid I can't remember where I saw a link to Mark Bernstein's post.]
October 24th, 2012
A bit of programming language nostalgia, courtesy of a contribution from Rupert Baines to this Quora thread on describing programming languages in layman's terms:
Pascal. Your grade-school teacher. A bit prim, a bit prissy but at the time you thought she was the way everyone should be. Funnily enough, none of the grown-ups had the same high impressions and afterwards you can see why.
Modula – Pascal's daughter. Died young
Forth – she was a strange girl. Creative, idiosynratic, flexible (the things she did sometimes! WOW! It could blow your mind).
But a little bit Ayn Rand, a little bit survivalist: everything had to be self-reliant. None of this co-operation malarkey. Last you heard she was somewhere in Patagonia, where she'd built a complete city from first principles, using just the forest & natural resources, from her own unique design, her own energy and a lot of bloody-minded persistence.
That said, you still have a beautiful bracelet she made for you, from metals she smelted herself, from rocks she dug up in the woods & forests: "FORTH LOVE IF SMILE THEN !"
I have to admit to having had quite the schoolboy crush on Pascal back in the day. Forth, not so much.
August 5th, 2012
One for the MacOS X users: Brett Terpstra has come up with a neat little script for Launching your entire Dock at once.
And just like that, he solves one of those issues that's been nagging away at me for ages. I'd been thinking in terms of saving a plain text list of applications that I could point a script at, but his approach of extracting the list of applications from the Dock's .plist is so much more flexible.
July 22nd, 2012
Jeff Atwood's post about the response of Stack Overflow's users to a request for examples of New Programming Jargon includes some real doozies.
18. Common Law Feature
A bug in the application that has existed so long that it is now part of the expected functionality, and user support is required to actually fix it.
I have to admit that back when I was teaching myself Visual Basic for Applications, my work included multiple instances of Stringly Typed functions. Even now, I struggle against the temptation to leave Ninja Comments.
All in all, it's just as well that I'm not being paid to write code.
May 23rd, 2012
An Introduction to Objectivist-C:
Objectivist-C was invented by Russian-American programmer Ope Rand. Based on the principle of rational self-interest, Objectivist-C was influenced by Aristotle's laws of logic and Smalltalk. In an unorthodox move, Rand first wrote about the principles of Objectivist-C in bestselling novels, and only later set them down in non-fiction.
Here's what you need to know to program in Objectivist-C.
In Objectivist-C, there are not only properties, but also property rights. Consequently, all properties are @private; there is no @public property.
In Objectivist-C, each program is free to acquire as many resources as it can, without interference from the operating system.
April 11th, 2012
One for the geeks. PHP: a fractal of bad design is a positively epic evisceration of the design philosophy behind every geek's fifth- or sixth-favourite scripting language:
There is a whole lot of action at a distance. Consider this code, taken from the PHP docs somewhere.
What will it do?
- If PHP was compiled with --disable-url-fopen-wrapper, it won't work. (Docs don't say what "won't work" means; returns null, throws exception?) Note that this flag was removed in PHP 5.2.5.
- If allow_url_fopen is disabled in php.ini, this still won't work. (How? No idea.)
- Because of the @, the warning about the non-existent file won't be printed.
- But it will be printed if scream.enabled is set in php.ini.
- Or if scream.enabled is set manually with ini_set.
- But not if the right error_reporting level isn't set.
- If it is printed, exactly where it goes depends on display_errors, again in php.ini. Or ini_set.
I can't tell how this innocuous function call will behave without consulting compile-time flags, server-wide configuration, and configuration done in my program. And this is all built in behavior.
I only have cause to use PHP at all because it's what WordPress is built on, so I'm not in a position to evaluate how bad it can get when used to build entire projects. Python seems tidier and more manageable, but in truth I haven't had much call to play around with it beyond writing a couple of scripts last year to customise adding web browser tabs to Instapaper. Most of the programming I do these days involves either some combination of Applescript and shell scripts at home, or Visual Basic for Applications if I'm at work, so I'm not sure I'm that much better off than all the PHP jockeys out there.
[Via The Null Device]
January 30th, 2012
October 31st, 2011
Things That Turbo Pascal is Smaller Than:
Turbo Pascal 3 for MS-DOS was released in September 1986. […]
The entire Turbo Pascal 3.02 executable–the compiler and IDE–was 39,731 bytes. How does that stack up in 2011 terms? Here are some things that Turbo Pascal is smaller than, as of October 30, 2011:
The minified version of jquery 1.6 (90,518 bytes).
The image of the white iPhone 4S at apple.com (190,157 bytes).
The Wikipedia page for C++ (214,251 bytes).
Not yet having made the switch to PCs at that point, I was probably still using HiSoft Pascal 4 on my ZX Spectrum, which was similarly minimalist by modern standards. But then, my Spectrum had 48 Kilobytes of RAM, so everything had to be distinctly minimalist.
[Insert standard "I feel so old!" lament here.]
[Via The Tao of Mac]
October 12th, 2011
"Reactive documents" is such a dull term: just go and play with the examples and you'll see how much fun could be had if your documents could act like spreadsheets.
[Via The Tao of Mac]