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:
- Great blueprints make great buildings
- We don't know what users want
- Do the hardest thing first
- Security and performance are not afterthoughts
- Don't trust memory, document everything
- Let your peers save you from yourself
- Don't launch on Friday
- Maintenance is software development, too
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.