When preparing for my first violin group performance, my teacher gave me a valuable advice that is applicable everywhere. He said, “Remember, you’ll only play 25% of what you’ve practiced on stage. There’s going to be distractions, the crowd making noise, your fellow players making mistakes, and also the fact that you can’t stop and correct your own mistakes. You just need to keep going.”
The core idea is, don’t try to do cutting edge stuff on stage if your objective is to give the audience a great performance. Practice at home, and play on stage only things with which you’re absolutely comfortable.
The usual over-enthusiastic software disaster
Imagine finally getting HBase into production. Your 45MB of big data finally has a new, comfortable, scalable, and cool home. But what happens to houses built on shaky foundations?
They eventually crumble. And that’s because you don’t probably know all the gotchas with it. Disaster recovery can get tricky even for known technologies, but with the known, no one is going to take responsibility for your failed experiments.
Just like medicines and surgical procedures that you go through have been verified to some degree and standardized, your skills need to be the same. You are generally not given experimental drugs unless you’re part of a trial.
Similarly, don’t experiment when the product requires straight results. If you endlessly experiment with a CRUD application, then you’re not effectively applying what you’ve learnt so far. Your experience becomes useless, and this creates a lot of grief down the road.
Remember, when you experiment, you often don’t have a Plan B. And Plan B, C, Ds… are very important to have because things do go wrong, and your customers won’t always be sympathetic to these disasters.
Never say never
This doesn’t mean you should never experiment. It only means that everyone should be on the same page about what’s an experiment and what’s a sure-shot expectation. Software can get complex, mostly because of the collaboration and long-term maintenance required. But some things should be simple to do after so many years, and we should keep them simple.