Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Wiring Programmers To Prevent Buggy Code

timothy posted about a month ago | from the stop-thinking-about-my-clairvoyance dept.

Bug 116

mikejuk (1801200) writes "Microsoft Researcher Andrew Begel, together with academic and industry colleagues have been trying to detect when developers are struggling as they work, in order to prevent bugs before they are introduced into code. A paper presented at the 36th International Conference on Software Engineering, reports on a study conducted with 15 professional programmers to see how well an eye-tracker, an electrodermal activity (EDA) sensor, and an electroencephalography (EEG) sensor could be used to predict whether developers would find a task difficult. Difficult tasks are potential bug generators and finding a task difficult is the programming equivalent of going to sleep at the wheel. Going beyond this initial investigation researchers now need to decide how to support developers who are finding their work difficult. What isn't known yet is how developers will react if their actions are approaching bug-potential levels and an intervention is deemed necessary. Presumably the nature of the intervention also has to be worked out. So next time you sit down at your coding station consider that in the future they may be wanting to wire you up just to make sure you aren't a source of bugs. And what could possibly be the intervention?"

cancel ×

116 comments

Sorry! There are no comments related to the filter you selected.

Can we wire Timothy to prevent duplicate posts? (3, Informative)

jeffb (2.718) (1189693) | about a month ago | (#47642749)

Re:Can we wire Timothy to prevent duplicate posts? (3, Funny)

Anonymous Coward | about a month ago | (#47642805)

Admittedly this version sounded more exciting. I was imagining failed builds resulting in electric shocks.

Disappointed to find that wasn't the case.

Re:Can we wire Timothy to prevent duplicate posts? (0)

Anonymous Coward | about a month ago | (#47642899)

Following FB and OKCupid, Dice is experimenting on their user base to see whether changes in wording will affect the responses.

Re:Can we wire Timothy to prevent duplicate posts? (0)

Anonymous Coward | about a month ago | (#47643087)

Something like this?

http://www.youtube.com/watch?v=mMuCd2ScyvU [youtube.com]

Propaganda requires reinforcement. (4, Insightful)

s.petry (762400) | about a month ago | (#47643355)

That they continue to try and blame programmers for problems that management creates should bother people. Yes, this is a rewording of the same article. The only way to sell this alchemy (I would not even call it pseudo science) is by continually bleating out the theme "programmers are baaaad and we can detect them being baaaaad".

Lets just say (though its impossible for them to do) that they can isolate every possible variable that would cause fluctuations in EEGs, heart rates, and everything else they want to track biometrically. How on earth do they plan to track and correlate that data without either knowing or directing everything you eat, drink, and touch (including shampoo, soap, and hand lotion).

Even better, how do they plan to either direct or track all of your personal interactions which can impact those same things. If they can't, then the numbers are skewed and we don't have any science, you only have biases.

Oh, I can see it now. "Monty. We know your dad died yesterday but you are performing sub par and your heart rate is elevated higher than we expect, so we are going to have to let you go. We can't have a repeat of your three days of sub par performance when your wife divorced you five years ago."

Now lets look at some of the great Microsoft Management decisions, and decide who's to blame: Programmer or Management. Lync can not copy/paste data. Do you really think a programmer didn't notice the lack of basic function and point it out? Windows 8, and in fact Microsoft's whole "One UI" strategy is management driven. Zune, was actually a decent device but management killed the program. Programmers said Win8 was not ready, Management released it (as they did with Vista, ME, countless back office products, etc..). Programmers have had fixes for security ready only to have them pulled by management for various reasons. "Can't fix that IIS back door because someone's code may break" is frigging hilarious, but how many times have we read just that from Microsoft management?

That list could get really really long, so here is the point. Why are they not hooking management up to these things and putting them under pressure instead of the programmers? Probably for the same reason I start with, which is that this is alchemy and not science.

Re: Propaganda requires reinforcement. (0)

Anonymous Coward | about a month ago | (#47643495)

Much like what education reformers have been doing to teachers in recent years.

Re:Propaganda requires reinforcement. (2)

jbolden (176878) | about a month ago | (#47643609)

Windows 8, and in fact Microsoft's whole "One UI" strategy is management driven.... Zune, was actually a decent device but management killed the program

That's not in any possible sense a bug. It is a strategic choice you disagree with. As for not releasing products when programmers say you should. I think Perl 6 provides a pretty good example of what happens when complex projects aren't disciplined with the "best version ships in 10 months".

Re: Propaganda requires reinforcement. (0)

Anonymous Coward | about a month ago | (#47644133)

I think his point is that these strategic decisions are faulty. Someone should have been zapped for Perl 6 just as much as Zune. But instead we'll monitor the coders, who are powerless to prevent those kinds of mistakes. You'll only prevent a class of mistakes that will likely be caught in review or in test, but not the kind of franchise destroying blunders that have no peer review or test.

Re: Propaganda requires reinforcement. (1)

jbolden (176878) | about a month ago | (#47644557)

Franchise destroying blunders are peer reviewed by the business press among others.

Alchemy (1)

RabidReindeer (2625839) | about a month ago | (#47645985)

Alchemy? Not even that much science. Say Astrology.

What good does it do knowing how people produce buggy code when the #1 reason for the buggy code is underqualified people being pushed under unrealistic conditions?

I, too thought "wired" as in "we apply electric shocks when they screw up". I'm sure at least 1 Dilbert cartoon already anticipated this.

Re:Can we wire Timothy to prevent duplicate posts? (2)

PPH (736903) | about a month ago | (#47642867)

100 volts for the first dupe, 200 for the second, etc.

Haven't decided on an arithmetic or geometric progresion yet

Re:Can we wire Timothy to prevent duplicate posts? (2)

war4peace (1628283) | about a month ago | (#47643075)

Fibonacci FTW.

Re: Can we wire Timothy to prevent duplicate posts (1)

jblues (1703158) | about a month ago | (#47644065)

C'mon. The only sensible choice is base 2. Things get interesting at around 128 volts and up.

Take it a step further... (5, Insightful)

hsthompson69 (1674722) | about a month ago | (#47642767)

...make sure you go back to the business guy who create the requirements being coded at the time, hook him up to an EEG, and see if he wrote a buggy spec :) ...for bonus points, put the EEG on the manager who just said they're going to measure productivity in LOC.

If we could detect stupid with an EEG, programmers would probably be the least useful people to put it on.

Not as novel as it sounds (1)

Daniel Oom (2826737) | about a month ago | (#47642931)

The procedure is just a variant of letting the programmer write a piece of code and then hook him/her up to a polygraph and interrogate her/him if the code has any bugs, and if it does, in which source file and line number....

Re:Not as novel as it sounds (2, Insightful)

Anonymous Coward | about a month ago | (#47643771)

The procedure is just a variant of letting the programmer write a piece of code and then hook him/her up to a polygraph and interrogate her/him if the code has any bugs, and if it does, in which source file and line number....

"Does this code have any bugs?"

"Yes, like all non-trivial programs, this program has bugs too."

"Where is the bug?"

"If I knew, I would have fixed the bug already. But that's not the point. There's always one more bug that haven't been found yet."

Re: Take it a step further... (1)

KramberryKoncerto (2552046) | about a month ago | (#47645229)

It won't work. This system detects when a programmer is trying very hard to deal with a difficult problem. On the other hand, a decision to use LOC as a productivity metric is more of a result of a blank head and a habit to avoid inevitable difficulties rather than to face them up front

Re:Take it a step further... (1)

Mikkeles (698461) | about a month ago | (#47645801)

"Difficult tasks are potential bug generators..."

So are easy tasks; it can be surprising how much of a bug generator is complacency.

Hi, it looks like you are writing difficult code! (4, Insightful)

danlip (737336) | about a month ago | (#47642779)

The last thing I need when I am focused of a difficult chunk of code is Clippy popping up and breaking my focus. Some tasks are just much harder than others. I think any decent coder knows when they are struggling and increases their focus or grabs someone on their team to help. Bad coders may not, but bad coders are always bad coders, and no tools will help someone who just can't get it or just doesn't care.

Re:Hi, it looks like you are writing difficult cod (0, Troll)

Anonymous Coward | about a month ago | (#47642885)

I think any decent coder knows when they are struggling and increases their focus or grabs someone on their team to help.

In my 20 years of experience in 6 different shops, you'd be called in "idiot" - wrongfully so, I might add.

Asking questions is considered a weakness of your intellect in this business - even if you are working on some social media app or website - well, advertising.

It's amazing how advertising companies want the best of the best even though their software is crap.

I'm talking about: Google, facebook, Yahoo!, and eveything coming out of Silicon Valley.

Re:Hi, it looks like you are writing difficult cod (1)

Anonymous Coward | about a month ago | (#47642919)

"finding a task difficult is the programming equivalent of going to sleep at the wheel"

Bullshit! To a programmer a difficult task is a challenge and sometime we generally crave amidst the drudgery that is routine, easy tasks. One day I am going to conduct a research study into drilling a hole in the skull of management and watching how their brains react when confronted with ethical dilemmas. Of course after the study finishes they'll be lobotomised for their own good.

Re:Hi, it looks like you are writing difficult cod (1)

Immerman (2627577) | about a month ago | (#47643191)

Hear, hear. Of course that very craving may easily mean we horde the challenge to ourselves, shunning a second opinion at the very moment it would do us the most good.

As for management brains and ethical dilemmas, why would you assume there would be a reaction? Have you seen some sort of behavioral evidence that they even notice them?

Re:Hi, it looks like you are writing difficult cod (1)

Wycliffe (116160) | about a month ago | (#47643553)

Not only are the difficult problems more fun but how will you ever advance if you are only ever given easy problems.
Yes, someone might make more mistakes when they are doing a harder problem but that is how a person learns.
Taking away the hard problems isn't the answer but maybe requiring additional peer review for hard problems but
you don't need an invasive brain monitor to find this out. Just ask the programmer. As a programmer I can easily
tell you after it's done which parts were easy, which parts were hard and which parts are more likely to have bugs.

Re:Hi, it looks like you are writing difficult cod (3, Informative)

JMJimmy (2036122) | about a month ago | (#47644219)

Honestly, I find my buggiest code is the easiest crap that I'm just not paying attention to. The moment I have a solid challenge my interest peaks and getting it singing perfectly is the only acceptable end result. It may take a few tries but it's what I thrive on. I'm my least productive and most careless on the routine pointless tasks.

Re:Hi, it looks like you are writing difficult cod (1)

Anonymous Coward | about a month ago | (#47644607)

This is just what I thought when I saw this article. Do any of the study's authors actually *do* programming? Bugs can arise in any code: hard, easy, or middling. I think that someone here is exploiting the inherently buggy grant-writing system.

Re:Hi, it looks like you are writing difficult cod (2)

matbury (3458347) | about a month ago | (#47642983)

Let's see... maybe they'll gather enough metrics on productivity and frequency of lapses in concentration and discover that the only thing that really correlates with those are the number of hours per week that they're working, previously recorded at an average of 35-40 hours per week, after which workers are no more productive but do less creative and/or innovative work. They might find out some interesting and novel details but the research into working practices is already pretty sound. It's just a pity that most executives, managers, and HR managers don't read it.

Re:Hi, it looks like you are writing difficult cod (2)

Immerman (2627577) | about a month ago | (#47643289)

Actually, as I recall the studies suggest that sustained work-weeks over the 35-40 hour threshold actually generate *negative* productivity - as in you get less total productivity out of a 60-hour week than a 40-hour week. A far worse situation than your phrasing suggests. I would actually suspect that in most situations hourly productivity starts to fall off much sooner, so that a 20-hour week would deliver more than half the productivity as a 40-hour one.

I can think of two important reasons a company (or economy) would be tempted to ignore such findings though:
1) Benefits, especially insurance. Thanks to government-mandated wage-fixing during the World War insurance has become a major part of most people's compensation packages, and those expenses will be the same regardless of time worked.
2) Wage fixing. As you reduce the hours worked you increase the number of employees needed, which gives the labor market more bargaining power. As automation caught on the normal US work week had been falling slowly but steadily in the US from ~12 hours per day to ~8, *without* a commensurate reduction in salary (i.e. accompanied by a 50% increase in hourly wages). That continued until early last century when federal regulations established 8 hours plus breaks and weekends as the norm, after which further reduction ground to a stop.

Re:Hi, it looks like you are writing difficult cod (2)

RabidReindeer (2625839) | about a month ago | (#47646007)

Or, rather than thinly disguised duckspeak, it could simply be that Management is still stuck in an 1890's industry mentaility where the longer you run the machines and the harder you run them, the more output you get and the sooner you get it.

Human creative endeavor, however, doesn't work like a hamburger grinder. It develops at its own rate, and not infrequently, any attempt to accelerate that rate will actually cause it to jam up. Rather like the old joke that if you pull on the paper as it comes out of the printer, it will print faster.

Re:Hi, it looks like you are writing difficult cod (2)

Immerman (2627577) | about a month ago | (#47643173)

On the other hand, it might be useful to have an actual resident guru or two wandering around helping out anyone having trouble. I assume you believe you're considerably better than the average programmer, so imagine you're the guru who gets notified whenever one of the code-monkeys starts having problems. If you're as good as you think and have a decade or three of experience under your belt, then I suspect that more often than not you could make a couple key suggestions that would improve the rookie's code considerably. But they're never going to actually ask for such help - that would make them look incompetent. If they suffer from inflated egos they may even resent your assistance, but the code base will benefit greatly from your intervention nonetheless.

Even among gurus, if you're working on something difficult that may be a sign that this is a section that would benefit from teaming up with another guru to for some pair programming. Obviously *you're* never going to want to do such a thing, you're the guru! But having another sharp mind on hand and less focused on the line currently being edited may still catch a lot of the subtle bugs that might otherwise slip through.

Re:Hi, it looks like you are writing difficult cod (2)

plover (150551) | about a month ago | (#47643393)

Actually, having the guru ask for help from the rookie is a good way to engage the rookie. It's pretty motivating to the FNG to be able to say "hey, I really helped the smart guy, I must be doing something right!" Pair programming is one way to put them both in that situation.

Re:Hi, it looks like you are writing difficult cod (1)

Immerman (2627577) | about a month ago | (#47643617)

That too, but I'd never suggest it to a large-egoed guru. Demand it perhaps, but a suggestion would almost certainly be a waste of air.

Re:Hi, it looks like you are writing difficult cod (1)

Anonymous Coward | about a month ago | (#47644893)

I did the guru thing at my last job. The problem with it is that you are helping everyone else who is struggling with things get their projects done, so they show visible 'progress'/'accomplishments' to management, while your manager wonders WTF you do all day (helping everyone else). Eventually you're probably laid off because you aren't adding any 'value to the organization' by having less overall projects/goals completed, even though you were integral to everyone else meeting theirs.

I remember my old boss sending out an email giving kudos to one of the junior guys for his great accomplishment helping get something critical running in a matter of hours... and some of my more senior coworkers commenting to me how there was no mention of the fact that he probably would've taken days and I did most of the work.

Two gurus with egos in check = awesomeness. APIs (2)

raymorris (2726007) | about a month ago | (#47643739)

I've been coding, and studying to improve my skills, for decades. People come to me for help and advice. With one open source project I work on, all code must be approved by at least three people. My counterpart for one module is also very experienced, and a perfectionist. Sometimes our egos collide, but when we get past that we come up with something much better than either of us started with. That's particularly good when we're working on an architecture or API that otter people will have to code to in the future.

Re:Hi, it looks like you are writing difficult cod (1)

Anonymous Coward | about a month ago | (#47643201)

In my experience the majority of bugs are not simple logical mistakes that can be seen as wrong within a limited scope. They are locally-correct code that breaks a hidden dependency resulting in a failure of a completely different part of the system.

In theory, well-designed systems with good separation of concerns make the upstream and downstream dependencies clear, so this doesn't happen (and even when it does the automated regression tests catch it). In practice, deadlines prevent code from ever achieving this state, and the resultant fragility is where most of the bugs come from. Over time, the words "just figure out what all the impacted regions of code are and test them" becomes a whole lot easier to say than it is to do, no matter how easy the coding task seems.

The solution proposed in the article won't address this problem at all.

Re:Hi, it looks like you are writing difficult cod (1)

Beck_Neard (3612467) | about a month ago | (#47644025)

Yup, that's correct. The best way to combat bugs is to write modular systems comprised of parts that can be designed and tested independently. OO was a failed attempt at doing this. But instead of moving on to better systems (like systems that have actual algebraic type systems), programming culture is still pretty much stuck on OO and languages that use it (like Java or C++).

Re:Hi, it looks like you are writing difficult cod (1)

Beck_Neard (3612467) | about a month ago | (#47643995)

There is no such thing as an inherently 'bad coder', only someone who has not yet learned how to code properly. I really think there's a huge cultural problem in programming. People view things like functional languages as 'academic' and 'too hard', but if you consider the amount of effort saved in debugging and maintaining code, they are very much labor-saving devices. And I am by no means a functional programming fanatic; I program in both conventional and functional languages each day. But people need to be constantly drilled that copy-pasting code is bad, that shotgun debugging is bad, that using higher-level languages has nothing to do with trading off 'speed vs. programmer productivity', but is fundamentally about writing correct programs instead of programs that arrive at the wrong answer quickly. There is no better way to do this than to force them to think deeply about problems.

Re:Hi, it looks like you are writing difficult cod (2)

RabidReindeer (2625839) | about a month ago | (#47646027)

There are, in fact, inherently bad coders. Coding is just like anything else. Some people have the apitude, some do not.

I am an inherently bad bookkeeper, since I work by scanning the big picture and integrating it, and a meticulous line-by-line process will only result in my dropping lines.

I am an inherently bad sales person, because it's actually painful to me to approach people, and my persuasive skills are probably measured in negative numbers.

But I can execute prodigies in software coding without even straining.

This idea that anybody can do anything (except CEOs, who therefore require special levels of compensation) really needs to die. We're not all interchangeable cogs, no matter how hard you flog us.

No silver bullet (1)

jnana (519059) | about a month ago | (#47642791)

For a given developer, even a very skilled developer, some tasks will be difficult even if the developer is working in an optimal state and there is no "intervention" that could change that. The discussion doesn't seem to acknowledge that point or discuss how they would distinguish between the events they probably care about and could do something about (developer is experiencing great difficulty because they are hungover or drowsy after lunch), and those they can't do anything about (developer is experiencing great difficulty because they are trying to debug a subtle concurrency bug that they're having trouble even reproducing).

Re: No silver bullet (4, Insightful)

Rhaban (987410) | about a month ago | (#47642917)

Difficulty act as a motivator, and helps developpers to focus. Most bugs I've seen (or caused) are on easy, boring tasks.

Re: No silver bullet (2)

jnana (519059) | about a month ago | (#47642971)

That's a good point, and consistent with what I meant but didn't explain very well. Maybe "struggling" or some other word is better than "difficulty". The point being that the article talks about some symptoms that they're trying to identify, but they fail to discuss that those symptoms can all occur under normal circumstances when there is nothing that could/should be done (e.g., it's a good difficulty that encourages focus and the developer is working on something that is intrinsically difficult, or it's a bad difficulty and the developer is struggling on something that isn't very difficult because they're hungover or distracted because they had a terrible date last night).

Re: No silver bullet (2)

Immerman (2627577) | about a month ago | (#47643339)

A good question would be what exactly do they mean by "difficulty" in the study? If they're simply detecting increased stress or focus then you may be right; however, if they actually found some neurological/physiological response that correlates well with "increased chance of introducing a bug" then they would be zeroing in on exactly the right kind of "difficulty" that would suggest intervention.

I would suggest that, even if they're detecting you working "legitimately difficult code", if the intervention were to team up with someone at least as competent as yourself for the difficult part, then that could very well be a productive allocation of resources.

That is so going to backfire (0)

Anonymous Coward | about a month ago | (#47642807)

If tackling difficult problems will result in extra work, or worse, extra scrutiny, then programmers will find ways to avoid difficult problems.

Re:That is so going to backfire (1)

JustOK (667959) | about a month ago | (#47642975)

I think emacs has a macro for that

Re:That is so going to backfire (1)

Immerman (2627577) | about a month ago | (#47643345)

Can't be bothered to look up the obligatory XKCD but
Mission. Fucking. Accomplished.

If you're tasked with writing code to do X, and you find a way to do so without actually tackling any difficult problems head on, then where's the problem?

Breaking things is how we learn (3, Insightful)

neiras (723124) | about a month ago | (#47642819)

Doing hard or unfamiliar tasks is one way we improve and grow. Mistakes improve our understanding of a domain.

Flagging code for extra review based on "struggle detection" *might* be useful. Sadly, we all know that we'd end up with clueless management punishing or even firing good people because they were stretching to meet a goal.

Re:Breaking things is how we learn (0)

Anonymous Coward | about a month ago | (#47642935)

Who says you should be able to break things on company time, on production code?

No sir, you are hired to just write the damn code, not learn things.

Re:Breaking things is how we learn (1)

Immerman (2627577) | about a month ago | (#47643357)

Great, then go ahead and hire somebody at twice my salary who already knows how to to do all this $#@! instead. You've got to pay for quality my friend, and we both know you're far too cheap to do so.

Re:Breaking things is how we learn (1)

gnoshi (314933) | about a month ago | (#47644413)

Indeed. Detection of 'struggling' (or should we call it 'cognitive challenge' in this context) provides an excellent opportunity to have another developer head over and for them both to work on the problem, reducing the likelihood of bugs and design errors and potentially providing skills improvement for both people which the company then benefits from.

If someone is consistently struggling when working on basic tasks, it may be that the person isn't suitable for the role (and some people really aren't) but if you never provide challenges you'll explode the first time a really big challenge arises.

Low-hanging fruit (0)

oldhack (1037484) | about a month ago | (#47642827)

Taze him when perl interpreter starts.

Premise flawed? (4, Interesting)

Anonymous Coward | about a month ago | (#47642829)

It seems to me that when I find code very easy is when it is probably wrong. When it is more difficult it gets more concentration and analysis. When it seems "this is dead simple" - that's probably when I missed something (maybe some edge cases not being taken into account or whatever).

Re:Premise flawed? (2)

shoor (33382) | about a month ago | (#47643131)

NOW, after my moderator points have expired, somebody posts something I would want to mod up!

From my own experience, when I had really difficult, gnarly problems, the code came out really clean at the end. The bugs came when I was least expecting them with stuff that should have been a piece of cake.

I think it might be a bit like what somebody once told me about private airplane pilots. Statistically, accidents didn't happen the most when people were novices, but after a certain number of flight hours. I don't remember exactly what they were. Actually there were 2 peaks, for the sake of argument I'll say that one was at 2000 hours and one at 8000 hours flight time. An interesting phenomenon.

Get rid of the distractions (4, Insightful)

petes_PoV (912422) | about a month ago | (#47642831)

Bugs come when people lose track of the big picture. When they lose concentration and focus - just like when jugglers drop the ball.

If you want to reduce the incidence of avoidable bugs, get rid of the distractions. Ones such as other people interrupting, phones ringing, asynchronous non job-related alerts going off (fire alarms excepted) and the administrivia associated with the programming environment. Maybe even unplug them from their "entertainment", too.

There will always be non-avoidable bugs: ones where the programmer is simply making a mistake, isn't up to the task in hand or has been given a bad brief or wrong information.

Re:Get rid of the distractions (1)

raarts (5057) | about a month ago | (#47643965)

This. Totally agree on this one. When you make context switches (sales/pm asking a 'quick question'), and you continue programming before the full context is restored. That's where bugs happen. That has been my experience in 35 years of coding. No distractions: less bugs. Mod up please.

Re:Get rid of the distractions (2)

allcoolnameswheretak (1102727) | about a month ago | (#47645653)

There will always be non-avoidable bugs

That's what I was thinking. Some bugs are practically impossible to avoid, because it is almost impossible for a single programmer to have the entirety of a software system in his head, with all possible cases and side effects. Without complete knowledge of a system it's impossible to know the perfect solutions.
At some point it's up to testing and quality control to take responsibility and weight off the programmers shoulders.

Not all bugs are in difficult code (3, Insightful)

UrsaMajor987 (3604759) | about a month ago | (#47642833)

Just as easy to put a bug in simple code while you are blissed out on something else.

Yes (4, Insightful)

mveloso (325617) | about a month ago | (#47643009)

Bugs mostly come from when you're not paying attention, or you forgot something.

If you've doing difficult coding then writing code is the last thing you doing be doing. By the time you get to writing code it shouldn't be difficult anymore.

Re:Not all bugs are in difficult code (1)

roman_mir (125474) | about a month ago | (#47643165)

Right, of-course the biggest source of bugs in the code is fairly complex business logic and coupling of data structures / models between processing components, where limitations on data that one component requires and processes are different from limitations on same/similar data processed by other components. Really in order to avoid bugs we have to have full awareness of all business logic in every step in programming, which cannot be done in large enough projects where more than one person is working on a project and project takes more time than just a few days of work.

As to how to reduce number of bugs in simple code, I say write code generators that generate simple code if that type of code is used over and over again across the application, that's my approach [slashdot.org] , but YMMV.

they think they know what they're doing. Security (1)

raymorris (2726007) | about a month ago | (#47643835)

Many bugs are of course a simple "oops"or "l forgot that. I knew, and it slipped my mind".

Another very large portion are cases where they think they know exactly what they are doing, but in fact they are in way over their head. Many, many times I've pointed out a bug and had the developer argue with me, even after I showed them the problem. I have to actually crash/exploit their application before they change it, while still arguing "an attacker would never think of that." Dude, the attacker doesn't even have to THINK of it, that attack is automatically attempted by his web crawler because it's so obvious and so common.

Or:
Hmm, this page takes 40 seconds to load. Would it work better to do $long_operation OUTSIDThe loop?
No, no way that would make a difference.
10 minutes later ...
Here, I tried it outside the loop. It runs 400 times faster.

That one good thing is that each developer will only argue with me once or twice. When I make a suggestion, I politely ask about trying it a different way. When you argue, I prove clearly how incredibly wrong you are. It's easier to just accept that when I say something, I'm probably right. That's actually NOT because I'm necessarily right more often than anyone else. I've just learned to keep my mouth shut if I don't know. I only say something when I know it to be true.

It's kind of funny that I've gotten a reputation like I know everything, like I can solve any problem. In fact, 95% of the time I have nothing intelligent to say. So I don't say anything. It's a good way to avoid saying anything stupid.

So.... (1)

vomitology (2780489) | about a month ago | (#47642835)

The source of most mistakes (coding or otherwise) beyond sheer lack of knowledge is usually not being focused on the task at hand. So to help you focus on the keyboard, we'll be hooking you up to basically what amounts to a modified lie detector! It's brilliant!

Completely ignores bad specs... (4, Insightful)

linebackn (131821) | about a month ago | (#47642845)

consider that in the future they may be wanting to wire you up just to make sure you aren't a source of bugs

While completely ignoring that the specs handed down from the higher-ups are gibberish, contradictory, and physically impossible garbage. But, you know, that is not a possible source of bugs now is it?

Someone should first wire up management to zap them every time they get an idea for a "brilliant" addition.

Re:Completely ignores bad specs... (3, Informative)

janoc (699997) | about a month ago | (#47642985)

Mod parent up, please, this is spot on. You do this sort of "research" when you need to justify that the expensive toys you bought are actually used for something.

When I have seen the list of sensors they are sticking on the user, this has nothing to do with anything even remotely practical (have you seen a typical EEG sensor cap or eye tracker?). All the researchers are doing is running the test subject through a battery of experiments and classifying few measured values, based on some correlations - in an artificial setting.

This completely ignores the complexity of the problem - such as the biggest problem being constant interruptions from managers and colleagues, distractions in a noisy cubicle, bad specs, poor/inadequate tools, etc. What they are proposing is basically a Clippy on steroids with a ton of expensive sensors. Such papers are published a dime a dozen (google "assistive agents" for example), not sure why exactly this one got picked out as somehow interesting.

Re:Completely ignores bad specs... (2)

dotancohen (1015143) | about a month ago | (#47642999)

Someone should first wire up management to zap them every time they get an idea for a "brilliant" addition.

I had this at work today. Somebody arbitrarily decided to store 3 months worth of hourly MySQL backups. Never mind that they were being stored on the MySQL server itself (some backup!) but each backup was over 1 GiB - that is 30 GiB per day. 30 * 90 = 2700 GiB on a server with a 2 TiB hard drive that was already half full.

I enjoyed cleaning up that mess, but I as usual people with no technical knowledge continue to make technical decisions.

Re:Completely ignores bad specs... (0)

Anonymous Coward | about a month ago | (#47643055)

It seems you've been burned here. I think you made the classic white boy mistake.... you fucked with Medusa. Ain't nobody got to fuck with Medusa but they get all uppity and the next thing you know... their bitch ass is turned to STONE!

Re:Completely ignores bad specs... (2)

kwikrick (755625) | about a month ago | (#47643151)

I agree.

The source of most bugs is pressure. Time and money. Which results in management making bad choices.

In early stages of software development, the specs and design documens are almost always too abstract and insufficiently detailed, but development is started anyway, due to time/money constraints. This is not nessecarily a bad thing, if you follow some iterative or agile product development process, but it means some big refactoring and probably a redesign will be needed on the way. Especially when users have played around with early releases, and lots of change requests and missing features come in. Those are usually very specific, not application wide, so that changes are made haphazzerdly, all over the code. The result is that user experience becomes inconsistent, and the code gets bloated with lots of exceptions all over the place. It becomes almost impossible for the programmer to foresee all the consequences of any code changes he makes. Despite static code analysis, unit testing, funcional testing, automated testing, etc., with each new feature or bug fix, some other part of the application falls over. A good programmer will say: well this is going to take some refactoring and the analysist/users/architects should make some decisions about general design rules and specs, so we have to do this only once. But there is never time for refactoring, and the specs and designs never get updated. There is only time for new features, hacked in as quickly as possible. At the end of the development cycle, there is only time for bug fixes, but with every fix, two new bugs are introduced.

And so managment asks: can you explain where all those bugs come from? But they never like the answer.

This, by the way, makes my blood boil and sometimes steam comes out of my ears. So those EDA and EEG sensors will probably be all the way in the red, and management will think that i've ran into a complicated problem. Which is true, but the problem is not the software, it's managerment.

Re:Completely ignores bad specs... (0)

Anonymous Coward | about a month ago | (#47643447)

What is this "specs" thing that you talk about?

Intervention? (2, Interesting)

Anonymous Coward | about a month ago | (#47642859)

What isn’t known yet is how developers will react if their actions are approaching bug-potential levels and an intervention is deemed necessary.

Intervention - you get fired.

In software development/IT/software "engineering" asking questions is considered to be a sign of stupidity. So, you better search and search the internet. Spend all your time learning the code - and KEEP your deadline.

We need to get a job done. Spinning one's wheels for hours, days, or whatever over something that can be answered in 5 minutes is idiotic, but that's what you gotta do or you're an idiot. I know, I have been called an idiot because I asked questions. I try to be efficient - reading is slow - POINT me to the area. But Nooooo! Gotta bust your balls!

When one hears after asking a question, "If you asked that then you don't belong here!!"

Well. We didn't get much done.

The PHBs fired us and hired H1-Bs - who I had to explain what those asterisks mean in C code.

Whatever, guys.

I walk into an interview and I'm told, "Tell me what the layers are for a network stack."

And I ask, "Well, whose opinion of what a network stack should be? Tanenbaum's? Afterall, it's just his opinion."

Blank stare.

I can't remember; it's been years since I had to memorize that. I say, "If it is really important, I can memorize all of that again."

I then ask, "Why, are you writing your own stack? I've done that."

"No."

Alrighty then.

Feedback from recruiter: "You do not have the skills."

You know, there are a bunch of people who are looking for work - people who know their stuff - and yet, they are dismissed.

And I see companies who say they cannot get qualified people - for their social network nonsense or whatever software.

Every bright kid I know who is good at math and science, I just say, "The only worthwhile STEM profession is the 'M'. Stay away from engineering, software, and tech. Medical."

Everyone in my family who is in medical from nurses to doctors have none of the problems we have in tech - none.

Re:Intervention? (1)

mjwalshe (1680392) | about a month ago | (#47642881)

network stack is easy APSTNDP All, People ,Seem, To, Need ,Data, Processing - or do you mean the hacked out in an afternoon by grad students whist high TCP/IP stack?

Tricky network q's are what is the 8th layer and MIDI part of the presentation layer or not

Re:Intervention? (0)

Anonymous Coward | about a month ago | (#47646077)

I don't see an I in there for IP layer.

Are you by chance talking about the OSI Protocol, used in pretty close to zero places on this planet, because the specification is so complex and has so many optional parts, that even when people tried to use it, they could never get two components from different vendors to talk together?

I went to school back when that crap was still taught, and TCP/IP was something fancy used by universities over in America, and even though they spent months trying to teach us about the OSI protocol stack, I learned more in an hour about TCP/IP when I got a sysadmin job. Because the TCP/IP stack is so much simpler and more logical, and it actually corresponds to the real world.

Re:Intervention? (0)

Anonymous Coward | about a month ago | (#47642893)

What do those asterisks mean in C? Why can't I just write it in javascript?

Wiring eh .... (1)

Anonymous Coward | about a month ago | (#47642877)

A guy at work has been esposing hooking Jenkins up to an electric shock generator ... break the build ... BBBZZZZZTTTTT!!!!

can management crawl further up your ass? (0)

Anonymous Coward | about a month ago | (#47642887)

if you have any aptitude for other STEM professions please exit being a "programmer" now and fill the management coffee pot full of imodium before leaving...

what a bunch of dumbasses!

what next, are they prescribe drugs to be injected into you as your work?

False Premise (2)

visualight (468005) | about a month ago | (#47642889)

Difficult tasks are potential bug generators and finding a task difficult is the programming equivalent of going to sleep at the wheel....
( hmm. Easy tasks are potential bug generators and finding a task easy is the programming equivalent of going to sleep at the wheel... huh. that works too.)
^^
Like all the other sane people I stopped reading at that point.
The real reason for doing this is that someone has invested a lot of time and effort in the technology used for this (and has a lab) , and this idea was the best one he came up with.

Re:False Premise (2)

janoc (699997) | about a month ago | (#47642997)

Mod parent up, please, this is spot on. You do this sort of "research" when you need to justify that the expensive toys you bought are actually used for something.

When I have seen the list of sensors they are sticking on the user, this has nothing to do with anything even remotely practical (have you seen a typical EEG sensor cap or eye tracker?). All the researchers are doing is running the test subject through a battery of experiments and classifying few measured values, based on some correlations - in an artificial setting.

This completely ignores the complexity of the problem - such as the biggest problem being constant interruptions from managers and colleagues, distractions in a noisy cubicle, bad specs, poor/inadequate tools, and many other issues. What they are proposing is basically a Clippy on steroids with a ton of expensive sensors. Such papers are published a dime a dozen (google "assistive agents" for example), not sure why exactly this one got picked out as somehow interesting.

Re:False Premise (1)

Anonymous Coward | about a month ago | (#47643005)

Exactly, on large complicated (as in many featured) codebases, bugs are more often introduced when the programmer is entirely unaware that her simple fix for the scenario she has been asked to correct actually breaks the code under other less common scenarios. ie happy ignorance is more dangerous than stressed difficulty - at least in that case a sensible programmer would typically ask for help.

Re:False Premise (0)

Anonymous Coward | about a month ago | (#47643239)

I know when I raced cars on a track, I tended to nod off because it was much more difficult than my usual leisurely commute. Lots of F1 drivers keep a pillow in blankie in the car just in case.

Fundamentals (1)

Carcass666 (539381) | about a month ago | (#47642909)

In the B2B space, a lot of code gets written to wire up databases to front-ends of some time, and most of the time it involves an RDBMS. Unfortunately, with all the reliance upon ORM frameworks, developers often can't write or diagnose decent SQL to save their lives. We have a good chunk of Oracle code written by a large integrator, and there are innumerable cursors, one after the other, where a simple SQL join would have done the job much more easily. In Microsoft land, people are leaning way too much on LINQ, with transaction integrity and locking effects as distant afterthoughts.

On the front-end, things are even more chaotic. Whatever Javascript or UI framework you are using, there is always something newer, more "efficient" and inevitably more buggy if you don't take the time to learn to use it properly. Something like Angular is very cool, but very different, and there is a lot of front-end time to learn to use it properly in a production site. Unfortunately, in B2B space, we don't always get the time we would like to learn how to use the latest "hotness".

Abstraction for abstraction's sake is a killer too. Templates, abstraction and such re-use techniques get way overused. Yeah, it might be nice if every single block of code was reusable, and we could arbitrarily stub in test data for every possible call, but the complexity isn't always worth it. Setting up three levels of abstraction to make a class library call that was already abstracted accomplishes nothing. People that code this way never had to worry about stack or heap.

Maybe I'm old, maybe I'm yelling "get off my lawn", but I truly believe that, for especially internal, B2B applications, a focus on fundamentals would make life a little easier to manage.

Want better code? (1)

QuietLagoon (813062) | about a month ago | (#47642933)

Simple. Keep the developers happy [peerj.com] .

.

The problem with Microsoft's approach in TFA, is akin to "when all you have is a hammer, everything looks like a nail".

It is actually a lot better to solve the actual root problem, than trying to find and treat symptoms.

Good premise, bad reporting? (3, Interesting)

Chelloveck (14643) | about a month ago | (#47642957)

The story has a good premise: Can we measure the programmer's emotional and cognitive states to predict when they're more likely to produce buggy code? That's a fair question. Where it loses it is when it jumps from that to the assumption that difficulty (and thus concentration) is the mental state in which bugs are produced. Hopefully that was just a case of the reporter missing the point.

Moronic (1)

StormReaver (59959) | about a month ago | (#47642967)

Difficult tasks are potential bug generators and finding a task difficult is the programming equivalent of going to sleep at the wheel.

This is moronic, at best. It's the easy things that are the equivalent of sleeping at the wheel. The hard stuff makes us stop and think. I always spend much more effort analyzing hard problems, and breaking them down into manageable chunks, than I do when I'm on cruise control implementing the simple stuff.

Who thinks up this crap?

Re:Moronic (1)

Immerman (2627577) | about a month ago | (#47643409)

Perhaps we should fix it:

Making ungrounded assumptions about the causes of errors in someone else's field of expertise is the intellectual equivalent of going to sleep at the wheel

Wha? (1)

cascadingstylesheet (140919) | about a month ago | (#47643073)

finding a task difficult is the programming equivalent of going to sleep at the wheel.

Say what?

Finding a task difficult is a chance to learn something new. Finding a task difficult is a chance to flex your mental muscles.

Re:Wha? (1)

freeze128 (544774) | about a month ago | (#47643135)

Right. It's finding a task IMPOSSIBLE that will kill you.

Struggling is a good thing (0)

Anonymous Coward | about a month ago | (#47643133)

When I struggle, I usually am getting a deeper grasp of what I'm trying to do, and write better code as a result of deeper insights.

Good luck with that my friend (1)

NotSoHeavyD3 (1400425) | about a month ago | (#47643227)

It sounds great in theory but I've worked places recently where developers decided they didn't need to do code reviews or follow coding standards or use source control

wrong target (1)

knightghost (861069) | about a month ago | (#47643257)

I believe that a far more productive idea would be to apply strong electroshock therapy to managers that insist on unreasonable due dates since that is the single greatest cause of software bugs (cutting corners to meet an arbitrary date).

Not quite right (1)

mysidia (191772) | about a month ago | (#47643299)

There is no evidence to suggest most bugs come from tasks developers find difficulty. Which is implying that "shotgun troubleshooting" is causing bugs ---- this is a real potential phenomena, but I believe it is one primarily suffered by novice programs.

Competent programmers are likely to seek help and be extra careful about it when they find something difficult, which suggests more testing and more careful coding and quicker discovery of bugs with the thing they are finding difficult..

What's more likely happening is the bugs are occuring When programmers are not careful, because the task is difficult or complex, but the developer is overly complacent or fails to recognize the difficulty, or they just make a silly careless mistake, because they perceive the task so easy, they are not being so cautious, and they are kind of rushing through it --- furthemore, when they look back at the code, they may see it perfectly correct and not recognize that there could be an error at all.

"It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so."
- Mark Twain

Wrong audience, do this for *executives* (1)

echtertyp (1094605) | about a month ago | (#47643315)

Bugs can be isolated with unit tests, and / or fixed in future releases. Executives who are over their heads, however, make decisions that cannot be unf#cked and destroy thousands of lives. You'll get much more bang for your buck by wiring executives and board members up to monitor their alertness and comprehension. With one headset on one executive this could have been prevented: "Metro UI everywhere? Uh...ummm....so tired, so many words, I want to go golfing so bad...sure, sounds good, Metro UI everywhere, do I sign at the bottom?"

Easy Peasy (2)

bobmajdakjr (2484288) | about a month ago | (#47643401)

For me it is not the dificult things that cause bugs, but rather the shit that was so easy it didn't need thinking - things that were obviously too simple to fuck up.

How about this. (3, Insightful)

aepervius (535155) | about a month ago | (#47643417)

Hire older programmer which learned a lot and do less buggy code in average, rather than every few year a generation of youngling which suffer from NIH and must relearn everything the older knew, just because you can underpay them for long hours (or even instead of outsourcing). Yeah I know, controversial shit.

Re:How about this. (0)

Anonymous Coward | about a month ago | (#47645043)

It's very hard to hire good programmers, young or old. Young folks at least got inexperience going for them, but if a `seasoned' programmer can't figure out rudimentary basis, especially those they claimed to have worked on in the past, then they don't get hired.

How about people who can't even spell? (0)

Anonymous Coward | about a month ago | (#47645335)

How about people who can't even spell? I bet you think you are hot shit at your job.

I'm an old average programmer. Slow, thorough, methodical, and I don't put up with shit. I hate problems, I organize my work and coding to reduce them. No one will hire me, so when their projects crash and burn I just laugh. What else can I do?

This will be GREAT! (0)

Anonymous Coward | about a month ago | (#47643449)

Finally, a tool to convince the PHBs out there what really causes bugs!

This ought to prove to them that bugs occur when the programmer is interrupted. Whenever the phone rings, the programmer's eyes leave the screen. Their blood pressure goes up. Their palms itch with the urge to choke someone. Surely the bug count will go up as a result of the disruptions, and detectable behaviors will be recorded that can correlate to the bugs. The problem will be in recording when the distractions occur, as I don't see the PHB or distracting co-workers being hooked up to the recorders at the same time.

Still, assume the following. Programmer is coding away, happily in the groove. Eyes abruptly leave the screen for 30 seconds. Bug count goes up consistently over the next half hour to an hour. In other situations, when the programmer finishes a section of code and eyes leave the screen, bug count doesn't spike after the programmer returns to coding. Shouldn't be too hard to conclude that a major source of bugs is interrupting the programmer's train of thought, right?

Re:This will be GREAT! (1)

captjc (453680) | about a month ago | (#47645833)

Knowing some of the managers I have met, they would call you up on the phone, multiple times a day and if you'd answer, "HOW DARE YOU ANSWER THE PHONE!? DON'T YOU KNOW THAT THAT CAUSES BUGS!?" However, if you ignore the calls, you will get a face to face meeting demanding why you are avoiding them.

Managers, can't work with them, can't get paid without them!

test it on (1)

mjwalshe (1680392) | about a month ago | (#47643473)

Judges and politicians so they get an electric shock if they fall asleep at work :-)

Turing, Goedel, ... are laughing. (0)

Anonymous Coward | about a month ago | (#47643527)

so they invented a system to detect/predict bugs. transform the problem. you can apply it to the actual problem, so why wire the developers? sound like bullshit?

Another HR filter? (0)

Anonymous Coward | about a month ago | (#47643751)

Having worked with some brilliant coders over the years, it really sounds like they want to filter for the programming equivalent of politicians -- people who are skilled at lying with a straight face and faux sincerity. Maybe we really need to go back to Cobol for business rules and leave the exotic stuff to systems jocks? But seriously, the worse bugs I have ever seen were at the interaction of multiple bits of code -- like race conditions or timing problems where the line by line stuff looked reasonable but when it interacted with other modules and the operating system was problematic, to say the least. So I really don't see how evaluating whether the coders hands were shaking is going to prevent stuff like this? Or perhaps it explains why weird and exotic problems are more the norm than ever?

Wiring? (1)

Livius (318358) | about a month ago | (#47643899)

Should we tell whoever wrote the headline what 'wiring' actually means?

For me it's reversed (1)

Rashdot (845549) | about a month ago | (#47644299)

Years ago I discovered that I used to slow down and struggle with simple things, soon after making a mistake (a bug) that I obviously missed. So I learned to go back and review my most recent code whenever I sensed that I began struggling. It appears that in those cases I subconsciously registered the mistakes. Of course you can also introduce bugs while happily coding along, but whenever you falter for no apparent reason, just review your most recent code for mistakes.

Think defensively (1)

evil_aaronm (671521) | about a month ago | (#47644985)

Think in terms of "How might this break?", and further, "What could possibly go wrong if it did break?" Then, plug those leaks before they happen. The problem is people - not just programmers - lack imagination to consider all the possible points of failure, or any points of failure, and just do shit based on the assumption that bad stuff will not happen. Do we have to consider solar flares flipping bits on a platter, causing incorrect reads? Maybe not for every step of the operation. But, dammit, when we have strnlen() available, for very little extra cost, don't use strlen() on the assumption that the input field won't be too long, anyway.

I heard that microsoft already did this in 2006 (0)

Anonymous Coward | about a month ago | (#47645821)

http://m.youtube.com/watch?v=D28FkfJiauk

It was not during writing code but to give feedback about bugs.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>