Challenging assumptions
There are many ideas and principles in software development that we believe to be true and often are non-negotiable for us.
Here’s a challenge for you – challenge the assumptions that you have. What if they’re not true?
For example (not that I believe any of this, just throwing it out there):
- What if TDD is a waste of time?
- What if estimating in hours is better than estimating in story points?
- What if pair programming is an inefficient use of your development team?
- What if pair programming is the most efficient use of your development team?
- What if a relational database is not the best way to store data?
- What would happen if you developed a given feature and put it into production without QA testing it at all?
- What if sitting in a co-located environment is less valuable than being able to sit in a cube with less distractions?
Like I said, I don’t necessarily believe anything I just said. I’m just trying to make your blood pressure rise a little bit when you think about some of your core principles being false.
The reason I think that this is a valuable exercise is that it forces you to think outside the box and honestly evaluate the way you do things. Most of our core principles depend on the situation. That’s why I get frustrated when people take a prescriptive process like Scrum and say that you have to follow the Scrum rules exactly as they’re laid out or you’re introducing “scrum-buts” into the process. If you haven’t adapted your process to fit your team and your environment, that would be a red flag to me that you might not understand your process or that your not trying hard enough to find ways to improve.
I don’t want to ever stop improving. I’m not going to be naive and think that I have everything figured out. At one point I thought that Windows Forms
data binding was awesome, and after that project was over, I realized that that was the totally wrong approach.
I really took to heart a quote that someone said at CodeMash a couple years ago, “If you don’t ever fail, you’re not trying hard enough.” It’s OK to fail, and when you do, you’ll learn something from it and come out a better person. But if you’re never willing to fail or too scared to consider that maybe your way is not the best way, you’re not going to take that next important step.
This is similar to a thought process I apply to my projects. Rather than asking “what if is ?”, I try to continually ask WHY we have the assumptions we do. Identifying the core principles behind those assumptions then you’re better able to identify WHEN they might not hold true.
For instance, we value TDD because it yields testable code, that isn’t over-engineered, and that has a safety net allowing us to make changes without fear. But if we’re working on a piece of code that isn’t hard to test manually, IS hard to test in an automated fashion, and is easy to modify (or easier to re-write) then the value of TDD is less clear.
When developers hear these “truisms” repeated often enough (always TDD, always pair, always whatever) they sometimes stop applying critical thought and fall into routine. Challenging assumptions, or thinking in terms of core principles rather than specific practices, is a good way to avoid that trap.
That being said, it can be scary to go against the grain on some of these things. Its a thin line between “being pragmatic” and “ignoring prevailing wisdom”.