Pride and Prejudice: (The Vasa):
What can software engineers learn from shipbuilders?
I teach computer science to undergraduate students at a school in California, and one of my friends in the English department, of all places, made an interesting comment to me the other day. He wanted to know if my students had ever read Frankenstein and if I felt it would make them better engineers. I asked him why he thought I should assign this book, and he said he felt that a book could change the way in which people think about their relationship to the world, and in particular to technology. He wasn’t being condescending; he was dead serious. Given the number of Frankenstein-like projects that seem to get built with information technology, perhaps it’s not a bad idea to teach these lessons to computer science undergraduates, to give them some notion that they have a social responsibility. Do you agree?
Purpose-Built Languages:
While often breaking the rules of traditional language design, the growing ecosystem of purpose-built "little" languages is an essential part of systems development.
In my college computer science lab, two eternal debates flourished during breaks from long nights of coding and debugging: "emacs versus vi?"; and "what is the best programming language?" Later, as I began my career in industry, I noticed that the debate over programming languages was also going on in the hallways of Silicon Valley campuses. It was the ’90s, and at Sun many of us were watching Java claim significant mindshare among developers, particularly those previously developing in C or C++.
The Flaws of Nature:
And the perils of indecision. The latest musings of Stan Kelly-Bootle.
Multicolumnar ideas had been lurking like Greek temples in my so-called mind as 2008 came to an end. There are so many annual journalistic clichés available, looking back at all our past-years’ mistakes and resolving never to repeat them in 2009. One annoyance that I must get off my chest here and now: Can we ban such empty constructions as "X is much worse than you may think"? Or "Y is much simpler than many suppose"? We may never have thought of X one way or the other, or made suppositions about the ease of Y, yet we tend to nod and move on as though some meaningful proposition has been asserted; and, worse, that some judgment has been validated beyond dispute. Let’s learn to recognize these sneaky-weasely variations of "proof by insinuation."
The Obama Campaign:
The Obama campaign has been praised for its innovative use of technology. What was the key to its success?
On January 3, 2008, I sat in the boiler room waiting for the caucus to commence. At 7 p.m. the doors had been open for about an hour: months of preparation were coming to fruition. The phone calls had been made, volunteers had been canvassing, and now the moment had come. Could Barack Obama win the Iowa caucus? Doors closed and the first text message came from a precinct: it looked like a large attendance. Then came the second, the third, the fourth. Each was typed into our model, and a projection was starting to form. The fifth, the sixth, and now the seventh. The projection of attendance seemed solid. The Des Moines Register’s poll had been correct: more than 240,000 people participated in the Iowa caucus. The numbers were astounding, and Barack Obama was going to win it. Simple technologies enabled the campaign to create a simple, yet effective, predictive dashboard.
Case Study: Making the Move to AJAX:
What a software-as-a-service provider learned from using an AJAX framework for RIA development
Small start-up companies often face a bewildering array of technical choices: how to deliver their application, what language to use, whether to employ existing components (either commercial or open source) or roll their own... and the list goes on. What’s more, the decisions surrounding these choices typically need to be made quickly. This case study offers a realistic representation of the sorts of challenges a young start-up company faces when working to deploy a product on the Web. As with many startups, this is also a story that does not have a happy ending.
Debugging AJAX in Production:
Lacking proper browser support, what steps can we take to debug production AJAX code?
The JavaScript language has a curious history. What began as a simple tool to let Web developers add dynamic elements to otherwise static Web pages has since evolved into the core of a complex platform for delivering Web-based applications. In the early days, the language’s ability to handle failure silently was seen as a benefit. If an image rollover failed, it was better to preserve a seamless Web experience than to present the user with unsightly error dialogs.
A Conversation with Van Jacobson:
The TCP/IP pioneer discusses the promise of content-centric networking with BBN chief scientist Craig Partridge.
To those with even a passing interest in the history of the Internet and TCP/IP networking, Van Jacobson will be a familiar name. During his 25 years at Lawrence Berkeley National Laboratory and subsequent leadership positions at Cisco Systems and Packet Design, Jacobson has helped invent and develop some of the key technologies on which the Internet is based. He is most well known for his pioneering contributions to the TCP/IP networking stack, his seminal work on alleviating congestion on the Internet, his leadership in developing the MBone (multicast backbone), and his development of several widely used IP networking tools, such as trace-route, pathchar, and tcpdump.
Commentary: A Trip Without a Roadmap:
Instead of simply imagining what your users want or need, it’s always a good idea to first get their input.
Viewed broadly, programming projects fail far more often than they succeed. In some cases, failure is a useful step toward success, but all too often it is simply failure.