Written by Ben Bishop
In the past couple of years, I’ve become very preoccupied with the concept of “quality” in software development.
One doesn’t have to look much further than the healthcare.gov website to see that this is a problem that still hasn’t been solved. Granted, there are concepts like Xtreme Programming, Lean, Agile, and Scrum, but for every successful project there’s dozens of examples of failed half measures. So when I think of quality, I don’t think of it in a utopian world where everyone buys into the “right way,” but more in the real world that I actively participate in every day. If you’ve ever read a book like “7 Habits of Highly Effective People,” practiced some sort of Zen mind set, or been in a 12 step program you find that the only way to effect real change is to focus on what you yourself can control. Not what everyone else SHOULD be doing.
With this in mind, I set out to learn more about how I can improve what I do everyday regardless of whether or not I’m working in an Agile or Waterfall environment.
One thing that I knew before setting out in my research is that saying you can generate quality by working harder is not only a flawed concept but also a very lazy attitude born out of the experiences of manufacturing. As I see it, having a boss tell you “This is unacceptable. Work harder.” is like a coach saying “Running a 9 minute mile is unacceptable. Run faster.” Yes, running faster will get you a faster mile time, but you can’t exactly flip a switch and immediately start running a 7 minute mile. You need time to build up your muscles. Time to increase the oxygen capacity of your lungs. Time to improve your stride so you aren’t wasting energy. Sure maybe you can ingest a bunch of 5-hour energies, rest for a couple of days, eat the perfect meal, and just go balls to the wall and have a great run. But how likely can you repeat that the next day?
So I set out to look at how I could improve my programming stride and build my coding muscles.
I HATE bugs. Some developers say that they love bugs. Bugs help them build a better product. I look at bugs as “F*@! I should’ve caught that” or “D@#$%^& I subconsciously knew that was there, but didn’t want to look.”
I would never want to hire a contractor to work on my house and then have to call him back repeatedly to fix things he should’ve known was a problem to begin with. Nor would I have the best view of contractors or the contracting world if that was the case with every house project. However, with software development we think this is 100% totally acceptable. Because it’s HARD. It’s COMPLICATED. No one else UNDERSTANDS. It’s my PM’s fault because I don’t have the time I need.
Wanting to throw away these lousy excuses, I started looking into Clean Code and instantly fell in love with Test Driven Development and Unit Tests. I quickly followed Uncle Bob past TDD and learned about SOLID and how it can lead to a more adaptable and flexible code base.
As I reflected on and started practicing these principles, I realized that previously there was a very strong correlation between my desire for quality and how often I would say “no.”
I would find myself saying NO for the following reasons:
– My code base was brittle and could break easily if I did anything that wasn’t in the original scope of work
– I was using a platform that was very generic and couldn’t be easily customized to accommodate the client’s request
– Didn’t have time to implement the change and do the appropriate QA before the launch/deadline
Basically, I started viewing each request as a dare from the client. A risk that may compromise the perception of the quality of my code.
This lead to a lot of friction between me and any manager or client. In mechanical engineering, friction is bad. It steals energy that could be better used propelling a car forward instead of building up heat that eventually leads to break downs. Software development is no different. Saying No is tough. It requires long emails, or god forbid, a meeting. It becomes a game. “Well, I said No to this request, I need to throw them a bone and say Yes to this other request.”
I started to imagine a world that I could say Yes. How would I feel? Would I maybe be less combative? Would I maybe *gasp* be happier because I’m not in a constant state of “This stupid client is screwing up what would’ve been a delightful day?”
And thus, the concept of Production Experience (PX) was born.
UX is widely understood as a way to ensure that users experience as little friction as possible going from point A to point B. Because it’s 2014 and software products are no longer static entities that only get updated every three years, the Experience of Production is just as vital and important as the Experience of the User.