If the developer is stressed
They're probably reading some rather hairy code
or
they're under excessive management pressure to get the work done
or
they're trying to use Visual Source Safe.
Microsoft is developing a new approach to splatting bugs in software before they take down production systems. It involves wiring up programmers to sensors that record brain activity, track eye movement, and test how sweaty the engineers are. If the developer is stressed – bingo, they're probably reading some rather hairy …
I well remember the feeling of disoriented terror when I read the MS recommendation that a dev group with our size of team and codebase (10 and 100k SLOC) should run a "fix" pass at least once per week, which in our case required about 18 hours running on the server hosting the drive containing the rats' nest of directories which MS nonchalantly called a database.
Happily enough Wikipedia says "The final version of the product, Visual SourceSafe 2005, retired from mainstream support on 10 July 2012 with extended support ending on 11 July 2017" so very soon it will be nothing more than a developer ghost story
You say that, and yet we're still using it... Sort of.
Every time there's a big release a quest begins to track down all the things that need to be rebuilt, most of them are in the developers hands, but a few pieces of ancient long forgotten code are still held in source safe, access to which is only allowed to a small number of individuals, with only a handful in the company who know who these individuals are.
Basically if these few people (I think there are two left) ever leave. We're fucked.
I think Micro$oft's plowed this field before, say, around April 1st......
http://blogs.technet.com/b/uktechnet/archive/2012/04/27/friday-fun-microsoft-wsyp-we-share-your-pain-project.aspx
http://www.youtube.com/watch?v=3dF-POFE30E
(I can see it now, Ballmer saying "No chairs were hurt in the making of this film.")
Paris, because she syps, er, sips Espresso, Prosecco, Pink Champagne.....
(we share your pagne? ) (sorry)
... you could train that same Bayes classifier to look at the code itself. That would probably be easier, all things considered.
Unless, of course, the goal is less to do with "spotting dodgy code" than with "reading people's minds".
Or maybe this is just thinly-disguised market research from Microsoft. Actually, that strikes me as most likely. What sorts of code do devs most like to work with, and if you give them a free choice of software, what will they pick? - now that's valuable data.
you could train that same Bayes classifier to look at the code itself
I doubt Naive Bayes would be much good for identifying suspect source-code constructs, beyond what static analysis tools already routinely catch. But it'd be interesting to experiment with more-powerful classifiers like Support Vector Machines or Maximum-Entropy Markov Machines or stacked neural networks1.
On the other hand, it's such an obvious idea that there must be a pile of existing research. I'm on vacation and feeling lazy or I'd have a look.
1The last are generally known as "Deep Learning", but that term is so stupid I avoid using it. Which is how you know I don't work for Google, where it's apparently mandatory.
If it wasn't for "Screw this, good enough!", many projects would never get done or they'd only get by done by people who don't see failure on the horizon. It's not always an Engineering problem and it's not always perfectly solvable, as most problems with obvious answers are already solved. The difference between good code and bad code is whether you clean up old problems or try to bury them.
If it wasn't for "Screw this, good enough!", many projects would never get done or they'd only get by done by people who don't see failure on the horizon
I'd like to see solid evidence to support that conclusion. In my own experience - and research I've seen appears to agree - most bad code is developed in ways that are less efficient than implementing superior alternatives would be. Copy-pasta is a great example: it's often faster to prefactor at the first sign of reuse and abstract the problem away rather than duplicating the effort.
Certainly servicing technical debt ("clean up old problems") is crucial, but it's also possible to avoid a lot of technical debt in the first place and use fewer, not more, resources in the process.
In field-tests on one team of developers:
Dilbert - Constant levels of high stress = code tagged as consistently bad
Alice - Generally low stress, with occasional peaks off the scale
Wally - Zero stress all the time = code tagged as perfect
Next generation systems all coded by Wally.
Wally has the "top right quadrant" personality beloved of some organisations' management. The "positive" type - an optimist who never sees any problems on the horizon.
The people who then dig the company out of Wally's holes have the "bottom right quadrant" personality. Natural worriers - usually denigrated as the "negative" type.
Mined Mind Message to Microsoft Majoring Minions ..... Cut down on the Coke and ACID use. IT FCUKs Head Quarters.
And Code isn't Code without Bugs Creating Opportunities and Pathways to Perfect IT ..... and thus is discovered and/or uncovered to be AIDefault Practical Feature and SMARTR Virtualisation Facility in Beta Programming of ProgramMING Projects and New Orderly World Order Systems for CHAOS..... Clouds Hosting Advanced Operating Systems for Global Operating Devices/Universal Virtual Forces/Immaculately Resourced Assets.
ROTM ..... a Second Coming Production Project for Budding Cummings?
A buddy told me that, ages ago, in Denmark, they had a guy who'd watch the people coming to work in the morning and if some of them looked to be in a bad mood or stressed, he'd send them home. The reasoning was that it was cheaper to send a dev that's feeling under the weather home (without any reduction to his pay) than to later fix whatever he messes up in such a state.
And yet most places I've worked they seemed to prefer you stressed to they eyeballs and overworked rather than productive. A macho boss was much more respected than a productive one.
But the best work I've done has been when I've been largely left to my own devices - and not doing important code when hungover or ill as per your Denmark mate.
I used to use the "Whiskey" method when trying to find any really elusive coding bug that instinct said had to be "obvious" and "stupid". If my thinking hadn't slowed down enough to spot the subtle error after the third whiskey - then it was time to sleep. It was then up to my subconscious to fathom it out for when I awoke next day.
It couldn't be used too often - as the body would soon reduce the effects of the alcohol. One particularly nasty problem was solved that way - but my boss wouldn't refund the cost of the whiskey.
top marks for the shitty parody animated GIF of exploding head from scanners.
I think that was the first ever computer 'video' I ever saw - on my amiga in 1987.
I think it took a whole disk, might have been more than one to load it and then played back the 20 or 30 frames.
It was awesome.