Earlier this spring Dan and I made a road trip north to the Midwest PHP Conference (read Dan’s reflections on the conference). The conference offered excellent technical instruction from a talented panel of experts. And while all of the talks I attended boosted my understanding of frameworks and code, the real wisdom came from presenter’s years of experience working with other humans.
As every developer knows, frustration over setbacks delivered by bug-ridden code is minor compared to the challenges we deal out to one another. Communication breakdowns and inconsistent systems play a far bigger role in the small dramas that unfold around project development. Here, I share some of the sage advice gleaned from conference presenters.
Note: I found Eryn O’Neil’s Project Triage: What To Do When Everything Hits The Fan particularly enlightening and much of what you’ll read below is based on Eryn’s presentation.
The Power of the 5 Whys
“5 Whys is an iterative question-asking technique used to explore the cause-and-effect relationships underlying a particular problem. The primary goal of the technique is to determine the root cause of a defect or problem by repeating the question “Why?” Each question forms the basis of the next question. The “5” in the name derives from an empirical observation on the number of iterations typically required to resolve the problem.” – Wikipedia
Working with clients over the years, I have observed misconceptions and miscommunications from both sides of the fence. Each party makes assumptions about the other, but both sides are rarely able to see the complete picture.
The 5 Whys are used to help determine the root of the problem. The technique is based on a series of questions, with each new question serving as an informed follow-up to the previous answer, always in the hope of digging a bit deeper into the problem.
For example…
Q1) Why do we keep pushing back the project deadline? (Because corporate isn’t sure about the overall design.) Q2) Didn’t they approve it during the original review? (No, they were not part of the original review.) Q3) Why were they not part of the original review? (Because they don’t have the time to attend all the meetings.)… and so forth until the fifth question.
A problem that project managers assumed was due to inconsistent deadlines or changing requirements actually reveals itself to be an issue in communication with the corporate office. Once we have a clearer picture of the problem before us we can address the issue by coming up with a more iterative approach, one that allows the client to easily view changes, without the need to commit to meetings.
Each client has a different set of problems, and it is foolish to assume what works in one case will be the right fit for everyone. Unless we take the time to derive a better understanding of one another, we will only serve to frustrate each other as we trip over simple problems we never knew existed.
Always Have an Action Plan
As the Boy Scouts would tell you, “Always be prepared”. When things fail, and as we all know, eventually everything fails; you are going to be in a panic to get them restored.
I have been programming for over 15 years and have had a fair number of disasters come my way. It could be a hardware failure, a software glitch, or just human error. It happens. Even with all those years under my belt, I still feel my stomach drop and the adrenalin spike when the application fails.
Usually, in the middle of a crisis, I go into super-production mode. The problem is – that might not always be the best solution. In my rush to get things done, I might forget a small step, or not realize another person is in the system and we cause each other problems.
In the midst of a crisis any number of “solutions” might be implemented, but without a strategic set of plans, there’s a good chance that the “solutions” will just kick off a whole new set of problems. Having an action plan is critical, it doesn’t have to be elaborate, even a simple list of steps to take in the event of an emergency can help ensure the problem is resolved more quickly and without any resonant errors.
For example, Action Plan for When the Server Crashes (because it will):
- Reference our contact list and contact John, Jane, Michael, and Joe.
- Everyone gets on our Server Response Room in HipChat.
- Quickly discuss what happened, and reference list of fixes from past cases. If this is something we know about and have a clear fix we will follow that list. If it is new we will discuss the best plan of attack and assign tasks to people.
- Fix the issue
- Once complete we will research the cause of the issue.
- Then document our fix for future reference.
That is a basic list, but for specific problems, it can be very handy. For example, you might have a “don’t forget to run this command” before you start the webserver so that the Solr Service is running appropriately.
Action plans are designed to cut down on mistakes and make it less stressful on everyone. We know we have things in hand and that we are going in the right direction.
Show Respect
I think this is important on both sides of the client/programmer fence. There are so many ways to demonstrate respect for the people you are working with: respect one another’s time, communicate clearly and consistently, make an effort to accommodate other schedules, and the list goes on.
Both the client and the company doing the work are busy. Never assume what might be going on, or that they can simply fit you in. Too often we see this with a client who might think our schedule should be wide open and we can start as soon as today. Or it might be the other way around, where we can’t understand why the client isn’t getting back immediately and that projects are falling behind weeks on end.
I believe we forgot to respect each other’s time. I wouldn’t call my doctor’s office and expect to get in immediately. In most cases, I will have to wait to get an appointment. I respect and understand why that is. My doctor is busy and has a number of patients he needs to see but I wouldn’t look for a new doctor who was otherwise giving me excellent treatment just because they couldn’t see me right away.
What I think makes the difference here is showing some respect for each other’s time, but also clear and concise communication. My doctor’s office will clearly tell me when they are free to see me. It is up to us to clearly communicate to each other what our schedules look like.
This can be the client saying, I am really busy through the holiday working with my customers, but things free up for me around the middle of January. The company hired saying, we have two other large client projects on our plate and are unable to give your project the time it needs for 3 more weeks, but can get you in immediately after that.
In most cases, clear communication will head off any brewing conflict, whether it is a schedule or a project decision.
Build a Healthy, Tolerant Culture
The temptation is always there to criticize and condemn the mistakes of others. Even though there may be a perfectly good reason for our frustration, too frequently we act on that feeling without thought of the consequences.
But what is really accomplished when you lash out or belittle someone’s mistake? In my case, I tend to shut down when feeling guilty or embarrassed. Some people simply shrug it off and move on, but more often people will do whatever they can to avoid having that experience again.
Instead, they begin to avoid situations where they might make a mistake and become more timid in their work. That might be fine in an assembly-line or rote work environment, but successful programming calls for gusto and the courage to try new things. Without a sense of support from one’s co-workers, there’s a risk of missing out on the benefits of creative decision-making.
An intimidating atmosphere can also be inefficient. If it takes twice as long to get to the bottom of a system crash because someone is afraid to admit to accidentally deleting a critical file, that’s a poor use of everyone’s time.
Success does not consist in never making mistakes but in never making the same one a second time. – George Bernard Shaw
It is important to accept that we all make mistakes, that they are not something to shame one another with, but something we can each learn from.
If we nurture a culture in which we encourage one another, not only will employees be happier, they will thrive and learn and ultimately become more adept at programming. Our mistakes can help us define better practices, build stronger workers, and encourage teamwork.
