Slashdot Mirror
Smart People Choke Under Pressure
People perceived as the most likely to succeed might also be the most likely to crumble under pressure.
A new study finds that individuals with high working-memory capacity, which normally allows them to excel, crack under pressure and do worse on simple exams than when allowed to work with no constraints. Those with less capacity score low, too, but they tend not to be affected by pressure.
No offense, but it's considered bad manners here to post the article text under your login name (as opposed to anonymously). People consider it a "cheating" method of trying to raise your karma.
No it talks about high working-memory capacity and says nothing about smart people. The title of the submitted article is a little misleading. This appears to be the original article, while here is some of the other work, includes sports performance as well maths.
Unfortunately engineering school tends to drive away the creative people.
I can tell you that it doesn't take more than 1-2 such projects, to give one the idea "no, you don't. Not again. Give me a good spec up front this time." Because anything short of a full spec simply comes back to screw you with a chainsaw lately.
--------------
This is a double edged sword.
I have been with my company for 5 years. When I got here, in 2000, the business units would be adjusting the project right up until production time. We had a "you start working on this, I'll go figure out what they want" method of working.
This was terrible. Everyone was nuts all the time because we'd be changing stuff at the last minute with no time to do a complete regression test to figure out what we broke by the last change.
Stuff would go into production, promptly break and we'd have emergency changes going in for a week. In fact, we had a never ending cycle of emergencies and fires.
We had no QA group, we did the QA ourselves. We had a user acceptance testing group, but they were just making sure the content was right, you could do what needed to be done with software etc.
The business complained about the bugs, and we got yelled at occasionally, but by and large, they were very happy with our work.
Fast forward to 2005.
In the last 5 years we have gotten:
1. 3 region development model... dev, qa, and prod
if you are a developer, you understand why 3 regions are necessary.
2. A dedicated QA testing group, who is really a bunch of trained programmers, who for one reason or another, decided they liked to test better than program. All are very capable programmers, and excellent testers.
3. A requirements process which requires full functional requirements, which are translated to technical requirements and set in stone before the project is allowed to have the first line coded.
Once into a project, the specs are revisited and adjusted as necessary, as reality dicates. All requirements changes are documented, and time added to the project if the changes require more time. If the users decide to add features, they go to a post implementation change queue, for once the project is done.
The net result of this has been very positive from a development perspective. We have project managers now who control the whole deal and we are following best practices across the board and doing things in accordance with PMI. Our post implementation bugs have gone from an average of 60 to 5-6 and, here's the best part, projects actually get sealed and done on schedule, where before the project wasn't allowed to close until the business was happy and done adding features(read: never, we had 4 year old projects active)
Here's the bad part. It now takes us 6 weeks, from the time the request goes in, til implementation day, to change a freaking phone number on the sites. If everything goes through process (which is now a terminatable offense to sidestep), it takes that long to get through everyone's queue.
The business is now going outside the company to a contractor for future development because "you guys don't move fast enough for us". Never mind the fact that we are hamstrung by process for the simplest of changes, but our IT organization has policies that must be followed. In fact the units are violating policy because they didn't want to wait for their chosen vendor to go through the IT vendor approval process. They just went out, got someone and are now using them.
Now we have our business going outside the company for IT work, to a company that will work without making them produce detailed specs first.
Be careful what you wish for. A detailed spec, if done correctly, generally takes longer to hammer out, then it does for the developers to code it.
Business users don't know what they want, and if you make them tell you, it takes so long that they are unwilling to use you.
They would rather have something, anything, now, than an absolutely correct and on the money product, 6 months from now.
Quality doesn't matte