TL;DR – When you see a “Best Practices” article or conference session, read or attend with caution. Its likely not to help you with your current problems.
Today I read a very informative blog post about passwords and the security that they don’t provide. The one thing that stood out in that post more than anything else was the following sentence:
“Best practice” is intended as a default policy for those who don’t have the necessary data or training to do a reasonable risk assessment.
You see, I’ve always cringed when I’ve read blog posts or seen conference sessions that claim to provide “Best Practices” for a given technology or platform. People read or attend feeling that they will leave with a profound solution to all of their problems within that sphere. In the end these sessions don’t help the attendee/reader. They lack two important things; context and backing data.
“Best practices” are an attempt to commoditize solutions to what usually are very complex problems in even more complex environments. I have seen “always use HTTPS for communication between browser and web server when authenticating onto websites” as a best practice. I’m sure you have too. But does that make any sense when the traffic between the browser and web server only exists on an internal network? Possibly, if the system needs to be hardened against attack from internal company users, but this is a pretty rare scenario. So what benefit do we get from blindly following this “Best Practice” for our internal system? We have to purchase, manage, re-new, deploy and maintain SSL certs (amongst other things). And to what benefit if the risk of attack from our internal users is deemed to be low (which is what most organizations I’ve experienced would categorize it for their internal apps)?
The “Best practice” of always using HTTPS is a broadly painted practice intended to cover more situations than necessary. Why? Well these “Best practices” are intended for organizations and people that “…don’t have the necessary data or training…” These organizations and people need solutions that err on the side of caution instead of being focused for their needs. In essence, “Best Practices” are intended for audiences that are either too lazy or too uninformed about their scenarios, tools or platforms to make decisions on their own.
I know that I’m using a security scenario and referencing a security related blog post. On top of that I used phrases like “side of caution”. Don’t mistake this as a condemnation only of “Best Practices” for security related matters. I intend to condemn all “Best Practices” using the same arguments. Regardless of if those “Best Practices” are for MVC, IIS hardening, network security, design patterns, database technologies or anything else that we deal with in software development, I opine that they are worthless. Well, they have one use; to identify organizations that have neither the interest or capability to assess their specific situations and needs.
It’s been quiet around here for the last while. I’ve been spending my time and energy on some side projects that don’t really pertain directly to the art of programming. They do, however, have a degree of interaction with a programming community….and that’s where it all goes sour.
I’ve had two run-ins with this programming community over the last few months. Both times it has been related to support. I’ve been playing around with creating things for a flight simulator (www.flightgear.org to be precise). One thing that I have been working on was the modeling of an aircraft flight and autopilot systems. Again, I hoped that some of the elements of programming a simulated computer system would possibly lead to some greater development enlightenment, but the ultimate desire was to have a great simulation of this specific aircraft.
In just the last couple of weeks I ran into a problem with the graphics functionality of the software. I’m still not sure what it is. FlightGear is open source so I could dive into the codebase and figure out what is going on. I have absolutely zero desire to look at a bunch of C++ graphics code though. Since this feature is a fundamental framework support piece for what I am trying to do what I really want is for it to just work or a fix to be made. My mentality is that of yours and my mother; I don’t care how sausage is made, I just want to eat it.
With that in mind I log a defect with all of the details that the project asks for in a defect entry….and then I wait. A few weeks, and nightly builds, later I update to the latest build and the problem still persists. So I update my defect. I’m already thinking about my options for moving to another flight sim, but finally someone responds to the defect.
Lesson 1: The longer you wait to respond to defects, the more likely the defect reporter is to go find another tool/system to replace the problem system.
The first response to the defect is request for me to turn some stuff, which I vaguely recognize the meaning of, on and off. So I go looking in menu items, the project wiki and other things to see if I can figure out how to trigger these changes. Nothing. I’m stumped so I report back as such.
Lesson 2: No matter how close you are to walking away, communication is always helpful.
The next messages follow a similar pattern but also include statements like “see the wiki”, but don’t include links or specific topics that I should be referring to. So, again, I stumble around looking for the mysterious piece of information that is supposedly included in the wiki. I find nothing related to that topic. I end up digging around and eventually finding something that works the same as I was originally told to use.
Lesson 3: If your support technique is to send people to documentation to help gather debugging information, that documentation had better be both comprehensive and complete.
I’m told to increase the logging verbosity and “send the console output to a file”. I get the verbosity jacked up without any problem but I cannot get the output into a file. After a fair bit of research I find out that sending the output to a file isn’t supported in Windows for this application. Well isn’t that just nice.
Lesson 4: If you know you’re going to be supporting different platforms/environments you need to be 100% sure that your support tools and techniques work equally well for all of them.
I have been told that I should reconfigure my hardware to ensure a known baseline. My hardware is not abnormal. In fact, it is using up to date drivers and out of the box configurations.
Lesson 5: Asking for hardware configuration changes makes you look like you’re flailing and unprofessional.
So after 2 weeks, and about 6-8 hours of effort, I’m absolutely no closer to a solution that I was before.
Lesson 6: If it takes the user more than a few minutes to start the process of gathering debug information for you, then it is you (the project/developer/team) that has failed, not the user.
Before anyone says “Oh, it’s open source so you could just go fix it yourself” everyone needs to start remembering one thing; You’d never do this on a project for your employer. If you did you’d probably not be long for employment with them. So why is it any different in OSS
Lesson 7: An OSS codebase is not justification to throw good development and/or support practices out the window.
I’ve always struggled while trying to explain to teams and organizations how to setup their version control system so that the project can succeed. Ask almost any business person and they want the dev team to be able to release both at a scheduled steady pace (versioned releases) and spontaneously when needed (hotfixes). Most organizations that I’ve dealt with have a very naïve version control plan and struggle immensely once projects head to production. Usually they flail around removing partially completed, or untested, features so that a hotfix can be released quickly. After they get the hotfix pushed to production they flail away ensuring (and not always succeeding) that the hotfix will be included in the next scheduled release.
For anyone that has seen this, it’s an unmaintainable work pattern. As the application becomes more complex, ensuring that the product is stable when a hotfix is required becomes a game of chance and luck. To many organizations pour endless time (and ultimately money) into maintaining this situation in a (perceived) working state.
A solid branching pattern can help ease the pain. Don’t get me wrong, branching won’t solve the problem for you by itself. You have to have a plan. How and when do we branch? Where to we branch from and where do we merge back to? What conventions do we have in place to identify the different branch purposes? All of these things need to be standardized on a team (at a minimum) before branching has a hope of enabling a team to do what every business seems to want.
I won’t try to explain my branching policies on projects. All I’d be doing is duplicating the work by Vincent Driessen over at nvie.com http://nvie.com/posts/a-successful-git-branching-model/