When I was college, I found it odd that my Computer Science classes were located in the natural science building. We weren’t studying the universe, the laws of physics, chemistry, or biology. I felt that the discipline of writing software had much closer ties to the philosophy department and the study of logic.
I have since found a number of ways that the tools of the scientific method can be key to success or failure in software projects, and I’d like to discuss my top five ways to use these tools to help your projects run smoothly.
1. Experiment Regularly
Could you ship your product using SQLite as a production database, or would its performance bog down your application? You could read a few reviews, consider the pros and cons of the architecture, and discuss with colleagues. One way to know for sure, though, is to do the experiment!
Would switching a core team practice improve your velocity? You could ask everyone to climb onto their soap boxes and duke it out, or discuss what’s worked best on past projects. Or… you could do the experiment!
While intuition and logic can and should be used as tools to discover knowledge about your problem set, nothing beats the hard data that comes from experimentation. And te results of a valid experiment will be readily accepted by your team even when discussion may lead to differing opinions. I often find that experimenting with a few possible approaches to a problem will lead a team to a better understanding of the domain and save precious time and effort going down the wrong path. Don’t make assumptions, do the experiment!
2. Gather Precise Data
Good data is key to producing successful software.
Insist on precise requirements.
Few things lead to more frustration than putting a lot of time and effort into a feature and then discovering after completion that you’ve implemented the wrong thing, or that you’ve missed key use cases. The person creating your requirements is probably very busy, but they are relying on you to build the right software as efficiently as you can. Insist that your requirements are clear and complete, and you will do a great service to your team.
Insist on clear defect reports.
Few things frustrate a developer more than a problem report stating that a feature “didn’t work.” How did it fail? What steps were taken to create the failure? What was the expected behavior?
When faced with poor defect reports, help the reporter understand what information you need to resolve their problem efficiently and completely. Provide them with a checklist. Everyone suffers when a defect fix fails to resolve the reporter’s issue.
Insist on gathering good data yourself.
Track where your time is spent, what problems end up being more expensive than anticipated, and what practices speed your team. Make implementation decisions on hard data — few things are more counter-productive than optimizations that eat up your time and obfuscate your codebase while adding little runtime value.
3. Research Your Problem
Most developers who love their jobs love them, in part, because they’re asked to solve hard problems. The opportunity to solve puzzles and think creatively is very rewarding. However, we have a responsibility to get our work done as efficiently as possible, and we rarely have the luxury to come up with ideal solutions.
Fortunately, there’s so much information available these days. Take advantage of the excellent ideas and solutions your peers have published. Perhaps you will be best served with an original solution, but you can only help your cause by familiarizing yourself with existing approaches.
More importantly, make sure that the software you’re writing is solving a well-researched problem. Good software is expensive to produce, and there’s nothing more expensive than software that fails to address a customer’s actual problems. It may be tough to push back when asked to write a feature that you don’t think has been carefully researched, but it’s a good practice to humbly and conscientiously make sure that you’re being asked to build something that is going to be useful and cost-effective.
4. Make Predictions
Two key steps in the scientific method are to create a hypothesis, and then experiment to prove or disprove it. I find this especially useful in software projects when learning a new codebase or library. When you feel that you have understood a topic or a particularly challenging piece of software, make predictions about how it will behave, and then test those predictions. If your hypothesis proves to be correct, then high fives all around, good work. The more interesting case, however, is when your hypothesis fails. Tou can save yourself much sadness by learning early where your understanding might be flawed. It’s really helpful to test your knowledge early on before baking mistakes into a codebase.
5. Name Things Precisely
Do biologists ask themselves why “felis catus” images are so popular on the internet? Well, I hope not, but there’s a lot to be learned from precise naming. Vague names for classes or variables are often code smells that indicate that you haven’t really thought a component out or haven’t identified a clear role for it.
Vague naming also makes it much more difficult for your colleagues to understand and learn your codebase. Watch for catch-all names like MainWindow or Utilities and ask yourself if you can find a name that more specifically states a responsibility for the feature you are implementing.
Intuition and creativity are key to my process of writing software, and I’d never suggest leaving those aside. But scientific tools are a wonderful complement, and a really great way to help you build the right thing, make sure you understand your problem clearly, and communicate your understanding with your colleagues. Please do Science to your software!