Key practices for building software
Some time ago I decided to write down the key practices that I've found to contribute toward success in the software projects I've worked on. I came up with eight of them:
-
Great blueprints make great buildings: having a thoughtful and thorough planning process leads to clarity of scope, shared understanding about who will do what and how long it will take, and what areas of building might be high risk.
-
We usually don't know what users want: just because we use and build software that doesn't mean we understand how our users use and experience software. Creating software features that are accessible, inclusive and compelling requires research, study, testing, conversations and related work to even get close to understanding user needs.
-
Do the hardest things first: it's tempting to build the easy things first and put the hard things off until later. But the hardest and most complex features to build are the ones that have the highest risk in terms of the time they'll take and the impact of changes on the rest of your software. Tackling those first can pay dividends throughout the project.
-
Security and performance should not be afterthoughts: As soon as we start thinking of security, validation, escaping, user privacy, testing, performance profiling and related practices as features that can be pushed to version 2 or beyond, we risk never really properly integrating them into our software. They should be baked in from the start.
-
Don't trust your memory, document everything: take notes on everything you do and why you do it. Write detailed commit messages, commit early and often. Write down the details of the problems you had to solve, how you tried to solve them, what worked and what didn't. Keep a current list in front of you showing the next 2-3 key things you need to tackle to move the project forward.
-
Use peer code review where possible: find people who will review and comment on your code, architecture, approach, design, and every other aspect of your software. Be thirsty for constructive criticism and excited to learn new things.
-
Don't launch to production on Friday. :)
-
Maintenance is software development too: Releasing new features is a great feeling, but it's just as important to build in time for refactoring and improving the existing codebase. Plan bug sprints, cleanup days, test suite expansion lunches, whatever you need to keep your code sparkling and efficient over time.
Obviously every project is different and these need to be adapted accordingly. (You can read more expanded thoughts on each of these in the blog post I wrote about this same topic.)
Do these resonate with you? What are some of your key practices across your software projects?
A big part of my day job is helping enterprise orgs build better software. We lean heavily on XP for our guiding principles and have observed tremendous success in our customers for the past 31 years. I look at this list and find that while only three of the items align with our approach, it’s raised a very interesting question in my head: What are the differences in tactics between indie hacking and enterprise software development?
Pair programming obviously can’t work if you’re a solo dev, but it’s how we avoid the code review steps. You can launch to production anytime you want to if you’re following XP and have a stable PaaS, but as an indie hacker, maybe not. If you have a balanced team of product managers, designers, and engineers, the project tracker and tests written from TDD are the sources of documentation, but if you’re an indie hacker, you likely don’t have any of those things (maybe tests?)
Thanks for sharing these thoughts. I like waking up and being forced to think about things from new perspectives!
Thanks for your comments. Glad my post was helpful!
It's a great question. I know some of what I wrote above might come off as too much for someone trying to launch an MVP of their idea as quickly and cheaply as possible, especially if they are working on their own. But I also think it's never too early to start thinking about software engineering practices that will scale over time, even if it's just aspirational.
Ha. If you have sufficient testing/QA in place, including a staging environment, it's actually not that bad.
Also maybe not push too much at once, push small updates frequently instead of big updates infrequently.
With this system, I've pushed to production many times on Friday without a hiccup.
:) Yeah, I probably should have said "Don't launch complex new features to production on a Friday afternoon" or something like that. Most of the Friday launches I've been a part of have actually been fine too, but when they go wrong and reverting isn't simple and your team wasn't ready to spend the weekend working on it, it can be especially stressful.
Thanks. Quality testing is an important aspect of building software too.
This comment was deleted 4 years ago.