Critical Spirit In Software Development

Is CriticalSpirit something to be desired in SoftwareDevelopment?

There are several levels where critical spirit might help in software development:

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?

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 UnitTests and make sure all the UnitTests 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 AcceptanceTests. 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:

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

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 AlarmBellPhrases, 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:

-- 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?

EditText of this page (last edited February 18, 2006) or FindPage with title or text search