Is CriticalSpirit something to be desired in SoftwareDevelopment? There are several levels where critical spirit might help in software development: * at a personal level. One should have a critical spirit towards his own code, towards his own values (preferred languages, technologies, and so on) and towards himself as a person. * at a project level. The generalization from one person to the entire team. * at a industry level. We are being sold crappy technologies. Many individuals have a problem with this, but nor the industry neither the software development community (or communities of interest) seem to favor a critical spirit approach towards this de facto state of affairs. I thought it was self understood that CriticalSpirit is beneficial at all these levels, but apparently the jury is out on this one, so I'm eagerly waiting for other's arguments. -- CostinCozianu ----- From WhereCriticizeBluntlyWorks Here's the original raw discussion (not all might be relevant to this page), that went from criticize bluntly as a possible manifestation of critical spirit to questioning whether critical spirit at all is good in SoftwareDevelopment: You can add SoftwareDevelopment on the list of unforgiving domains. It is very unforgiving to make mistakes, with all the XP and refactoring , mistakes in SoftwareDevelopment cost a lot, sometimes the whole project. And UNLIKE in maths and in chess, there's tons of bad advice floating around in every imaginable shape and form (magazines, vendor marketing, vendor documentation, published books, online forums, blue prints, sample applications, you name what here). And also UNLIKE in maths and in chess (and other domains) CriticalSpirit is not quite encouraged. I wouldn't think it is good to place too much emphasis on the security of the person being criticized, (''let the other save face'' kind of thing), a much more important thing to consider is the disastrous effects his bad advice might have on others. This is a lot more important than anyone's ego. -- CostinCozianu I disagree. There are a lot of cost-benefit trade-offs in SoftwareDevelopment that make distinctions about the right and wrong thing difficult. Microsoft and others are notorious for delivering imperfect code on time because of considerations irrelevant to programming. ''With what exactly do you disagree ? Is critical spirit encouraged by the industry, is critical spirit not needed in the industry, is anyone person's ego more important than the disastrous effects his bad advice (sometime advice means books/standards/product docs/official recommendation or guidelines) might have on others, or is it just that CriticizeBluntly is not recommended in discussing SoftwareDevelopment issues ? '' ''CriticizeBluntly is not necessarily about right and wrong, on the other hand there are things that are clearly on the wrong side.'' '''How about this: If you can show me the economic advantage that "encouraging CriticalSpirit" gives one company over another, I'll agree that we should do it.''' [editor's style change] Specifically, in SoftwareDevelopment, you might come across this situation: Programmer P is working on fixing feature F. Manager M has to meet deadline D. M says to P, "I know you're working on fixing F, but the bug isn't big enough to hold back the release." P, knowing the 'right' way to program says, "It would be a mistake to deliver without fixing F." M, knowing the 'right' way to deliver software says, "No, you're wrong." P replies, "No, '''you're''' wrong." What's the economic advantage of having this argument? Who's right? Who's wrong? Does it matter? Perhaps they deliver the broken software, and somebody dies (in a fluke accident). Was the manager wrong? Suppose it's the exact same software and nobody dies. Was the programmer wrong? It's impossible to be certain one way or the other. Criticizing bluntly in this case will only spark a useless argument. In the end, someone has to make a final decision that may be 'wrong' or 'right'. ''The futility of the imagined argument above doesn't come from its bluntness; it comes from the lack of useful information being offered. Blunt means direct, not rude or irrelevant.'' There is a '''fundamental''' lack of information inherent in SoftwareDevelopment. The problem is not that it's blunt, but that it assumes there is an easy answer to 'right or wrong'. Otherwise, how can you be blunt? * '''X''': "Blah, blah, blah..." * '''Y''': "You're wrong, and here's why: This, that, the other." This is CriticizeBluntly. It is not usually possible in SoftwareDevelopment, because both sides have different values and understandings. The appropriate CriticalStyle in such a circumstance should be to explore the underlying values and assumptions, not ''impose'' one person's values on the other. CriticizeBluntly might work if the domain is well-defined, such as in chess or math, but not in something ill-defined like SoftwareDevelopment. As soon as RealLife and BusinessValue butts its nose in, CriticizeBluntly becomes merely argumentative. ''Now can ALL the aspects of SoftwareDevelopment be covered under shades of gray ? Are there not certain things that are clearly good or clearly bad? -- CostinCozianu'' Sure, but your original claim applied to all of software development: "You can add SoftwareDevelopment on the list of unforgiving domains." You could make a less universal claim. It would be a lot easier to make a case for a more restricted domain. Here are some ideas of where CriticizeBluntly may apply to SoftwareDevelopment at the levels you mention at the top of the page: Personal level. Write UnitTest''''''s and make sure all the UnitTest''''''s pass before you integrate. If everyone does this, you'll always have a working system. If you integrate and the tests fail, it must have been something you did or failed to do. It is your responsibility to fix it. Be critical of your own code. Don't go trying to blame someone else. Project level. As a team, do not accept a person's word that a StoryCard is complete. It's not complete unless it passes the AcceptanceTest''''''s. If it doesn't pass, that person does not get credit for completing the StoryCard, and that person's velocity on the next iteration is lower. Don't accept the "It's 90% done," excuse. Industry level. Industry publications should evaluate software products impartially, thoroughly, and strictly. None of this bandwagoneering we see going on so often. ''Ok, I admit I was rather inexact. Let's try these: '' * SoftwareDevelopment is a rather '''unforgiving''' domain (can we take this for granted? at least some books on software engineering tell us that the rate of failed projects is rather alarming) * we need to make sure that CriticalSpirit feels at home in any software development endeavour * not in all situations CriticizeBluntly is the best expression of critical spirit in a software development activity ''Maybe the next step is to distinguish where exactly we do have shades of gray and where should we strive for true/false, right/wrong approach. -- CostinCozianu'' This page has a great quote: ''[CriticizeBluntly] is not usually possible in SoftwareDevelopment, because both sides have different values and understandings.'' There's a lot of wisdom in this statement. For every person who says that an agile approach is correct, another will say that a big process approach is correct. I think comments are overused; someone else thinks comments are underused. I argue for lots of short, simple methods; my co-worker argues for a few long, standalone methods. I can only think of a few inarguable facts in software development: the code either compiles, or not, and it either passes tests, or not. Everything else is arguable. Including whether or not to have tests, and whether or not to even compile everything. So my answer: Striving for a true/false, right/wrong approach on any issue more complex than "did it compile" or "did you get a GreenBar" is a bad idea. It will provoke religious arguments, engender bad feelings, and generally waste time. Instead, look for simpler answers. Better for this project, or worse for this project? Every project is different, so try things and see what works. Come to consensus. Don't fight. -- JimLittle * ''SoftwareDevelopment is a rather '''unforgiving''' domain (can we take this for granted? at least some books on software engineering tell us that the rate of failed projects is rather alarming)'' And yet those companies whose projects often fail are still around, and some of them are doing very well. So no, I don't think SoftwareDevelopment is unforgiving; it seems to me to be a very '''forgiving''' industry. The big successes can counteract lots of small failures. In math, for example, if you have one error in your proof, it's unlikely you'll still arrive at the right answer. ---- ''I thought it was self understood that CriticalSpirit is beneficial at all these levels, but apparently the jury is out on this one, so I'm eagerly waiting for other's arguments.'' Anyone care to provide an example of where a CriticalSpirit was beneficial? -- AnonymousDonor It all depends on how you define CriticalSpirit. I have two definitions, and two stories. My first definition: ''"A person who looks for problems and points them out to others."'' Long ago, I was hired to work on a team. I sold myself as an OOP mentor and Java programmer. (Okay, so it wasn't ''that'' long ago. I've come a long way since then.) Nobody else on the team had prior OO experience or Java experience. In the interview, I caught several AlarmBellPhrase''''''s, including, "How do you feel about working overtime?" So I came in expecting problems. Sure enough, I found them. Design documents were out of date, the code hadn't ever been integrated, morale was low, tensions were high, people were leaving. I dutifully dived in with my AntiPatternsBook, looked at the design, made lots of little critical notes. I ignored the signals that no one else thought of me as a mentor. Six months later, the project was dead and I was universally reviled. Word about me spread around, and I had a lucrative job offer retracted due to the rumors. I was lucky to find another job. All because I had come in with the OneTrueWay and a high and mighty attitude. None of my criticisms worked, the project failed, and I made a lot of enemies. Second definition. ''"A desire, on the part of a person or a group, to see and correct personal problems."'' Not so long ago, I was hired to work on a team. I had proven myself as a capable project lead and Java programmer. Nobody else on the team had prior OO experience or Java experience. The project manager was seeing high-level problems, and I was specifically hired to solve those problems. The team was pretty sceptical of my suggestions. I explained the reasons I saw for the team's problems: process problems, not personal problems. They agreed enthusiastically. I offered some XP-based solutions, and they balked. "These individual practices have worked for me before," I said, "but I've never tried them all together. But people I respect and trust have had a lot of success." The team agreed to try it out for a little while. We would have regular PostPartum reviews and tweak the process as we went along. Eight months later, the project was a huge success and I was off on a lucrative follow-up contract. We tried a huge number of ideas. Some of them worked, some didn't. The team was always willing to at least consider an idea - even the really stupid ones - and although they would argue passionately, they were always willing to listen to other points of view. In the worse case, they'd be willing to at least try it for a little while, and they were honest in their evaluation. Many practices that were originally resisted ended up being adopted. Without the CriticalSpirit present in that team, the project never would have succeeded. If I had ''been'' a CriticalSpirit, as first defined, it surely would have failed. -- JimLittle Jim, your first definition was not good anyway because CriticalSpirit is not a subtype of Person, it never will be. A person might have it or might whine about it. Those who whine about critical spirit are the amateurs. In the first project you exemplified you were involved with a bunch of whinies and amateurs. Nothing and nobody could have helped them, unless they accepted critical spirit in the first place. The second definition is much better, however the example is about the social engineering of CriticalSpirit. That's a whole new game. -- CostinCozianu ''Where is being critical applied in the second example? It appears to be about avoiding being critical.'' ------ I just bought the book TheOneMinuteManager (cheap and only 100 pages), and thought the contributors on this page might be interested in it. It talks about OneMinutePraisings and OneMinuteReprimands. I think this is related to CriticalSpirit, but I don't think it's exactly like Costin's original definition of it. ----- How about these: * No progress in knowledge has ever been done in the absence of CriticalSpirit. In the absence of CriticalSpirit you can only have the illusion of progress. * We should all strive for performance at our individual level and at the team level. We shouldn' strive that much for accommodating mistakes, but put the good accent on avoiding mistakes (I very much praise the author of WhyDoPeopleMakeSoManyMistakes for criticizing ExtremeProgramming in this regard). * Cultivating CriticalSpirit is the ONLY way that you are going to minimize the number of mistakes, especially if you cultivate it as a team. * CriticalSpirit is crucially important at a "industry" level, if we ever want to take pride in software development as craftmanship. Otherwise we can all tell we are sold a lot of crap (they call it technologies), we put more crap into it, and sell it to the end user. That's not craftmanship. * Leaving egos aside is a '''sine qua non''' condition for any performance endeavour. You can easily see that in any team sports . See Lakers this year (2001) for the most recent example. * If you want to accommodate egos you can pretend to do anything BUT performance. A bunch of whinies will never make a team. * The only style that really cultivates CriticalSpirit is CriticizeBluntly. If this style hurts some egos in the process, those egos were not going to help the team anyway. -- CostinCozianu ''Can you provide any justification to these assertions? Isn't being critical the rejection of ideas? How could this possibly lead to increased knowledge or improvement?'' Being critical IS NOT the rejection of ideas, critical spirit is the rejection of bad ideas and an essential part for the validation of good ones. Outside CriticalSpirit you have no ideas at all. ''Who is doing the rejection and whose ideas are being rejected? How is the "goodness" and "badness" of ideas determined?'' The question is way too general. It depends. In science the scientific (academic) community is responsible for rejecting bad ideas and promoting good ones. The process is very fuzzy and mistakes can happen (the ideas of EvaristeGalois were first rejected , to be accepted 30 years later), however the process '''cannot happen at all''' in the absence of critical spirit. What are the criteria ? Well, the criteria vary from one domain to another, but you'll always have some. ''How are these criteria known? Who is responsible for applying the criteria? How does this lead to an increase in knowledge? How does any of this justify your assertions concerning being critical? Would it help the generality of my questions if we limited them to the area of software development?''