If you aren't taking part in Steve McConnel's Software Best Practices forums, you're missing out. It's not very active yet, but it's got tons of potential. By all means, check it out.
In a really interesting thread, a poster suggested that he'd like to ban the use of the term, "Best Practices," given that it's become something of a convenient excuse that IT professionals use to excuse every insane practice under the sun, regardless of its logical suitability to the business or environment. In his particular case, he cites this lovely bit of whimsy:
The IT manager at my last place of employment had set up the network to change passwords every 30 days. His response every single time the multitudes cried out in pain was to hold up a sheet of "best practices". Yahhh!
Now, admittedly, lots of companies have this policy in place. But if the only reason you can explain the 30-day password change policy is because it's on a best practices list somewhere, you've got a problem.
The Chief Software Engineer at one of my previous employers had a staunch policy that Is-A inheritance had to be maintained at all times, and could not be violated at any time whatsoever, even if you had a perfectly good reason for doing so. He would rewrite your code behind your back to make sure it happened. "Best practices, dontcha know." End result: confused developers who had code changed on them, extra code written to support additional classes, angry developers, adversarial relationships, hostile work environment, and, eventually, employee turnover.
Blind adherence to Best Practices is a Very Bad Thing. You need to have a compelling reason to do so. If you're doing it just for the sake of doing it, you're shooting yourself in the foot, and likely pissing people off in the process.
The same is true if you're just blindly grabbing hold of The Next Big Methodology. We're inundated with methodologies in this business. Test Driven Development, Refactoring, Visual Modeling, Big Upfront Design, the Waterfall Method, Use Cases, Agile, Extreme Programming, and on and on and on. Every one of them involves risk. The risk is largely due to the fact that there are people involved, and people tend to clash, especially when they're under pressure. So you can't just foist any old methodology on them; them you have to pick the one that's going to work best for them, given the number of people that you have, the resources at your disposal, the time you have, and the project you're doing.
And let's be very clear, people: There is no Silver Bullet Methodology.
A few months ago, I responded to a thread on the Braidy Tester (a great site, love Michael Hunter's stuff) that blind adherence to "best practices" and adoption of "The Next Big Thing" without adequate analysis of the risks involved was unwise. I contended that sometimes you had to deviate from what everyone else was doing and develop your own customized methodology that might be a hodgepodge in order to get the job done, because what worked for ABC corporation didn't necessarily work for Your Real World Company, Inc.
A Microsoft Developer, who shall remain unnamed, said, in short, that I had an amateur opinion.
But the truth is that I've watched a lot of folks (and entire companies) become Best Practice Zealots, and turn this whole thing into a Fundamentalist Religion. Best practices and methodologies are supposed to help you get your job done better, faster, on time, within budget, and according to specification and customer expectations. They aren't supposed to be an iron rod with which you can bludgeon everyone around you. Too many companies are willing to just snatch up the next Silver Bullet Methodology and apply it without determining whether or not it fits their business model, their project, or their customer.
If you're going to embrace "best practices" remember this: they're guideposts, sitting on the side of the road, pointing you towards success. If you're using methodologies, they're supposed to be the route that gets you where you're going without hitting any tolls, construction sites, congestion points, and so on. Best practices and methodologies are supposed to be used together, to get you where you want to go: to a successful product delivery, with the whole team, the client, and the product intact. If anything is going awry, be willing to reevaluate your selection of practices and methodologies.
Caveat: Don't switch methodologies in the middle of the project. Jeesh. I'm not that stupid. (Though I can see where some people might think so.)
3 comments:
This is the IT version of Authoritarianism. It is just a set of rules that some people can force on others because a higher "Authority" has deemed as "correct". It amazes me to no end how intelligent people can be ridged and inflexible in their thinking.
To a certain extent, I agree.
If best practices are put in place for a good, justifiable reason and if they produce a reasonable return on their investment, then that's all well and good.
But if someone implements a practice or a methodology simply because Acme Corporation down the street does it that way, or because "we've always done it way," and can't provide a compelling reason that justifies the time, cost, and other intangible impacts on the project and team, then they're just engaging in Process Zealotry and Methodology Fundamentalism.
Where I work there is an elaborate and painful process to get a "best practice" approved. (To avoid the red tape, I only have "better practices".) Even so, there are about 250 such practices. They're listed in an Excel spreadsheet, which already tells how savvy my management is about technology.
Of the 250 some contradict each other, some are pointlessly vague (like "always consult with the user about test cases"), and some are pointlessly specific (like "column abc in table xyz holds the business code). As a result, no one -- no one! -- pays any attention to the listed practices. Having them is just a checkbox on someones compliance list.
Post a Comment