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]
Comments Off on A Bridge To Nowhere
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?
Comments Off on Mtrek
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.
Comments Off on Do not look for the sense in it.
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]
Comments Off on HelloWorld.arnoldc
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.
Comments Off on Programmer speed versus computer speed
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.
Comments Off on 'You are an expert in all these technologies, and that's a good thing, because that expertise let you spend only six hours figuring out what went wrong, as opposed to losing your job.'
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. […]
Comments Off on ' … the most lunatic thing I've seen on a piece of silicon since I found out the MIPS architecture had runtime-mutable endianness.'
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. […]
Comments Off on Scratching someone else's itch
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.
Comments Off on 15 Sorting Algorithms
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]