Psychology for Engineers - understanding your people

[Big Bird]

Greetings all,
I’ve got another essay bubbling away inside my head. I think it is sufficiently different from the “Reasoning…” argument to warrant its own thread, but if you think it should be buried there please let me know.

I’ve been thinking of team politics and harmony, and how they are much better indicators of team success than vehicle specification. I would like to attempt to define some of these factors, rather than just tell you it is “all about people” and then give you nothing concrete to work with. I am not a trained psychologist – but then again I’ve seen qualified engineers who cannot engineer, and unqualified one who can…

I’ve also been thinking of the applications of design process in the real world, given that I see a lot of the lessons we learn as engineering designers (and in particular, FSAE designers), are not learnt by people who are often looked up to as role models and mentors, and who should be smart enough to know better.

I’m going to pick two easy targets for us in the below – politicians and academics.

Some will say that the below is lost on undergrad engineers. I say that even if it is, it might be useful further down the track. I didn’t stop learning from the FSAE experience the day I graduated.

What I like about engineering is that it is practical. At the end of the day, we have to apply what we know and deliver something concrete in the real world. Often, that is an artifact, sometimes it is a process or a procedure. But our success is measured by the results that we deliver – not the arguments that we have, or the ideas that we generate, or anything we say, or anything that is polished up and presented by marketing departments and PR agents. Our challenge is to deliver.

The engineering design process can be described in many ways, and different descriptions may suit different purposes depending on what we wish to understand. The first post in my “Reasoning…” thread contains a methodology and breakdown of the vehicle design process. In the following, I am going to attempt to broaden that out to a general problem solving process – and offer some ill-informed prattle about some psychological aspects of our thinking processes.

For the sake of this argument, I will assume that the problem being confronted is known and understood, and we are about to embark on our problem solving process. I will use the FSAE problem as a starting point, but then draw in some observations from the outside world.


THE THREE PSYCHOLOGICAL STATES OF THE DESIGN PROCESS
I will break the problem solving process into three phases.
1. Generation of solutions
2. Analysis of the solutions
3. Delivery of the solutions

I am being quite broad here, but that is because, psychologically, I see three distinct mind skills that quite neatly fit into the above three phases.

The first phase, generation of solutions is a creative phase. It is all about ideation, opening your mind to new ideas, being adventurous. It is about suspending criticism and disbelief, and being positive. I think humour fits in really nicely here, as humour is effectively about taking something familiar and then providing a surprising answer or twist. For example, I am presently organizing a few charity benefits with some friends, and attempting to be a funny bugger I have twisted the term “friends with benefits” around to come up with the name “Benefits with Friends”. Ho ho hee hee I’m so hilarious – not - but I can never remember jokes and wanted to save you all the collective facepalm if I had have rolled out the standard “what is brown and sticky – a stick!” joke.

Anyway, the point I am making is that this first phase is all about twisting and distorting and looking at problems from different perspectives. Phase one is the fun phase, I reckon.

Phase two involves analysis and criticism of the ideas generated, and requires a different psychological skillset. This phase is all about fault finding, identifying potential failure points, finding limits, criticizing. If phase one is open and adventurous and generative, phase two is confining, critical, and effectively “closes out” the ideas that are not suitable. It is analytical, serious, and is quite “negative” in character. The effect of this phase is to prune down all the ideas to the one solution you are going to build.

Phase three is effectively collaborative. It is about taking the one design you have decided upon and delivering it. It is about putting behind you the arguments and disputes you had during phase two and moving forward together. This is real engineering, this is teamwork and delivering a product and this is what sets us apart from scientists.

So, effectively the process works like this:
1. We go through a creative process to generate ideas
2. We go through a critical process to eliminate options and select one for delivery
3. We go through a collaborative process to deliver on our final product

From a Formula SAE perspective, we could define the transition from phase one to two as the Conceptual Design Freeze, and the transition between phases two and three as the Final Design Freeze. We come up with ideas, we select the best one, we work together to build and deliver on the final product.

If you look at the above a little more broadly, it is not only relevant to FSAE design, or engineering design, but is a rather decent representation of any problem solving process.


SOCIETY STEPS IN…
OK, so now it is time to start shouting from the rooftops about how society is stuffing everything up for us, and how it is not our fault…

The dominant thinking pattern and the one that seems to get the most attention in our society is the critical phase two pattern. We celebrate our critical thinkers to such an extent that many people in our society make a damn good living without ever venturing out of phase two.

Our academic institutions are pretty firmly entrenched in a phase two mindset. In our engineering education, I would say 90% of our material is about analysis, which is effectively about criticism of a certain design. That criticism may simply be in terms of calculating a force or a velocity, but it is generally about assessment of an existing product or system and whether or not it is fit for purpose. Other faculties are typically the same. The teacher gives some information, the student has to perform some exercises to have their understanding assessed, and the teacher then looks over the work to “correct” it and assess where the student has gone wrong.

Our political system, our legal system, and our media are pretty much the same. Adversarial, critical, confining, negative.

Don’t get me wrong, I am not saying that this is a bad skill to have. I am saying though, that it is but one mental skill in a suite of them, and that if practiced solely is ultimately destructive.

Curiously, the only time I really hear celebration and appraisal of the full three phases of problem solving is in team sport, and in war. When I listen to football commentary, I hear the commentators speak of strategies to create opportunities, and shutting the opposition down, and building team spirit, etc etc. We look at our sportsmen quite often as dumb jocks – but in fact they regularly demonstrate a kind of mental agility that spans all three mental skills mentioned above.


MISTAKES WE MAKE
The critical phase nestles neatly between the creative phase and the collaborative phase. So what happens when the critical state creeps in either direction.

Critical mapped over creative: this usually manifests itself in the shooting down of ideas before they have been investigated. The “that is a stupid idea” mentality that kills a lot of creative thought. Note that one of the first rules of brainstorming is to suspend judgement – the intention being to free the mind and expand the set of potential solutions. I have seen very few minds here that are brave enough to be fully creative and exploratory. I would nominate Z and Rob Woods as belonging to this group, and note the chorus of criticism they have attracted over the years. Phase two thinkers can’t wait for a phase one to arrive so they can ply their trade and shoot them down in flames. How often does a Z or a Rob Woods get a “hey, that is an interesting idea – let’s explore it further.”

Critical creeping into collaborative: this usually manifests itself as the divisive “I would have done better” character – the one who can’t accept a team decision and move on. The “things aren’t perfect yet so I’m going to tell everybody I can” character who, often subversively, undermines the harmony of the team by encouraging little cliques of dissent. I have seen an extraordinarily prominence of this kind of behavior in FSAE teams. The teams that control this are the winners.

I would say that a number of teams approach this project with a completely phase two approach, and it shows….

I’ll write more in the near future, but for now it is time for bed. Hopefully I’ve got at least a bit of the message across in the meantime.

[mecwill]

I love your brain man.
The way of thinking its important in every stuff were involved.
I think its a known 'guidance' but people should hear or think of that more often; just like a clock alarm wakes you in the morning.
But that depends on the education system and the 'journey' your in in life.
If you find yourself thinking that the psychology its a good think for you, you start seeing things differently.

[Big Bird]

As I mentioned above, engineering is a vocation of practical fault finding and problem solving.

A purely fault-finding approach is confining and focus-narrowing. You will always find a way that a new system or idea is inferior to an existing system.

How many of us have shot down a new idea because we didn’t like it, or saw fault? I’d say probably all of us.

How many of us have looked at a new idea that we didn’t like, or saw fault in, and then actively looked for the good in it. Probably not many of us. Once we are engaged in fault finding, and are being adversarial, we are often too emotionally invested in the argument to accept any good. And given the engineer’s job is to objectively weigh up the good and the bad, this is a dangerous mindset to get in.

This is the major problem in dealing with engineers. They don’t know when to let go of the scalpel. They are so focused on fault-finding, and cutting out the “wrong”, that they leave themselves nowhere to go. If we go left, there is this bit of wrong. If we go right, there is wrong over there too. We’d better not go left or right, and we can’t go backwards because that is just really dumb. So lets keep marching in the same direction we always have, into this brick wall directly in front of us…

CASE STUDY IN ADVERSARIALISM AND DISPUTE – TUG OF WAR
Forgive me, I have marched this one out a few times, so apologies to anyone who has heard it before. School sports, two teams of students playing tug-of-war. They are given a rope with a flag on it, two lines marked on the ground. On the word “go”, the two teams pull directly against each other, with the objective being to move the flag over the line closest to you. After quite a bit of tugging and straining, one team outmuscles the opposition, the flag crosses the line, and a winning team declared. Result – two exhausted teams, one team satisfied, one team aggrieved, one rope moved maybe five metres to the right.

Maybe there will be additional heats, maybe different teams, but the same game plays out. At the end of the day, everyone reflects on their own results - winners are inspired to train harder so that they can oppose their opposition even better in future, losers get grumpy and vow and declare that they will train harder so that they can oppose their opposition even better in future. Everyone eats a lot to replace their spent energy. The sports staff pick up the rope and takes it back to the sports shed.

Now from an engineer’s point of view, we should look at this situation functionally and objectively.

Functional objective: - move rope
Case Study #1: Tug of War (adversarial model)
Method: Move rope by pulling both ends at once. Two teams of highly trained individuals diametrically opposed, working against each other.
Functional outcome – rope moved 5 metres
Cost: two teams of possibly highly trained individuals now exhausted, much energy spent, individuals fixated on working even harder on working against their opposition in future

Case Study #2: Sports staff pack-up (collaborative model)
Method: Fred the 63yo janitor picks up the rope and takes it back to the shed. Everyone understands that it would be silly to work against him, by for instance standing in front of him, pulling him backwards, tripping him up, or waiting until he puts the rope away and then putting it back onto the sports ground so he has to do it all again.
Functional outcome – rope moved 100+ metres
Cost: Fred’s wages for three minutes, and a little bit of his energy. Fred forgets about it as soon as it is done, and he is soon back home where he can focus his time on his model train hobby.

Put in those terms, we can see the ridiculous inefficiency in opposition and dispute when it is employed as a means of progress.

We wouldn’t dream of hindering Fred’s efforts to pack up the sports ground because we all agree that is a worthy objective. We all agree that the rope should be back in the sports shed, we agree that we want the sports ground to look nice, we all agree that putting obstacles in Fred’s way will only lengthen the packing up time and ultimately cost us money.

Yet somehow, when it comes to politics, for example, we are happy to support a system which is founded completely in adversarialism. In Australia, we have the Liberals and the Labour Party opposing each other on every issue. Members for each team are carefully trained and picked so that they play the game correctly, and oppose their opposition at every step. No-one is allowed to agree with anything the opposite team says, no matter how beneficial the outcome may be to the outside world. Thus we set up an immensely inefficient and unwieldy system that spends an enormous amount of our money and time arguing with itself in the name of progress. Slow, expensive, unwieldy – painful.

I also remember with some amusement the story of some famous gridiron player, built like a fridge, who retired after maybe 10-15 years of playing having only touched the ball three times. His job was to stand there like a fridge, directly opposite another bloke who looked like a fridge, and upon the blowing of a whistle he would engage in this game of grappling fridges where each fridge would try to stop the other fridge from stopping him, so that neither of them would get in the way of the game of football that was going on around them. We celebrate this kind of thing. We hand over lots of money for it.

Now I am probably being overly simplistic about all this. In the case of federal politics there is a bit more complexity than a simple tug of war, as there is a definite need to identify potential flaws and failure points in the topic being debated. Thus dispute (fault-finding) is a necessary part of the process. This correlates with our experience of Formula SAE too.

BRINGING IT BACK TO FSAE
So what are the objectives in Formula SAE:
1. Understand the problem (best done collaboratively)
2. Propose potential solutions (creative, expansive)
3. Analyze solutions to pick out the best one (critical,fault-finding)
4. Manufacture our solution (collaborative)
5. Refine our solution (collaborative)
6. Present our solution to the various judges, informing them of what we have learnt along the way, (collaborative)
In each of the above, we could potentially argue that each of the three mind states can be useful - however I have chosen to present the most prominent state.

Accepting that we need critical thinking / fault finding to be part of our process (but not all of it), how do we engage in the fault finding process (dispute) without it being a tug of war? How can we do it with the least usage of time, energy and resources?
1. Be honest with each other – don’t sugar coat stuff, and don’t put spin on your argument to favour your own favoured solution. If an engineer proposes a certain design solution and refuses to see any fault in it – sack them. If an engineer looks at someone else’s design solution and refuses to see any good in it – sack them. If the whole team knows they can trust each other to offer unbiased, honest information to melting pot – then the layer of complexity and wasted time attributed to breaking through sales spin is averted
2. Be critical – yep, point out what you see as wrong. And if someone finds fault in your critique – listen to that too and see if it makes sense. Ask yourself what you can learn from their perspective on this – rather than get all defensive and feel the need to prove them wrong.
3. Be encouraging – point out the good as well as the not-so-good
4. Be dispassionate about the product – we are building a self-propelled protective chair. Don’t be precious
5. Be mathematical – use numbers wherever possible to decide an argument for you. Don’t under any circumstances fudge the numbers, otherwise point #1 above flies out the window
6. Be thorough – make sure your mathematical analysis is comprehensive but appropriate
7. Be realistic – don’t expect you will solve all the FSAE problems in one year. Know when to say enough
8. Be humble – don’t get all precious if you don’t get the answer you like. You are an engineer. You don’t like. You do.
9. Be team focused – the team helps you to achieve things to a much grander scale than what you can achieve on your own. You would not have this opportunity without your team. Live for the team. Not yourself.
10. Be results focused – Your tasks as a team are to gather competition points, encourage new students to come to your uni, promote your university’s name, secure resources for your project and future projects. Know your objectives, and measure your success in terms of them. Don’t get bogged in petty arguments and don’t shift the goalposts as you go along. Set a deliverable plan, deliver on it.
11. Move on – when the design is frozen, and the disputing stage is done – stop your whinging and move on. Sure, keep an eye out for unforeseen faults, but do everything you can to be collaborative to deliver on that final product.

[Big Bird]

OK, a bit more about the phase two team. That is, the team that approaches FSAE purely from a fault finding viewpoint.

Firstly at the lowest level of engagement there is the team that looks at the winners, finds the differences between the winning car / team and their own car / team, and tries to win the event by eliminating the differences. Utterly uninspiring “design”. This sort of philosophy was behind the FSAE that I walked into in 2001, where an extraordinary number of teams were playing the game by trying to out-Cornell Cornell.
- Our motor is different to Cornell’s. Cornell beat us. Therefore we need Cornell’s motor to beat Cornell
- Our chassis is a different shape to Cornell’s. Cornell beat us. Therefore the type of chassis that is best is a Cornell-shaped chassis which we will need to beat Cornell
- Cornell have an electric supercharger. Cornell won. We didn’t win. We don’t have an electric supercharger. Not only did the team that did win have an electric supercharger, but the team that didn’t win didn’t have an electric supercharger. So we need to both have an electric supercharger, and not have a car that does not have an electric supercharger.

This is the “winning by following” method, which is essentially the “we won’t have a competitive advantage while we are different to our competitors” philosophy.

One step up from here is the pure analysis / fault finding team.

The project will usually start with a fault-finding analysis of the teams effort at the previous competition. Pick out what we did wrong. Fix it. Merit in that? Certainly. You don’t want to keep doing wrong. We then divide the car up into pieces, and fix the faults in each of the pieces. Car isn’t light enough. Chassis not stiff enough. Engine not powerful enough. Roll centres too high. Bob can fix the chassis, Carol can do the chassis, Ted and Alice you can attend to the suspension geometry. Everyone, make your parts as light as possible.

Faults in the fault finding process?
1. To a certain extent you are limiting your scope to the design solutions that are already there in front of you. Your design template is effectively last year’s car but with some bits modified. This is “little picture” engineering, and you will only ever come up with a “legacy car” with some detail changes. If the
2. Very rarely will such a process adequately record and therefore keep all the good bits of the original design. We feel the “wrong” much more acutely than we feel the “right”.

In my time at RMIT, I saw about twenty different pedal trays designed. Every year, some new guy would come along and “design” a new pedal tray. Every year, the process would be – find fault in the old pedal tray (not light enough, not stiff enough, motion ratios were wrong, load paths were all wrong, too hard to manufacture, too wide, too narrow, too steel, too un-carbon-fibrous). Every year we would have a new pedal tray presented to us which was “better” than the previous one, (it must be better, we took away some of the wrongness…). Every one was stiffer, lighter, cheaper, simpler, stronger, better than the one it replaced. The net result after all this progressive and incremental improvement, over about 20 iterations – a pedal tray that is worse than the one Baz designed way back in 2003. We made so much forward progress that we ended up going backwards.

The process is rather easy to understand of course. Dave designs a pedal tray to the best of his ability. Dave’s pedal tray has flexi-pedals and the driver hates it. The following year, the team is told we need a new pedal tray with stiffer pedals – the old ones were lousy. So Brian the new pedal tray designer focusses his attentions on new pedals. He identifies where the flex is coming from, makes stiffer pedals. With much fanfare the new pedal tray is released - but it is way complex and difficult to manufacture. The team learns that manufacturability is important, so Graham the next designer is told that he needs to fix the fault of difficulty to manufacture.

See the pattern? Everyone sees the faults and points them out, no-one really jumps out of their skin to proclaim the good. So the designers find themselves in this downward, constrictive negative thought cycle. If I bow my side impact protection bars to give them greater side impact resistance, that is wrong because they are not good for chassis stiffness. If I leave them straight, that is wrong because they will just buckle under side impact protection. If I do both, and weld a bowed tube to a straight tube, that is wrong because it is heavy. If I ask for advice, I am told that I need to figure it out for myself. So what does the designer do? Rather than risk being wrong, rather than draw the attention of the critics by doing something different, they take the line of least resistance and do what everyone else is doing. Result – lots of cars carefully designed to look the same as each other.

I liked Carroll Smith. I thought he was a cracker of a bloke, and I was fortunate enough to see him in action once back in 2002. From my short impression it seemed that he saw the good, and he saw the bad. And he pointed out both. He made you think, he often critiqued cars by asking questions (So you have a lot of camber gain here – what does that do under cornering? What about braking?). He would not spoon feed you, but he would guide you through a series of questions until you came to an understanding yourself. And if he saw something he liked,he pointed it out. Constructive criticism, but criticism that included positive encouragement too. It is something that I took into my teaching career.


Something that I find curious is that despite our displayed behavior and overt tendency to gravitate towards phase two critical / disputative thinking, we actually don’t really want to be there. When I look back on my time in FSAE, my fondest memories were of:
- Mateship (phase 3, collaborative)
- Dreaming up ideas for cars I wanted to build (phase 1, creative)
- Making stuff (primarily a combination of phase 1 creative and phase 3 collaborative)
- Checking out cool designs and chatting to the designers (a combination of phase 1 creative and phase 3 collaborative)
- Meeting a whole heap of cool people from around the world (a combination of phase 1 creative and phase 3 collaborative)
- Achieving stuff that the naysayers said we would never achieve (anti – phase 2)
- Summer nights having barbeques and shooting the breeze with a bunch of mates that you would do anything for.
- Laughing
And the things I hated:
- Team politics / divisiveness / bickering (phase 2 extending into anti-phase 3)
- Egos (phase 2 extending into anti-phase 3)
- Bureaucracy (which roughly means doggedly abiding by a set of rules implemented on a piece by piece basis from a firmly phase 2 mindset)

So what I think are my natural instincts are telling me that I want to be collaborative, and I want to be creative. Yet my education, the newspapers I read and the news and current affairs that I watch and all our politicians and lawyers and rulemakers want to operate in an almost exclusively fault-finding phase two mode.

Progress is about moving forward, it is not about not moving backwards. Life is an infinite bowl of jelly beans. Do you really want to spend your whole life picking out the black ones? Time spent avoiding the things you don’t like, by default, becomes time spent away from the things that you do like too.

When I get to the end of this life, I want to reflect on my contribution to this world in terms of what I created and achieved – not in terms of the number of undesirable things I managed to avoid. The latter firmly focusses your mind in the confining and the negative, and negative you will become.

So I end my chapter today on positive thinking with a double negative. I obviously need to work on this….

[Loz]

Geoff/Others

In defence of the "critical/fault-finding" or analytical phase/s of the engineering process, it is important that the contribution of critical/analytical phases be recognised to occur more than once throughout the process. The role of critiquing or "fault-finding" and its placement in the problem solving process should really be a free variable. i.e. it can occur at different times and can contribute in different ways which aren't necessarily anti-collaborative/creative. It is also a recurring function that is necessary in an iterative design process.

For example, in the early stages of the problem definition and concept generation (and independently of creative pursuits like brainstorming ideas etc), it is necessary to do a "first pass" critique with fundamental analysis tools (e.g. math about the physical world) to establish some loose boundaries which effectively act as known's until proven otherwise. Newtonian fundamentals are well placed here. Even though limits or boundaries may be generated which are seemingly creativity killers, they only serve such a purpose if the mentality applied when the analyses are conducted is as such. This is where the psychology of a typical engineer can certainly stifle innovation. When providing an engineering solution to a problem, it is always necessary to impose limits reduce the solution space to a manageable region. It is simply part of engineering. Even though it is not specifically a "fault-finding" activity, it can (and mostly does) place physiological limits and constraints on creativity and collaboration in a similar fashion to implementing a purely "fault-finding" design process.

HOWEVER (big however), it is the engineers discretion which determines how this feeds into the process and what it means to the successive solution trail. Just like in the general scientific field, limits are only limits based on the scope of currently available information and knowledge with some level of certainty (or uncertainty as is usually quantified). It is an understanding of the currently known limits which often provide the greatest opportunity for creativity [Note: This is especially the case for engineering minds which usually struggle to be purely creative]. It is well spelled out in your "Reasoning..." thread, the limits and boundaries imposed by a set of rules can be (or should be) perceived as opportunities to pursue something that might be unorthodox (often also referred to as innovation, creativity or thinking "outside-of-the-square"). If the engineer chooses, this process of seeking the limitations through a critical process can in fact increase creative possibilities and expand the solution space if some time is taken to understand what the imposed limits really mean.

The opportunity for expanding creativity occurs again in the middle stages where the analytical (selection) process often occurs. The second phase you speak of (the critical analysis) is used to prune the solution tree and determine which is the best fit to the problem. This doesn't have to be a one shot process (and I'm not suggesting that was your contention), but it often does proceed this way. In more recent times this has become worse as we (as an engineering collective) become more incautious about accepting as truth anything that has an absolute value attached to it, especially anything from a simulation (e.g. becoming less reluctant to question the validity or accuracy of a result that a numerical simulation spits out). This critical/analytical phase should provide a second opportunity for expanding creativity by understanding the facets which prevented (or limited) the other "less ideal" solutions from from being selected as the "best fit". Point 2 and 3 below really need to be (and should be) part of an iterative procedure (and one of multiple iterative loops in the FSAE design process).



BRINGING IT BACK TO FSAE
So what are the objectives in Formula SAE:
1. Understand the problem (best done collaboratively)
2. Propose potential solutions (creative, expansive)
3. Analyze solutions to pick out the best one (critical,fault-finding)
4. Manufacture our solution (collaborative)
5. Refine our solution (collaborative)
6. Present our solution to the various judges, informing them of what we have learnt along the way, (collaborative)
In each of the above, we could potentially argue that each of the three mind states can be useful - however I have chosen to present the most prominent state.


It is frequently recognised that it's often the "ignorant" who generate the most innovative solutions as they are free of prejudice with an unbounded thought process, thus promoting limitless creativity (often referred to as the antonym of an engineering mind). How we perceive the limits established during the critical phase is again at the discretion of the engineer to choose. They can be absolute and deterministic and the process is generally more "negative", or they can be key pieces of information which provides a first step to exploiting the the limits imposed allowing further creative thinking (i.e. more "positive"). It is this part of being critical and developing an understanding of the imperfections or limits of "inferior" solutions which allows one of my favoured activities (as you put it in Post #1) "Achieving stuff that the naysayers said we would never achieve (anti – phase 2)".
However, this only happens if the the critical and fault-finding activities are performed in the more "positive" sense with an acceptance that very few things are actually absolute, almost all solutions have value and/or feasible components that can harnessed.

As in Chapter 2 of the thesis,


Accepting that we need critical thinking / fault finding to be part of our process (but not all of it), how do we engage in the fault finding process (dispute) without it being a tug of war? How can we do it with the least usage of time, energy and resources?
1. Be honest with each other – don’t sugar coat stuff, and don’t put spin on your argument to favour your own favoured solution. If an engineer proposes a certain design solution and refuses to see any fault in it – sack them. If an engineer looks at someone else’s design solution and refuses to see any good in it – sack them. If the whole team knows they can trust each other to offer unbiased, honest information to melting pot – then the layer of complexity and wasted time attributed to breaking through sales spin is averted
2. Be critical – yep, point out what you see as wrong. And if someone finds fault in your critique – listen to that too and see if it makes sense. Ask yourself what you can learn from their perspective on this – rather than get all defensive and feel the need to prove them wrong.
3. Be encouraging – point out the good as well as the not-so-good
4. Be dispassionate about the product – we are building a self-propelled protective chair. Don’t be precious
5. Be mathematical – use numbers wherever possible to decide an argument for you. Don’t under any circumstances fudge the numbers, otherwise point #1 above flies out the window
6. Be thorough – make sure your mathematical analysis is comprehensive but appropriate
7. Be realistic – don’t expect you will solve all the FSAE problems in one year. Know when to say enough
8. Be humble – don’t get all precious if you don’t get the answer you like. You are an engineer. You don’t like. You do.
9. Be team focused – the team helps you to achieve things to a much grander scale than what you can achieve on your own. You would not have this opportunity without your team. Live for the team. Not yourself.
10. Be results focused – Your tasks as a team are to gather competition points, encourage new students to come to your uni, promote your university’s name, secure resources for your project and future projects. Know your objectives, and measure your success in terms of them. Don’t get bogged in petty arguments and don’t shift the goalposts as you go along. Set a deliverable plan, deliver on it.
11. Move on – when the design is frozen, and the disputing stage is done – stop your whinging and move on. Sure, keep an eye out for unforeseen faults, but do everything you can to be collaborative to deliver on that final product.


All of this is is necessary. In addition, it is important to recognise that the activities which are connected to the critical/fault-finding process can (or should be) dispersed among other more positive and collaborative phases. Even though they might be implicitly "negative" activities, the output can perceived to be positive and then used to progress the broader "positive" process. Thus as an extension to the list, there should be a point that addresses the need to not solely be critical for the sake of fault-finding but to support an iterative feedback loop which reinvigourates creativity having outcomes which are used for good and not evil. It doesn't have to be a bad thing for the critical phase to creep into creative phase. In a non-sequential design process such as FSAE where it is necessary to "Design it. Build it. Break it." (Pearson, n.d.), there are many times when a good critique is the most positive thing that can occur.

Loz

[Big Bird]

Nice one, Loz. What a well written and considered response. Thank you!

I'll take a day or so to get back to this - but I will get back to it.

Cheers!

Geoff

[Big Bird]

I’m not going to be too verbose here. Loz, I fully agree that a critical eye needs to follow the whole project. My concern, though, is that a lot of engineers that I have worked with are not too flash when it comes to the discretion you speak of. Their first response is one of finding the wrong – and then there is not much else after that.

Engineering has a culture about it that is firmly founded in pointing out the wrong. I live in a country that no longer has an automotive industry, despite the talent we have here. A lot of this is due to the fact that the industry refused to change despite imminent threats – because there was always a reason to not change.

It takes a brave soul to stand before a team of arguing engineers and broker an action plan. Especially if the action plan is NOT “Let’s just keep doing what we have always done”.

My thesis above is an attempt to break a few minds into being a bit more positive and adventurous. Because to be quite honest, for a competition that is meant to be about fostering creativity, there are a lot of very similar looking cars out there. Where is the next UWA???

Cheers all. Would be glad for a few more to chime in, it feels like I'm talking mostly to myself here...

[Loz]

I agree and and share the concerns. It is apparent everyday that the culture of modern day problem solving continues is trending towards methods which are highly conducive to impeding the the process of finding a solution (especially in the case of engineers).
Without grumbling too much, the plethora of bits and bytes floating around the intrawebs and the "Google generation's" tendency to absorb any and all of it as verbatim truth, is not assisting the matter. I could grumble about schools and education, but Z could do that far better than me...

It would be great to see a team work though the process without once consulting a digital reference, or at least staying away from such external influences until the point of manufacture. It is impossible to remain free of bias as everything which comes before necessarily shapes the future. However, I think it would serve a team well to employ a strategy which was specifically implemented to mitigate creativity constraints to the problem solving process. Part of which would likely be a far greater emphasis on the use of "traditional" tools like logic, reasoning, geometric constructs, proofs (not necessarily mathematical and could certainly be physical e.g. testing) etc.

Perhaps one way would be to treat the first team meeting of the year like an AA meeting where everyone sits down, is honest and admits they have certain biases, fixations and a cache of "old dog" tricks that will be hard to unlearn and they have no control over them. Once everyone's compulsions and addictions are out in the open, all of the contributing substances are locked away and the steps are put in place to prevent the habits from perpetuating.

In the same vein as the twelve step program, the first step to freeing the mind comes from admission that it is constrained.

Loz

[Jay Lawrence]

^ what a great metaphor!

Personally, we had (and still have) some very creative minds on the team (myself not really among them. I am, somewhat sadly, better at criticising rather than creating). Unfortunately the arrogance of some with the creative mindset caused them to either not see the flaws or not accept any criticism (their projects often causing massive headaches for the team). A mixture of creative, rational and critical brains should be a perfect mix for this project, but the 'authority' levels and influences don't always match up. I would say that this is the biggest cause of teams being unable to be consistently high performers.

My 2c

[Z]

Would be glad for a few more to chime in, it feels like I'm talking mostly to myself here...

Geoff,

Thanks for your words so far. This is a subject I feel strongly about, so you can expect a looong post in a few days...

Unfortunately, I am a bit busy feeding the chooks right now. Many, many chooks to feed...

Z

[Big Bird]

Thanks gents. Z, I knew your reserve thus far was more about having too many words to say than not enough. I look forward to your input!

Cheers all

Geoff

[Brett MacPherson]

We're a team in the process of designing our 6th car, and the 2015 car will be my 3rd. Because of this I don't have a lot to offer in the way of wisdom, and I'll have to go based on the oral history I've gathered along my way, but here we go.

The first few years of our team were very disjointed. Lots of big ideas by a small group of people. The team had a high turnover rate year to year, and poor knowledge transfer meant that we jumped between blindly rebuilding a part of the previous year's car verbatim and redesigning systems from scratch. We had the mindset the system X didn't work so obviously it's a poor design that we need to the scrap, and system Y worked fine so it is perfect and don't dare change it. It was extremely difficult for anyone to understand why a system failed like it did, because the designer was often long gone and left no clues as to what their process was. If you're new, taking the time to breakdown and understand an entire system is an extremely daunting task, whereas reducing it to bite-sized portions we can digest as we design it ourselves over the year is much more palatable.

I am in no way trying to defend this process, because it is obviously flawed. What I'm trying to do is understand it so that we can be better managers as the team matures. I like to think of creativity, critique and analysis as the three axes on a sort of vector diagram. Each situation will require different amounts of each skill, and it is all going to vary throughout the life of the project. (Then again maybe the three are on a 3 dimensional continuum...hmm..)

It often seems easier to start from scratch with a design that you created and "trust" than to reverse engineer someone else's failed design. How difficult is it to look at a failed design, maybe even one that ruined a competition for you, and see the good in it? But how easy is it to be critical of it? When we're in this sort of situation, we obviously need to combine critique (the easy and obvious one) with the skills of creativity, and analysis (the difficult ones) in order to succeed. The focus needs to be on shifting the team's mindset away from being armchair critics to being analyzers. In becoming the senior members on the team, we're expected the set the tone for new members and if managers work to create an environment of learning, rational analysis, and constructive criticism then that is what the team will become.

I really like Loz's point that the first step to improving is admitting our faults, which we all do to our car relentlessly, but often hesitate to do to ourselves and our team. We need to take it a few steps further and dig deep into the whys and then come up with potential solutions from there. Our program at university seems to paint engineering as a profession of designing, not one of analyzing, and certainly not one that teaches you to deal with other human beings. So here we have a group of people who have no experience managing, trying to work with people who have little to no experience being managed, and convince them to build a racecar together. I'm still amazed we've ever managed to pull it off.

[Z]

CRITICAL THINKING 1.01 - WHAT IS IT?
===================================

Geoff (and others interested),

While I agree 100% that there is too much FAULT-FINDING and NEGATIVITY in the typical Engineering workplace, I really DO NOT think this has anything to do with "critical thinking". Here I am much more in agreement with Loz, namely that good critical thinking is a positive force that enhances "creative thinking".

But to explain this is going to take quite a few words. Apologies for this, and I have split these hastily cobbled together notes into multiple posts for easier reading.
~~~~~o0o~~~~~

It has taken me the better part of a half-century to realize that "too much criticism" in our societies is NOT THE PROBLEM at all. Rather, it is almost the exact opposite. It is the COMPLETE LACK OF GOOD CRITICAL THINKING these days that has given us a world where nothing much really new, or useful, or interesting, ever seems to happens. (I am happy to debate this claim, but moving on for now...)

So, just what is "critical thinking"?

Looking up the definition of "critic", "critical", "criticism", "critique", "criterion", etc., I find words that stem from Greek kritikos = able to discern, or judge, which ultimately stems from krinein = to decide. Sure, some of the many variations of meanings of the above words refer to "finding faults in...". But for the most part the words simply refer to the ability to "clearly see the differences" between different things.

So, how do we go about making a good decision (krinien), or judgement (kritikos), on any particular matter?

I would suggest that we start by gathering as much relevant evidence as we can find on the subject. We should then sift the evidence, rating it for reliabilty, and then remove the dross. We then put the reliable evidence on the balance-scales, weigh it, and finally see which way the balance-scales fall.

And, like Lady Justice, whose statue stands in front of many "judgement" rooms, we should do all this while metaphorically wearing a blindfold. That is, we should NOT let any of our many innate prejudices and biases affect this assessment process.

http://www.lifeofthelaw.org/wp-content/uploads/2013/05/LadyJusticeImage.jpg
[Disclaimer: Real Courts may NOT work as advertised above... :)]

Note that this evidence, which is gathered and sorted by the process of "critical thinking", is just objective stuff. It is observable facts, and numbers, and measurable quantities. It is NOT feelings, or hunches, or, to quote Daryll's lawyer from "The Castle", a "vibe".

This objective evidence should always tilt the balance-scales in the same direction, regardless of who is weighing it out, or even who might be looking at it.
~~~~~o0o~~~~~

Example 1. In my dictionary, in amongst all the quoted words above, is "critical-point". This is the point on a phase diagram, measuring temperature and pressure, at which a substance can change its phase between solid and liquid, or between liquid and gas, and so on.

Importantly, note that this "critical-point" is NOT FINDING FAULT with any of the phases. It is NOT BEING NEGATIVE in any way. It is simply making a clear distinction, in terms of some numbers specifying temperatures and pressures, between the different phases of solid, liquid, or gas.

Now, if we happen to be swimming in very cold water (perhaps in a heated wetsuit), and the water suddenly passes through the critical-point and changes to ice, then, yes, we might get mightily annoyed at that "criticism".

On the other hand, if we are walking across a frozen lake and the ice suddenly passes through the critical-point in the other direction, and turns from ice into water, then, yes, we might get very annoyed again.

But there is nothing intrinsically faulty, or negative, with either side of the critical-point. Ice and water can be both good and bad. The critical-point is simply the objective dividing point between the two. Any fault-finding, or annoyance, that we might find in either situation, is simply our subjective assessment based on our wishy-washy feelings at the time.

These subjective, wishy-washy, feelings are hardly a good basis for making rational, well-reasoned, Engineering decisions.
~o0o~

Example 2. Another good example of an everyday "criticism" is the sign in front of the fun-park ride that has a horizontal line painted on it, and the words "You must be taller than this to ride.".

The short little boy who loves running around and crashing into things thinks that this "criticism" of his height (or lack thereof) is a disgraceful example of fault-finding and bullying.

On the other hand, the much taller, but suddenly rather cautious, young girl might also dislike this criticism of her excessive height. Especially as her father (yes, Old Z) mumbles "Oh, stop being such a sook! You whinged and moaned all last year because you were too short, and now you are head-and-shoulders above the line. The line says YOU RIDE!!!". And he drags her kicking and screaming onto "The Vomitron"... (All children should be made to vomit from too-much-fun at least once a year! :))

Either side of the "critical line" can be good or bad, depending on the viewer's perspective. The line is just a line.
~o0o~

Example 3. Another word related to "critical" is "crisis". This also stems from krinein = to decide, and it means "a turning point in the course of events...".

Interestingly, it seems that nobody ever looks forward to a crisis, even though, in principle, it could mean that things suddenly change for the better. This asymmetric attitude is, I believe, the crux of this whole matter. Please read on...
~~~~~o0o~~~~~

IMO, a great deal of the fault-finding and negativity that goes on in our societies is due to FEAR OF CHANGE. Another plausible reason is good old-fashioned LAZINESS.

Observing a typical H.Sapiens society, I see a flock of sheep that are waist deep in a mud-hole. There is only an occasional thorn-bush poking out of the mud that they can graze on. An Old Goat standing further up the hill yells out "Hey, why don't you all come up here. The grass is beautiful and lush. No mud. No thorns...". The sheep all bleat in chorus "Nooooo waaay! Weeee're doing just fine heeere. And what would a stupid old goat like you know anyyywaaay...?".

Mud hole? Thorn bushes? No problem, because it could be much worse! Things have to get VERY BAD before anyone considers changing their lifelong habits. As Geoff noted earlier regarding FSAE, the all-too-typical attitude is "Well, we've done sort of OK until now. So we may as well just keep on doing the same-old, same-old...".

Yep, life is very comfortable in modern Western society. Nobody could be bothered rocking the boat.

Not even if this "rocking" is in a rather insignificant, and risk-free, student competition like FSAE. A place where rocking the boat just a little might get you 3.5 second Acceleration times, sub-4.0 second Skid-Pad times, and all-round performance that makes every other car look like it is standing still. "Oh, no, no, no... Don't listen to those stupid old goats. Much better to stay here, waist deep in the s#:+, with ... yippeee, found another one ... all these thorn-bushes to eat!"
~~~~~o0o~~~~~

Anyway, to sum up this section, the vast majority of what passes as "criticism" these days, even when it is dressed up as "rational Engineering analysis", is nothing more than a desperate attempt to prevent change. I am not sure if the root cause of this is mainly "fear", or "laziness", or a bit of both. But it is most certainly "H. Sapiens".

One way to break out of this boring prison is to simply start making RANDOM changes. This is how Nature does it with "evolution", and very well it works indeed. But, unfortunately, this method is very expensive, since most of the random mutations end up being, quite literally, dead-ends. (Note that Nature can afford this expense, because, to put it bluntly, life is cheap.) In fact, the many dead-end results of this "trail and error" approach may be why people are so frightened of change.

So, is there any sensible way of sorting the few potentially good changes from all those dead-ends, thus reducing costs and speeding up progress?

OF COURSE! It is simply a matter of THINKING CRITICALLY!

More coming...

Z

[Z]

CRITICAL THINKING 1.02 - HOW TO DO IT.
======================================

I Googled "critical thinking" and, unsurprisingly, I found a lot on it, but mostly in the form of many rather meaningless buzz-words and phrases. I doubt most of it would help student Engineers who are trying to build a better "small racecar".

So what follows are some brief hints on different ways that you students can separate the wheat from the chaff (ie. apply "critical thinking") as you search through the myriad alternative ways of building your small racecars (ie. do the "creative brainstorming"). These tips only cover a very small part of the full range of critical thinking skills, but they are a start.
~~~~~o0o~~~~~

THEORY vs PRACTICE.
===================
In THEORY, you students should be able to decide (= krinein, remember) whether an alternative design of FSAE car will be "better", in whatever objective way you wish to measure that, by simply applying well established Mechanical Theories. In short, your "simulations" should give you the objective answers.

But, unfortunately, because of the failed Education system many of you have very little understanding of how these Theories work. The clues confirming this are the number of times I have seen rather complicated looking equations posted on the Forum, that seem somewhat irrelevant to the problem at hand, and which were probably just cut-and-pasted off the first website that covered that subject. The clincher comes when some crudely guessed input is loaded into these equations, and the results are then printed out to FIVE DECIMAL PLACES!!!

So, to once again paraphrase Prof Lewy, "All your simulations are UTTERLY USELESS, if you DO NOT KNOW THEIR UNCERTAINTY!!!".

Even the simplest, most predictable, simulation is unlikely to give five decimal place accuracy. So, rather than fooling yourselves that your analysis is so precise, you should be spending much more time estimating your errors. At the least, this requires looking very closely at the many simplifying assumptions that are used in most of the simpler Engineering Theories, and how these might introduce errors. You should also estimate the errors in your input data, which in many cases in FSAE are of the order of ~+/-10%, if not more.
~o0o~

In PRACTICE, I am confident that suitably motivated Trade School students, who might have absolutely NO knowledge of any Mechanical Theory at all, could nevertheless build a very competitive, perhaps world-beating, FSAE car. They could do this simply by making a critical analysis of all the "prior art" that is out there, and then selectively COPYING those parts of the prior art that seem most useful in FSAE.

This prior art includes 100+ years of motor racing (of all types, including bikes, boats, and planes), and everything from Go-karts up to Monster-trucks. You do not have to be a rocket scientist to realize that the wheel-bearings on a Monster-truck are probably a good deal oversized for FSAE. On the other hand, those on a Super-kart might be a pinch too small. So something inbetween, perhaps off a small production car? And so on with all the other parts.

My point is that all the sub-systems required for a world-dominating FSAE car are already out there. They have already been designed, and thoroughly developed, tested, and PROVEN. Sure, some of them might not be running around today, like some aero-approaches that were banned ~30 years ago because they worked too well. But you can still see this stuff on the interweb. Or, better yet, GET OUT THERE and go to historic racecar days. Or just wander around a car wreckers yard.

In Engineering terminology this practical approach is called "Reverse Engineering". It is quite legal in FSAE, and it can be very educational.
~o0o~

To sum up here, the theoretical approach allows you to EXTRAPOLATE designs to places no one has ever been before. But, to have any hope of getting the right answers, you must understand the theories VERY well. I suggest using the most fundamental theories (eg. Newton's Laws), and putting in much more effort estimating how WRONG your answers might be.

The practical approach allows you to INTERPOLATE your new design between other existing designs that have thoroughly PROVEN performance. The key to this approach is recognising which of the many existing designs have the best features for your particular application. This can be done with a stop-watch, or a weighing machine, or even with a theoretical simulation. But first you have to GET OUT THERE and study as much of the prior art as you possibly can!
~~~~~o0o~~~~~

QUALITATIVE vs QUANTITATIVE.
===========================
QUALITATIVE assessments are based on comparisons of general "qualities", and use words like "greater than", "heavier", and so on. It is natural that the early stages of critical analyses use mostly this type of thinking.

For example, "We know that MORE torsional stiffness is better for a chassis, and layout-A has the potential to be MUCH stiffer than layout-B, so we should definitely use layout-A. Err..., except that LESS weight is also better, and layout-B will probably be a LITTLE BIT LIGHTER than A. So..., err..., maybe we should use ... B???"

Decisions based on qualitative thinking are very easy to make when ALL the qualities point in the same direction. So if some new design is "win, win, win", then the choice to adopt it is obviously "Yes, yes, yes!!!". But the problems start when some qualities of a particular design point in a good direction, while others point in a bad direction. Typically, this is the most common situation.
~o0o~

QUANTITATIVE assessments are based on comparisons of hard "numbers" (ie. "quantities"). The above common problem of deciding whether the "fors" outweigh the "againsts" in a particular design can be solved by "quantifying" the various factors (ie. putting numbers to them). The numbers are then simply summed to a single total, and the answer is easily determined. Or is it?

Unfortunately, getting accurate numbers is not always easy. If "theoretical" calculations are needed, then there are problems related to the uncertainties mentioned above. And even if accurate measurements can be made from pre-existing "prior art" parts, it is not clear how to rank, say, a numerical stiffness value against a numerical mass value.
~o0o~

So neither of the above approaches is guaranteed good. Here are two warnings of what can go wrong.

1. Say I take ten hops forward, and then one skip backward. Am I now in front of, or behind, my starting point?

Note that the size of these "hops" and "skips" are qualitative, because they have NOT been quantified. So I could end up well BEHIND where I started, simply because the "skip" was much, much, bigger than the "hops".

Much qualitative decision making goes wrong for this same reason. A particular design might have a hundred qualitative assessments in its favour, and only one against, but it could still be a COMPLETE AND UTTER FAILURE. The one "against" might be a really big one.

So be wary of arguments that try to boost one side of the balance-scale with many lame entries. A typical FSAE example is the list of reasons in favour of Push/Pullrods&Rockers, which includes "...can reduce unsprung mass...", and "...can make damper adjustments easier...". The first claim is nonsense, and the second is so insignicant as to be worthless. (And there are many more such lame claims.)

Using such "bottom of the barrel" reasons to boost the numbers on one side of the balance-scale is a sure sign of subjective bias, and poor critical thinking.
~o0o~

2. Quantitative decision making often involves the use of arbitrarily determined "weighting coefficients", which are intended to scale the differently dimensioned values (eg. mass, stiffness, etc.) so they can be "fairly" compared against each other. Be aware that whenever this happens the whole process can very quickly descend into subjectivity, and a truly fair objective comparison is lost.

A recent FSAE example is a "decision matrix" a Team used to rank the suitability of a single cylinder engine against various configurations of twins. The single was a clear winner in all areas, except one. For some reason, in this area the single was given a "power potential" of 0/5 points, with the twins getting up to 5/5. This particular attribute was also given the highest weighting. As a result the single was just squeezed out of first place.

There was NO real objectivity to this process at all, and the parallel-twin which won was clearly the intended winner all along.
~~~~~o0o~~~~~

The best decision-making comparisons you can make in FSAE are with a stop-watch on the completed car. I suggest you try to get your other, more academic, comparisons as close to this as possible.

And please wear that metaphoric blindfold while doing so.

Last bit coming next...

Z

[Z]

CRITICAL THINKING 1.02 - HOW TO DO IT (Continued...).
==============================================

The above post suggests that "critical thinking" is not always easy, and we cannot expect the right answer to fall out after minimal effort.

So how do we decide which results of the above processes we should trust and follow, and which we should ignore and discard?

TRUTH vs FALSEHOOD.
====================
This is a very important subject.

So much so, that from Antiquity to only a few hundred years ago, all students in the Western world would study this as one-third of their foundational education. That is, Logic was one of the three subjects of the Trivium, which itself was the first part (ie. literally the easy, or "trivial", part) of the Academic curriculum.

Sadly, nowadays almost all students who finish tertiary education have NEVER BEEN TAUGHT how to tell truth from falsehood.

What follows is just the briefest of brief introductions to this subject.
~~~~~o0o~~~~~

All Ronald McDonalds are Redheads.
All Ronald McDonalds are Clowns.
Therefore, all Redheads are Clowns!

Is this argument, which consists of two premisses and a conclusion, a GOOD argument?

Well, most people know of a particular Redhead who is NOT a Clown, so they conclude that the above bit of reasoning is, err..., probably, ummm..., not right? (I tested my children on this one years ago, and that was their answer.)

Indeed, as all schoolboys USED to know, this particular Logical Syllogism is INVALID. Note that a "valid" syllogism implies that the conclusion is true IF both premisses are also true. An "invalid" syllogism might have a true conclusion (ie. by chance), but its use in an argument is worthless. So, while all Redheads might by chance be Clowns, the above argument is a waste of words, just hot air...

The purpose of teaching olden-day students Logic, as one-third of their entry level subjects, was so that they had some chance of drawing the correct conclusions from arguments that they might hear in their later, much harder, subjects (ie. the Quadrivium). For example, all the different syllogisms were given their own, unique, names, for easy recognition. The above syllogism is "Barbara in the third figure", from the mnemonic bArbArA for All-All-All.

So a student would hear the above argument, quickly recognise its structure as "Barbara in the third...", and then immediately dismiss it as piffle. No need to even think about Redheads, or Clowns, and so on.

But the really troubling thing is that I know many modern-day Academics who replace "Ronald...", "Redhead", and "Clown" in the above syllogism with terms appropriate to their field, and then use exactly that same syllogism to support their hypotheses, in the ignorant belief that their argument is VALID.

My point is that, as shown in the earlier posts, it is hard enough to determine if individual premisses are true or false. But nowadays there are too many people, all of whom should know better, who cannot string two premisses together and deduce a reasonable conclusion.

Anyway, no space here to go into more detail about syllogisms, other than to suggest that you try Venn Diagrams to make sense of such arguments. But it is worth noting that out of 256 possible syllogisms, ONLY 24 ARE VALID. And even some of these are considered dubious in "existential" cases.

So keep in mind that MOST ARGUMENTS you hear in your Concept Design meetings are probably INVALID. This applies both to those arguments that say "We should keep doing the same-old, same-old, because...", and also to those that say "We should use this new-fangled bit of gee-wizardry, because...".

The stop-watch, and a real, finished, car, are the best way to decide "true or false".
~~~~~o0o~~~~~

Along with syllogisms, the olden-day start-of-school Trivial subjects of Logic, and also Rhetoric, taught students about the MANY OTHER FALSE WAYS OF ARGUING. There are far too many of these to cover completely here, so just a few examples.

* The "non sequitur" (="it does not follow"). Does the following argument make sense? "I had cornflakes for breakfast this morning, therefore we should implement rear-wheel-steering on our car." OK, that one is obviously nonsense. But it is surprising how many people fall for non sequiturs that are a little less obvious.

* The "post hoc, ergo propter hoc" fallacy. This "after this, therefore because of this" way of thinking is sometimes nowadays referred to as "causation versus correlation". Just because A happened before B, does NOT mean A CAUSED B.

* Excessive emphasis. One way of spotting a false argument is by noting the volume of its delivery. This is especially so when the argument comes with very little quantitative back-up, or none at all. Saying "WE MUST HAVE THIS ON THE CAR!!!" does not make it a better argument. Ahh..., but then again, we are talking about H. Sapiens, "the wise one".

* The "ad hominem" attack. In sporting parlance this is called "playing the man, not the ball". Despite Lady Justice's blindfold, this is perhaps the most beloved tactic used by lawyers. "If Your Honour pleases, I will now show that many years ago the witness's pants once fell down in public, and therefore not a single one of his vile and slanderous rantings can be trusted one iota!!!".

* Finally, "ad hominem" is often used in a reverse way. How many times have you students been told that you should believe an argument, simply because the deliverer of said argument has worked with NNN professional race teams, over M decades, and has given countless seminars, to even more countless students and Engineering professionals, and they also have a Racecar Simulation software package they can sell you? Ask yourselves, "If the argument is really that good, then should it not stand on its own merits?"

(Edit Nov2014: Students may wish to google "Appeal to Authority", "Argumentation from Authority", or "Argumentum ad Verecundiam", for more background on this fallacious way of arguing a viewpoint. This post (http://www.fsae.com/forums/showthread.php?11902-Direct-Actuation-Vs-push-or-pull-rod&p=122049&viewfull=1#post122049) gives a recent example.)
~o0o~

More than enough for now...

As always, critical critiques of above most welcome. :)

Z

[Kevin Hayward]

Z,

I think you are too harsh on students that are the product of a western society that embraces relativism. It is also interesting that the Indian teams (from a country steeped in relativism) seem to perform worse. We are raised to believe that what is true for you is not necessarily true for me. There are many roads leading to the one place.

While this keeps the philosophers and artistic types quite happy and entertained it wrecks havoc with engineering. In reality there is truth that is true whether you believe (or like) it or not. Argument about what is true is constructive, argument about whether there is truth is not.

Kev

[ABCD]

Hey Big Bird and Z, thanks for taking out time and bringing an interesting point up. It sure makes you think more on how you and the team works.

We are just in the process of redesigning our Pedal tray and those couple of paras really crack'd me up ;) but in our defence our reasons are different from those pointed out there.

I agree with Z on the reverse engineering and particularly more so in the Formula Student scene as here (atleast in my team) every year you have fresh bunch of junior designers. I believe that it is better if they study some existing design and then redesign it to suit their car and over the course they will definitely hit on some intriguing questions which will push them to bring creative solutions.

ABCD.

[Charles Kaneb]

Newer designers go for "safer" solutions. A Formula car looks huge when you first look at it - all of those parts to design, all of those parts to make, all of the integration to connect one part to another. If it's your first time designing a nontrivial part, you're less sure of what you want, less sure of why you want it, and less sure that you'll be able to do it than afterwards. So you want a path leading from what you know how to do now to a result that resembles what you've seen before. Next time you'll know more and will go about it differently.

Think of it like cooking chili. If you're starting out with a new recipe you haven't eaten, the first time you cook it, you'll follow the directions exactly, like a baker. That way, you know exactly what ingredients to get, how much of each to add and when, how hot to get it for how long, and you can expect that it'll taste like the recipe writer's chili. It's gonna cost $15+ and take up six hours on the stove, so you don't want to end up with something to throw away. Once you're done cooking it, you now know which steps were difficult (chopping green pepper to < 10 mm chunks), which ingredients were expensive (beef) - you know the process. Once you and your friends have eaten it, you know what it tastes like - you know the process. Once you've heard what they thought of it (man, that was bland) and thought about what you were tasting (hmm, onions, beans, chili powder and what else?), you know what they thought about it - you know the result. Now you get to do the evaluation and the analysis for next time - you get to improve (that word's got "probare" in it somewhere, if someone who knows Latin can find it) and change the recipe. I suppose this is like the post-critical part of the design process. In go the green peppers 20mm on a side, in go three cloves of garlic, in goes the salt that some dietician reviewing the recipe before publication took out, and maybe you even dare to take a risk you haven't comprehensively evaluated and switch the beef for some tiny beans - but you think it'll work. You've got some confidence that the changes you're making will go from where you started, in a direction where you wanted.

After the second pot of chili, you're able to move to an active rather than reactive mode. You know you'll definitely be able to make an edible chili (confidence), and have a good idea of what the taste and texture are mostly determined by. You can now estimate quantities and effects. I've got 5 kg of vegetables in that pot, so adding a gram of black pepper is unlikely to change it much. You can start from a completely different plan with a little knowledge of what's going in - I want a few clear French flavors with all those beans, so I'll saute' the onions half as long, put them in last, and put in two bulbs of garlic.

Of course you can still be surprised; you don't know everything. Some process can be sensitive to a variable you didn't know about (the TVP might need the whole mixture to be bubbling merrily away for a few minutes before it absorbs the liquid) and if the plan is to just let it slowly cook along after it's added you'll have to change the plan after the first taste. You can always be let down by your inputs (the jalapenos and cayennes that had no heat at all). Finally, sometimes maybe your goals aren't the same as the ones you had as a beginner. The looks of delight on my friends' faces as they tasted the onions, garlic, and pintos and then the looks of surprise as those five Carolina Reapers rolled in steadily bite by bite and crested several minutes later were worth a 9th place finish in the chili cookoff today. I had no difficulty ladling out extra chili afterwards.

To sum up - few first-time designers handed an assignment to "design a suspension rocker and pushrod system" will come back with a transverse leaf spring, few first-time chili cooks will come back with enough garlic to make canned beans and tomatoes taste like they'd been fresh.