It’s been a pretty crazy year, with some pretty high-pressure projects. My company just had a pretty important launch that we’ve been building to for the last two years; I’ve been working on it since last October.
My project is the customer Control Panel, a portal where users manage their Cloud infrastructure (e.g. virtualized servers). This product was recently completely redesigned and rewritten with an eye towards improved user experience. I’m looking forward to blogging more about some of the things I’ve learned from it in the upcoming days and weeks, especially with an eye towards building a large client-side application using JavaScript.
Launch Day
We recently had our launch day; this was the day of the marketing blitz for our new product and when we got a huge rate of incoming new users. On that day we did over 12 deploys to production, all without downtime. We didn’t deploy to fix problems that came up; we deployed because that’s what we do every day.
Any one of these deploys could have completely broken the site or negatively impacted the user’s experience on our most high-profile day: the day when everyone was looking at us. Instead, we shipped several behavior changes, a few defect fixes, and one major feature.
We’re not grizzled veterans: three of our team members have been with the company less than 6 months and we’ve got an intern; everyone writes code that gets deployed to production and into the hands of our customers.
We have a mature continuous integration system: we run a full battery of tests on Jenkins, running unit tests, integration tests, and Selenium tests. Each of these validates that we didn’t make the site unusable or remove customer-facing functionality.
Our process has been set for the last few months in the ramp-up to launch and even though we’ve had a few issues, each time we’ve had an issue we’ve used Root Cause Analysis to fix the problems that came up.
XP Values
I had the fortune of being exposed to the Extreme Programming (XP) Values early on in my programming career, when I was working part-time in various university labs. Most XP Values are centered about the concept of Feedback: giving better transparency to the customer about what you are building, why you are building it, and how you might build it better.
My favorite XP value is Courage (alternatively, Fearlessness or Aggressiveness). The way I interpret Courage is that because of the team’s process, we don’t entertain the parts of our brains that encourage bad patterns or practices.
How do I know I won’t break something? The tests will catch it. What if I don’t understand what I have to build? We work closely with the business as a team: nobody works alone. What if I do break something? There is no individual blame; the fault is the whole team’s, and our goal is to improve the process.
Over the years, I’ve performed some pretty aggressive refactorings: some of them have gone well, and a few have caused problems that I later needed to clean up. Most of these had direct business impact: they either enabled us to develop much faster or had dramatic performance impacts. On paper all of these undertakings were terrifying, but none of them would have been possible if I was afraid to undertake them in the first place.
Write Your Code Fearlessly
Of course, fearlessness is not recklessness! When you’re faced with a risky change, stay focused on what you can do to ensure that this change can be done without danger. Don’t add defensive code just for the sake of safety – understand what the reason for each line of code is and why it’s necessary. Once you start writing code out of fear you will product lower quality code and then you will break something.
One of the most fun parts of programming is the stories that you tell about work done when the pressure was on. I’m looking forward to telling the story about how when the pressure was on, we did exactly the same thing that we’d been doing for the last few months, and everything went great.