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
The "pros and cons of a global distributed network" edition:
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.
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.
I was working hard on a project today and this error window came up. It pretty much describes the kind of month I'm having.
Philosophically interesting and outrageously frustrating at the same time.
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!