James Bach says "No best practices"

Discussions

News: James Bach says "No best practices"

  1. James Bach says "No best practices" (49 messages)

    "No Best Practices," a blog by James Bach written in letter form, puts forth the idea that there are no best practices, pointing out that best practices rely on specific circumstances.
    It has a chilling effect on our progress as an intellectual craft when people pretend that a best practice exists. Best practice blather becomes a substitute for the more difficult, less glamorous, but ultimately more powerful idea of learning how to do your job. By "learning" I mean practicing the skills of identifying and solving patterns of problems we encounter as testers. Of course, that will involve patterns of behavior that we call "practices". I'm not against the idea of practices, I'm against pretense. Only through pretense can a practice that is interesting in a particular context becomes a "best practice" to which we all must bow down.
    Considering how many "hot-button" ideas there are in Java, this kind of thinking suggests that some of the tried-and-true concepts might not be as valid as they are accepted to be (i.e., EJB is bad, AJAX is good).

    He offers some common responses to his statement, and answers them. Here's one:
    "I don't mean 'best practice' literally. I'm just suggesting that this is a damn good practice."

    If you want to say it's a damn good practice, then it's just empty hyperbole to call it the BEST practice, right? But the truth is that your practice, whatever it is, is not a damn good practice. The most it can ever be is a damn good practice *within a certain context*. Outside of that context it is something else. So, please define that context before you prescribe it to me.

    A doctor who prescribes a drug without examining the patient is committing malpractice. Isn't that obvious? Would you respect such a doctor? Why should we respect people who prescribe practices without regard for the problems faced in a project?

    The answer comes back, "What if the doctor tells you to eat right and exercise?"

    And I reply "Even that is irresponsible unless that doctor has seen me. Besides, it's terribly vague. Ya call that best practice? It's vacuous blah blah."
    His closing statement:
    Do you know what's behind all this? I think it's simply that so few of us know how to do our jobs. Like puffer fish, many of us feel that we need to huff ourselves up so that predators won't devour us. We fluff ourselves full of impressive words. But when I do that I just feel empty.
    What do you think?

    Threaded Messages (49)

  2. Yes, but there are good and bad practices.
    Here is some good ones:
    http://wiki.apache.org/struts/StrutsBook

    I'd say EJB is an example of a bad bad practice, solution looking for a problem.

    .V
    http://roomity.com/demo.jsp
  3. Yes, but there are good and bad practices.Here is some good ones:http://wiki.apache.org/struts/StrutsBookI'd say EJB is an example of a bad bad practice, solution looking for a problem..Vhttp://roomity.com/demo.jsp

    When confronted with someone who thinks certain practices are *always* "good" or "bad" (without taking context into account), I'm remineded of an aphorism one of my High School English teachers always quoted:

    All generalizations are false ... including this one.

    Craig McClanahan
  4. But if there is a large EJB code base already, and you are hired to make it do a bit more functionality then it is an entirely good practice, in fact the best for that context.

    Jonathan
  5. i dont agree[ Go to top ]

    i personally feel there are best practices in any area ranging from technology to manufacturing to doing business.
    There is always a better way of doing things and bringing the better ways of doing things is wats really best practices.As its common people voice totally negative views saying there are no best practices and the kinds to justr be heard and send the crowd who have real no direction in a maze.

    Tharun George Babu
  6. i dont agree[ Go to top ]

    Me neither,

    "Best practice" implies a context, something James Bach 'scientifically' forgets...
  7. Yes, but...[ Go to top ]

    Are there worst practices? That is the question :-)
  8. Do you know what's behind all this? I think it's simply that >so few of us know how to do our jobs. Like puffer fish, many >of us feel that we need to huff ourselves up so that >predators won't devour us. We fluff ourselves full of >impressive words. But when I do that I just feel empty

    +1.
  9. Indeed,
    EJB is considered bad practise ?!&#!!
    But in some situations EJB is probably the best there is.
    If you need: RMI, JNDI Discovery, Transactions, run anywhere etc.

    For example for remote configurations of certain application.

    Unfortunaly these EJB features tend to stand in the way if you do need them or can not use them.

    I'm sick of all technology hypes.

    WE ARE PROBLEM SOLVERS!

    If a monkey in a box would solve our particular problem.
    throw away the computer and make place for your monkeys!

    Not that we all shoud start monkeying right now(hype).
    Even when Rod Johnson says that the monkeys are comming!

    Philip
  10. In my opinion, James doesn't give a compelling answer to the second "common reply" that he lists:

    "When I said this practice is a 'best practice' I meant it was best for a certain context."

    When the topic of a best practice comes up, it is understood that it's only best within a context (usually not fully specified). If you were addressing an audience that was completely ignorant of the context I'll grant that such specification is necessary.

    Furthermore, I would hope that everyone understands the term to mean "damn good practice within a certain context." Of course it doesn't mean "best possible ever, no exceptions" because that implies omniscience. Personally, I haven't read of a best practice that wasn't accompanied by some explanation of the problem context to which it applies.

    And I'm not sure what is meant by a universal context. A context is a just a description of the problem environment and it either applies or doesn't, or applies in varying degrees. Among those people for whom the context applies, the "best practice" solution is indeed universal, but only for them.
  11. i'll second that j b.

    james starts off boldly by stating there are no best practices, then saying that he can change the context and the practice is no longer valid. of course, james. a best practice is for a given context. if the context changes (requirements change), the best practice needs to be re-evaluated. there might be another best practice for that new context (or a better solution for the new requirements). thus, james:
    1. there are best practices and they apply to a given context. learn them, know when and how to use them.
    2. i wouldn't really call providing a best practice solution to a client taking advantage of them. i'd personally call that being dilligent. give the client something that's proven.
    3. how exactly is the craft chilled or slowed by providing proven solutions to problems? the proven solutions change over time as other best practices are evolve.
    4. ??
    5. those statements of course lead into the proposed solution, which should include best practices because they're proven in the industry.

    you seem to be fixated on the "best practice" term but faild to provide your definition up front. some where near the bottom perhaps? or scattered throughout? i'll give mine here: a best practice is a statement of something that has worked well for other people to solve a particular issue with a particular context. in fact, for something to become a best practice, it should be something that a LOT of people have found success with. best practices evolve as well. people find other best practices after trying something else. the good guidelines to provide people some knowledge of what has generally worked well for others.

    you also almost seem to imply that your colleague doesn't know how to do his job since he wants to suggest a best practice. i'd say if you didn't help him refine that best practice, perhaps you might look inward before casting stones.

    re: ajax .vs. ejb statement from Joseph. i'd love to see some cross platform tools for regresion testing ajax applications, and some good tools for debugging ajax applications. http unit doesn't seem to like ajax applications. what is the current alternative? we're using Load Runner/ Test Director i believe. no one understands the results or even if the application is being tested from an application perspective. but hey, the tests pass, so we're golden. on the debugging point, sure mozilla has a decent debugger, but what is used to set break points for ie and step through the code? java \script has been around about as long as java.

    ajax is a nice buz term and actually a pretty good browser based technology. the current state of the the tools for ajax applications are wors e i'd say than develoying ejb's pre xdoclet. even then, netbeans and eclipse had full debugging support for ejb code.
  12. "Furthermore, I would hope that everyone understands the term to mean 'damn good practice within a certain context.' "

    Unfortunately, that is not the case. I've seen many people do some ridiculous things because it was considered a "best practice." Often it is used as a poor substitution for reason.

    The fact of the matter is that people love to take a position or argument out of context and use it for their own ends. In this context, it motivated by apathy.
  13. Unfortunately, that is not the case. I've seen many people do some ridiculous things because it was considered a "best practice." Often it is used as a poor substitution for reason.

    One visible example is the javabeans getters and setters best pratice and its generalized usage without reason inside context. Agreed here and there.

    http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
  14. Repeat of the Obvious[ Go to top ]

    EOM
  15. If we simply go by this generalization, then we should suspect Design Patterns too -- since they also a solutions to a problem within a specific context.

    TSS should stop posting opinions of anyone. There has to be a benchmark applied to whose opinions deserve a new post.
  16. He should be a philosophor, the way he is talking about the semantics of some text....

    To put it simple, a best practise for a specific context still means that it is the best practise :)

    What you should be wary of, is the size of the context being large enough to warrant a best practise.
  17. Design Patterns are different[ Go to top ]

    Design Patterns are very much about choice. Context and consequences are an important part of the description of any design pattern. Tradeoffs between alternatives are often discussed. The literature goes to some lengths to distinguish the idea of a design pattern from any kind of "best practice".

    Regards

    John Hurst
    Wellington, New Zealand
  18. Design Patterns are different[ Go to top ]

    Design Patterns are very much about choice. Context and consequences are an important part of the description of any design pattern. Tradeoffs between alternatives are often discussed. The literature goes to some lengths to distinguish the idea of a design pattern from any kind of "best practice".RegardsJohn HurstWellington, New Zealand

    Yes, and yet we have lots of people talking about good and bad desing patterns.

    Take, for example, the Classic Singleton Pattern. It used to be much loved and has then been abandoned, because a general state is deemed inacceptable. Nowadays, the Singleton is actually considered "bad practice".

    Yet, looking something the NSApplication, NSFileManager (actual) singletons in the MacOS cocoa framework they unleash an extremely powerful concept in a very simple way.
  19. A great little post - made me smile on Monday. In particilar:

    >"This practice represents a consensus among industry
    >leaders."
    >
    >No it doesn't. You're just making that up.
    >
    >...
    >
    >It kind of reminds me of this advice: don't get sick. I
    >would like to follow that advice, but I'm not necessarily
    >able to.
    >
    >...

    In our world there is best practice in the context of software fashion. i.e. as software depts/houses/consultancies the way we get new projects off the ground is by saying (very quickly)

    "this new grid solution will be a million times faster, its simpler because the grid does all the comms and rollout, and we will use Hibernate so we don't hand crank the OR and Spring because if we do TDD then it will all work totally, especially because we are agile and all our developers are also BA's. In fact we don't need BA's. Also, and get this, the grid is service based, so we will use SOA which means we can devide and conquer."

    Three years ago the language was entirely different.
    "the new app server solution will be robust and scaleable, it's faster becuase it does caching and robust because it does failover for us, and we will use CMP entity beans so we don't hand crank the OR. We also have some great BA's who have got the requirements together and UML to communicate these to both users and techies. We will use XML for all comms, with GLUE for our SOAP implementation. The three tiered design with MVC, session beans and entity beans means we have segmented the code so we can devide and conquer".

    Six years ago, it was:
    "I've got this great idea, we will sell fur lined underwear, on the web, during the summer. I've got some venture capital and our business plan shows 6 million clients in 2 years time... technology, oh yeah, that's the day job. Linux, PHP, Apache, get it working, go go go. Or for consultancies, JSP, web farms, JDBC, Oracle, XML if we can."

    Nine years ago, trying to remember, it was:
    "We will by some ORB's and use Corba as our open protocol (IIOP) so we can have cross platform services. This is fast and scalable as it does all the comms for us. We will use stored procs as they are compiled in the DB, and are blisteringly fast, the client code is protected from the database. Our BA has a great requirements document and we will use waterfall to ensure we understand the problem, and deliver to the complete spec. This protects us from feature creep and gives us the basis for a contract. The client server architect means we are using the new power in the desktop as much as possible, while embedding large data operations in the database, close to the data which is where it belongs".

    One thing I have noted is that many testers hate our guts when we spout this stuff. For them, learning the latest fashion is a total waste of time, creates huge churn in the systems they test, and which have to be supported.

    They do not understand that without "this obvious progress", not nearly as many of us would be in work. And without the buzz words how would we show we are the best of the best (practice).

    Jonathan
  20. A great little post - made me smile on Monday. In particilar:>"This practice represents a consensus among industry >leaders.">>No it doesn't. You're just making that up. >>...>>It kind of reminds me of this advice: don't get sick. I >would like to follow that advice, but I'm not necessarily >able to. >>...In our world there is best practice in the context of software fashion. i.e. as software depts/houses/consultancies the way we get new projects off the ground is by saying (very quickly)"this new grid solution will be a million times faster, its simpler because the grid does all the comms and rollout, and we will use Hibernate so we don't hand crank the OR and Spring because if we do TDD then it will all work totally, especially because we are agile and all our developers are also BA's. In fact we don't need BA's. Also, and get this, the grid is service based, so we will use SOA which means we can devide and conquer.

    Blasphemy! You've used Spring in a negative context. I will write a blog about how you are the scum of the earth and are either brainwashed by the JBossians, or a JBossian astroturfing on TSS.

    Seriously though, but are people writing successful applications using Spring+Hibernate+SOA+agile? Sure they are.
    "Three years ago the language was entirely different."the new app server solution will be robust and scaleable, it's faster becuase it does caching and robust because it does failover for us, and we will use CMP entity beans so we don't hand crank the OR....more EJB/JEE stuff

    Again, did people create successful applications using this approach? Sure they did. I know, I was involved with a few of them.
    Six years ago, it was:"I've got this great idea, we will sell fur lined underwear, on the web, during the summer. I've got some venture capital and our business plan shows 6 million clients in 2 years time... technology, oh yeah, that's the day job. Linux, PHP, Apache, get it working, go go go. Or for consultancies, JSP, web farms, JDBC, Oracle, XML if we can.

    And did people write successful applications using this approach? Sure they did...(Sorry I wasn't one of them. Was never fond of scripting).
    "Nine years ago, trying to remember, it was:"We will by some ORB's and use Corba as our open protocol (IIOP) so we can have cross platform services.

    Funny how we come full circle with SOA and Web services, eh? But still, people created successful applications using this approach. I know, I was involved with a few of them.

    Ok, so my whole point is...Its the talent of your development team and how it is managed that is more important than the "best practices" you are using. I'm always wary of those that say "this is the only logical way of doing things. You are an idiot for suggesting otherwise."
    One thing I have noted is that many testers hate our guts when we spout this stuff. For them, learning the latest fashion is a total waste of time, creates huge churn in the systems they test, and which have to be supported.

    I usually find that testers are a total waste of time and cause me nothing but aggravation, JBoss QA is the exception of course ;-), so who cares if they hate us?

    BTW, it is cool to read a post that has some perspective...

    Bill
  21. Cheers Bill.
  22. The reason for the "best practices" interest is the fact that software engineering has no basis in mathematics. All other engineering branches are based on a theoretical foundation, except ours (Computer Science does not count, as it is about computer, not people). That is the reason for the hand weaving, buzzwords, and best practices interest. I hope once learning theory, pshycology and other related sciences become more empirical, software engineering will get a solid basis, and we won't have to argue which approach is better than the other.

    I aggree with the spirit of the article; I remember this doctoral student in CS arguing with me (with great passion I might add) that small but many classes are better than middle-sized but less numbered classes in object oriented design. My immediate thinking at the time was that, "how the F** do you know that?". Instead of saying "this is my approach", this idiot is taking a subjective observation and trying to make it a scientific reality.

    Having said that, given the shabby foundation we have, the search for best practices is still important. We must, at all step of the process, point out the deficiencies of current method, but still must strive to find some commonalities, fight for cleaner *languages* (not point click tools -hmm, sounds subjective doesn't it-), and try to make sense out of chaos. Ours is a black art still, so we should try to demystify it to best of our ability. I believe we have some set of best practices that have stood the test of time. Because of our shabby foundation, it's natural we will argue much on the new ones, but overtime, experience will validate the good ones and get rid of the bad ones.
  23. Blah Blah Blah[ Go to top ]

    Sounds like a pedantic puffer fish to me.

    The aurgument doesn't hold water ad I don't think he has adequately defended it. While I too chaffe at much of the jingoistic, hyperbolic nature of our industry, 'Best Practices' is not one of them.

    For instance, in my line of work (SCM) it is common to say 'Automating your builds' is a Best Practice. And it is though I'm sure James would call it 'vacuous blah blah.'

    I wonder what he would call the work that came out of the SEI? Stuff like the CMM which is extracted best practices culled for dozens if not hundreds of defense contractors.
  24. Blah Blah Blah[ Go to top ]

    I wonder what he would call the work that came out of the SEI? Stuff like the CMM which is extracted best practices culled for dozens if not hundreds of defense contractors.

    Well, here's a couple of quotes from an article written by one James Bach about the CMM:
    The CMM is at best a consensus among a particular group of software engineering theorists and practitioners concerning a collection of effective practices grouped according to a simple model of organizational evolution. As such, it is potentially valuable for those companies that completely lack software savvy, or for those who have a lot of it and thus can avoid its pitfalls.

    At worst, the CMM is a whitewash that obscures the true dynamics of software engineering, suppresses alternative models. If an organization follows it for its own sake, rather than simply as a requirement mandated by a particular government contract, it may very well lead to the collapse of that company's competitive potential. For these reasons, the CMM is unpopular among many of the highly competitive and innovative companies producing commercial shrink-wrap software.
    The CMM was originally meant as a tool to evaluate the ability of government contractors to perform a contracted software project. It may be suited for that purpose; I don't know. My concern is that it is also touted as a general model for software process improvement. In that application, the CMM has serious weaknesses.

    If it's the same James Bach then I think that answers your question. You can read the full article at http://www.satisfice.com/articles/cmm.htm
  25. In 10 years of software developement, this is I think when someone says something is a "Best Practice".

    1) Someone just read a magazine article.
    2) Someone has found a solution to a problem that they know how to execute. But they aren't confident that their solution is the most efficient one.

    These are some of the "Best Practices" that I want to see in software development:

    1) Show up for work and meetings on time!
    2) Comment your damn code.
    3) Hey business analyst, how about some freaking requirements!
    4) There is no reason why a meeting should last over 1 hour.
    5) Stop being lazy with variable names. A couple extra key strokes makes your code readable. If you don't make readable code, that means you want to hide it from critial review.

    Just a little rant to go with your morning coffee

    John Murray
    Sobetech
  26. These are some of the "Best Practices" that I want to see in software development:1) Show up for work and meetings on time!2) Comment your damn code.3) Hey business analyst, how about some freaking requirements!4) There is no reason why a meeting should last over 1 hour.5) Stop being lazy with variable names. A couple extra key strokes makes your code readable. If you don't make readable code, that means you want to hide it from critial review.Just a little rant to go with your morning coffeeJohn MurraySobetech

    Exactly! :)
    This whole discussion reminds me of the Dijkstra's article I read back in graduate school... The great computer scientist - who apparently was growing old and grumpy - was ranting about the term "bug" being so widely used in the CS community. Dijkstra was upset that the term implied that something had crawled into the code while the programmer wasn't watching, and therefore the responsibility for the mistake was moved from the programmer to something else. While it was amusing to read, and I got a chuckle out of it, I though it was a waste of article space... Who cares how you call it??? The same thing here... Look how many people have dropped whatever they were doing and got involved in this nonsence discussion - including myself! :) Here's the bottom line (IMO):

    1. Of course, any "practice" is only good or best within the given context - Until something better is discovered. OF COURSE!

    2. Of course there are people - and there will always be - who misuse practices, take them out of context, and then try to use them to defend their incompetence. Of course! Is this such a revelation to anyone? If we could only eliminate incompetence by changing the terminology, James... Hello-ooo! Snap out of it!

    Now... get back to work, people, write some code. Oh, and make sure you put some readable comments in it, you lazy bastards! ;)
  27. The best practices are always bound to a cultural context, that is a (partially) common history that lets people share an understanding about the value of "best practice", from their point of view.

    Just as an example in countries of highly specialized engineers ("the left-wing screws specialists" as said a friend of mine) the vision of what makes sense about a problem's may be very different from the vision of people from countries where engineers who have to code-design-and-lead a project.
    Although the technology is the same, their history using the technology is very different, and what is value for the former group is not of value for the latter, and vice-versa.

    Thus the best practices question is an ill-formed question.

    In order to be able to get value out of "best practices" we need to understand what makes its value for some people, why it does and when it does.

    The value is not in the practice itself but in sharing an understanding about the criteria that led that practice to be of value for a group of persons.

    Creating an understanding is very different from discovering the truth (the "best practice"). It is about creating consensus and about tolerating that other visions (experiences) may exist.
  28. "Show up on time" means what. Have you become one of those project managers who spend more time on MS Outlook and less on software development. Do you realize that it takes hell lot of time to deliver. There are people who spend late nights trying to make things work, and spend almost 12-16 hours at work everyday, because of unrealistic deadlines set by managers like you. You might find my comments rude, but you remind me of an ex-manager of mine, who was a stickler for "you should be in before 8:30 am". And he would make people stay till late. He would frequently be found playing Solitaire or Freecell in his cabin (sometimes he would be late in minimizing the window ).
    I left that job after 4 months, but not before giving him an idea about his stupidity.
  29. I started of my career as a programmer for BAAN ERP. In 1997 it was second to SAP just incase people wonder what is BAAN today.
    The entire ERP industry was based on the "Best Practices" approach. In those times they would actually recommend to companies how to do their SALES systems, Finance systems , Manufacturing Systems in the name of "Best Practices" . No one ever said which sample companies were chosen to come up with thos best practices anyways.
    In anycase I saw a lot of projects fail simply because companies couldnt use the "best practices" recommended in the software for any number of historical or cultural reasons and tried their best to customize BAAN to suit their needs.
    Today we have started doing the same thing at a different level. Sometime we suggest best practices at Technology level, other time we suggest best practices at Business Process level.
    I suppose that term "BEst Practices" was coined by the accounting world and only makes sense of the accounting world.

    AT the very least is it too much to expect that the person coining the term "Best Practices" in his/her recommendations atleast have the obligation to tell us why it is a best practice and what real life implementation make it the best practice.
    Otherwise that phrase is merely something someone the "Architect" and the "Architect" was either overlyimpressed with that person or found it a convinient and lazy way to gain importance.
  30. Misleading Connotation ?[ Go to top ]

    How about if you refer to them as recommendations?

    Software Patterns are recommendations for a proven (usable) design or analysis model, and hence by definition in a given context.

    Development Processes (RUP, XP, et all) are process models that've worked and can be replicated, and its always specified that they need to be adapted to the team profile etc. - again within a context.

    To state that "best practices" don't mean anything outside of a context is overstating the obvious. Even though the term itself is probably a tad supercilious.

    A final thought - yes for the lesser mortals its *safer* to stick to the seasonal trends. Its easier to refer to an "authoritative source" or a precedent than to go out on a limb and be outright radical. And neither is good or bad, its just a choice - as long as its a conscious one, I guess one is OK.
  31. I feel that[ Go to top ]

    reading this was a waste of my time.
  32. yep[ Go to top ]

    yep - a surprising rant

    best practices exist throughout any industry, art or hobby

    As happens with many buzz words that get slung around our particular industry - it seems that "Best Practices" has a lost a lot of value for being used too often.

    my 2 cents
  33. Whilst strongly worded, I believe this article is correct in marking "best practises" as dangerous and I agree that the key problem is the lack of context.

    Take the example given earlier in this discussion of "'automating your builds' is a Best Practice".

    Well, if you intend to keep the code and maintain it, then I agree that automating your builds is useful.

    However, if you have written a few classes to test an idea and are going to delete it in a day then automating your build is probably a waste of time.

    Now, most developers will have enough experience of development to understand that this "best practice" shouldn't always be followed. However, I've seen cases where managers have mandated a list of "best practices" to follow, or where the developer doesn't have enough experience to understand when a particular "best practice" applies or doesn't.

    Adam
  34. Topdown programming is the only real best practice.
  35. Here is a decent definition of Best Practices that I came up with:

    "Best Practices for a given scenario are tried and tested practices for that scenario, which, when applied, increase the chance of success".

    Best Practices promote repeatability in an otherwise clueless and risky world of IT where failure is not an option.

    I think this is a good definition of Best Practices.
    Think of how many tasks do we do again and again day in and day out. A lot of developers out there have done it - some more intelligent than us and some not. It is the collective intelligence gained from experience that we can adopt as best practice.

    These days there is a disturbing trend in the software industry of classifying developer common sense as either "Design Pattern" or "Best Practices", to capitalize the popularity of these terminology.

    Somebody on this thread said
    Well, if you intend to keep the code and maintain it, then I agree that automating your builds is useful.
    However, if you have written a few classes to test an idea and are going to delete it in a day then automating your build is probably a waste of time.

    I call that developer common sense. Any sane developer will not do that (unless they are learning to automate build) because somebody said it is a best practice. We need to always thing before jumping on the best practice or design pattern bandwagon. We have been endowed with brains to develop decent software in reasonable timeframe and in the process, if tried and tested practices help us, hey why should I fear (refrain) from calling them best practices just because somebody else abused the term.

    Somebody out here also suggested replacing the term "Best Practices" with recommendations. Going by similar logic, using the term Patterns is also wrong. Because they are just that, somebody somewhere found that there was a better way of doing things and named it. Just because the term is exploited beyond recognition does not mean "best practices" dont exist.

    It is not the best practices that are dangerous. it is the developers failing to apply their brain and common sense while doing things what they are paid for is bring bad reputation to the term best practices.

    Cheers,
    Srikanth
  36. There is another semantic problem with the use of the phrase "Best Practices" . It implies "BEST" , not "BETTER" or "GOOD" or "RECOMMEDED" but "BEST".

    Top management tends to get impressed with such words. I think it is mostly because they think they no longer have to spend effort trying to understand it or justify it to their managers. Our IT Industry is full of middle managers who somehow feel having technical competence makes them bad managers and such jargons are created specifically to play with their insecurities. It takes a certain measure of competence and confidence in ones technical ability to challenge notions as big as "BEST PRACTICES"

    Technical People using such terms often dont know why its called "BEST" either but its a nice cheap road to fame. Usually they aspire for managerial positions or glamour.
     
    Its almost like saying if this is an "INDUSTRY BEST PRACTICE" who are you to challenge it? Or are you so big or stupid to challenge "INDUSTRY BEST PRACTICES" ? Never mind no one know who came up with it and why on earth its the "BEST PRACTICE"
  37. All this discussion sounds like an English-learning class, that's all.

    If I receive some "best" practice from someone, I consider the practice strongly, but I will by default think twice before its application. Thus, the word "best" implies stronger consideration, and nothing more.

    As far as I know, that's how the 'English' language operates. Why don't you blame it on the United Kingdom where the language originates?

    Bottomline: For English speakers, "BEST" practices exist.
  38. Since English is the medium of communication here and english language has a meaning for the word "BEST" I suppose its appropriate that we consider that meaning when using that word in the IT context.

    The problem does not lie in developers such as us as we have our code to defend. This very factor makes us careful and vary of falling for such gimmicks.

    The problem is with constant battering of advertisements with such words being thrown in constantly. I will give you an example. Somewhere someone sold to our top management that "RUP" was industry best practice. Suddenly all projects have to use "RUP". An inordinate amount of time was spent in trying to fit "RUP" to projects being developed using a non-object oriented technology and batch processes. Effort was made to prove the USE Cases apply to batch processes. Even batch process calling another batch process is like a "COSUMER" and hence user of the later batch process. I ask "WHY?" . Didnt projects run before RUP. RUP should be a means to an end not an end itself.
    tomorrow someone will sell to the Top Management that SOA will solve all problems as its an industry best practice or WORKFLOW Engines are a panacea to all problems and suddenly some body start communicating only with WebServices. If that makes you laugh think about EJBs in 2000.
  39. I think it all depends on what the definition of "is" is...

    regards,
    Bill Clinton.
    :)
  40. YES to Best Practices[ Go to top ]

    I think James has a fair point that blindly following Best Practices is a poor subsitute for learning how to do your job. However, I disagree with him that best practices don't have a place in our workplace.

    I define a "Best Practice" as "A practice which we agree to follow, unless a rational, coherent, well defined, peer-reviewed argument is made for breaking it." Best Practices aren't the "Sacred Cow" that James makes them out to be. They're a "Common Starting Point" which a team agrees on, recognizing that it applies to 80% of the common cases and is therefore harder to go wrong following the "Best Practice" than deviating from it. Yes, you SHOULD deviate when the situation calls for it. It just means you should be giving it some real, honest thought and consideration when you do.
  41. YES to Best Practices[ Go to top ]

    I think James has a fair point that blindly following Best Practices is a poor subsitute for learning how to do your job.

    D'oh! And how exactly is this a revelation that inspires a person to write an article and publish it as if everyone should suddenly get enlightened after having read it??? I am considering writing a manifesto... something like "Writing Bad Code Is Not Always Good." And then let's all discuss it for a few days! How about that? ;)
  42. ...that is like saying there are no best practices is architecting buildings because every building is different, sits on a different piece of land, is subject to different building codes, will be used for different purposes, and on and on the list goes.

    the desire to reinvent the wheel is a psychological disorder along the lines of graniose self infatuation.

    those that do the best in any field are those that can learn from others, both present and past -- including from other fields -- and apply it to their own work. those that are superior are the above plus they have the ability to refine and improve upon the works of others.
  43. ...[ Go to top ]

    ...and one thing i have not managed to learn from others is spelling.
  44. Good or bad practices in the many years I have been
    doing consulting the one important thing I have learned is:

    Good process leads to good software!

    So, if having a good process is a good
    practice, it is the only one to use and
    all else will follow.
  45. From TFA:
    The way to get rich in this world is mainly by making people feel large hope about a small exertion (i.e. [...] voting in an election [...]).

    While I agree with much of what the author wrote, I'm having a bit of a hard time figuring out how convincing people to vote in an election would make me rich. Any suggestions?

    -Patrick

    --
    Patrick Linskey
    http://solarmetric.com
  46. While I agree with much of what the author wrote, I'm having a bit of a hard time figuring out how convincing people to vote in an election would make me rich. Any suggestions?

    Own your own oil company? ;-)

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  47. in industry to abstract useful development patterns from complex problem domains.

    Maybe the author doesn't get how to apply best practices...then again, maybe he's just got something stuck in his craw, leftover from a bad manager/managed experience.

    Maybe his manager wasn't following best practices for software development management.
  48. If what you claim is true, that people tend to call things "Best Practices" without considering a problem context:

    Is there really a need for the plural form?

    Something called "THE Best Practice" should be sufficient for solving any problem -- at least if people in common are as ignorant as you imply.
  49. actuallt, best practice is misured against some technologies and some givins that enables you to successfully pass Tasks/Tests Check Lists successfully for such a practice to get the solution.

    But if the technologies and/or the givins changed, this Best Practice must be revised to apply the new changes to get the same Best Practice.

    The Practice is concidered the Best when passing Tasks/Tests Check Lists successfully using some Technologies with some givins.
  50. Best Practices, is shorthand for "I'm not sure what to do, so I'm going to follow some one else example" Visionaries to not follow they lead. Nothing new will be learned by following the "Best Practice". If you can identify what works and what doesn't you have created our own best practices.