Tag: software_engineering

Bringing people back to the open web

Despite recent attention to the implications of giving Facebook full access to our online lives, I don't think it's shifting the average person's thinking about their use of a centralized, closed-off version of the web. For most people, the affirmation that there is no real alternative to Facebook doesn't mean they leave Facebook, it means they keep using it until something else comes along.

Of course, there is an alternative to Facebook and other walled gardens: the open web. The alternative is the version of the Internet where you own your content and activity, have minimal dependence on third party business models, can discover new things outside of what for-profit algorithms show you, and where tools and services interact to enhance each other's offerings, instead of to stamp each other out of existence.

But most users don't care about the principles or implementation of an open web, at least not in those terms. Most people don't see themselves as ever having left the open web behind, and if you told them to try to get back to it, they wouldn't know what to do or why it was worthwhile.

No matter how much it might be in their long-term self interest, it's not up to the casual Internet user to figure that out. Instead, it's up to the developers, designers, entrepreneurs and technology leaders to create a version of the open web that also happens to be the best version of the web.

Continue reading "Bringing people back to the open web" →

How I build software

At various times in my professional life I have been someone who builds software, someone who leads other people who build software, someone who sells and translates the power of custom software to clients, someone who supports the work of people who build software, and someone who tests software as a user. Each role has its joys and challenges, but I've realized that so far I find building software to be the most fun and rewarding of all of them.

This post is about some of the thinking behind how I build software and the processes I've found to work best over time:

At the end I've also included links to some books and other reading about software development that I've found useful.

Great blueprints make great buildings

There's such a thing as too much planning, but it's rarely something you find in the world of software development. Most people (myself included) who have an idea for a tool, app or other piece of software want to see their vision rendered into a working thing as soon as possible. The excitement about building often drowns out any concern for the details of what to build and how to build it.

But I know from experience that if the person who wants the software thing built (the client) is not the same as the person actually building it (the developer), there will almost always be a gap to close between each others` understanding of process, milestones, expectations and criteria for success. Even something as simple as "a website that takes a single text input and displays a message based on that input" can be reasonably interpreted and implemented a hundred different ways.

Continue reading "How I build software" →

Links for the Week - April 28, 2008

The "pros and cons of a global distributed network" edition:

Teaching software engineering

Today is the first day of the course I'm co-teaching at Earlham this semester, CS345: Software Engineering. I'm excited to be back in a classroom again and thinking in new ways and on different levels about a topic that's very much a part of what I do every day for Summersault (and why Summersault exists at all). Like the last course I taught at Earlham, this is sure to be a challenge and a joy. Wish me luck! I'll hopefully have some time to post general thoughts about teaching software engineering here, but the course website will be my main tool for collecting and sharing information and resources related to the class.

Comair flight cancellations caused by a 16-bit counter

Over the holiday weekend, Comair had to cancel over 1,000 flights because of software problems. It turns out that, as I read in the F-Secure Weblog, the flight planning software they were using was using a 16-bit counter to keep track of flight staff changes...so after 32768 changes it would simply stop working. Details are available from an article in Cincinnati Post. This is the kind of madness I was expecting for Y2K, not four years later when we're supposed to have learned that lesson by now.

Gas Pump Buffer Overflow

Random rant: In 1970, Intel produced a memory chip, the first, capable of storing 1 kilobyte of data - a couple of paragraphs of text or so. Today, one can obtain memory chips that store many gigabytes of data - enough to hold entire movies, encyclopedias, and more - for mere hundreds of dollars. So, why is it that when I finish pumping gas at a gas station and hit the "RECEIPT YES" button, the piece of crap machine can't store that one simple keystroke in its input buffer long enough that it doesn't have to ask me 5 seconds later, "RECEIPT? (YES/NO)". It can remember a credit card number, do complex fuel tax calculations, and even tell me about the latest sugar-coated crap I can buy inside, but not that I pressed that button a few seconds ago. It's a scary, scary world we live in, folks. Bah!