Slashdot Mirror
Wiring Programmers To Prevent Buggy Code
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?"
Seems like we just covered this...
...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.
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.
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).
If tackling difficult problems will result in extra work, or worse, extra scrutiny, then programmers will find ways to avoid difficult problems.
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.
Taze him when perl interpreter starts.
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
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).
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.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
Just as easy to put a bug in simple code while you are blissed out on something else.
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!
~Knowledge is knowing that a tomato is a fruit, but Wisdom is knowing not to put it in a fruit salad.
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.
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.
A guy at work has been esposing hooking Jenkins up to an electric shock generator ... break the build ... BBBZZZZZTTTTT!!!!
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.
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?
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.
Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
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.
"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.
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....
.
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.
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.
Chelloveck
I give up on debugging. From now on, SIGSEGV is a feature.
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?
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.
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.
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.
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.
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.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
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?
--- Most topics have many sides worth arguing, allow me to take one opposite you.
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.
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
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
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).
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.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
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
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?"
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.
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
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.
John
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.
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.
C. Sagan : A demon haunted world:
http://www.amazon.com/gp/product/0345409469/
visit randi.org
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?
Judges and politicians so they get an electric shock if they fall asleep at work :-)
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?
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.
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.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
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.
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?
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.
Should we tell whoever wrote the headline what 'wiring' actually means?
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.
A fool and his hard drive are soon parted.
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++).
A fool and his hard drive are soon parted.
C'mon. The only sensible choice is base 2. Things get interesting at around 128 volts and up.
If it acquires resources on instantiation like a duck, then its a shared_ptr<Duck>
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.
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.
This is not the sig you're looking for.
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.
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.
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.
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?
http://m.youtube.com/watch?v=D28FkfJiauk
It was not during writing code but to give feedback about bugs.
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.
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.
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.
Personally I didn't find a correlation between how I struggle writing code and the number of bugs I produce. I'm not sure about why but it's probably because I'm more careful with hard problems.
Anyways, I think the worst bug-generator is code that is hard to test, or not tested enough because of time constraints or poor management. This can explain the correlation : complex code (lots of inputs, lots of steps) tends to make programmers struggle and is hard to test. Also, programmers having a hard time tends to drive the project over budget, and when this happen, testing is commonly sacrified in a misguided attempt to recoup the goals.
I think that if we see developers struggling, instead of trying to "improve" the developers (the hard problem they are solving right now is actually what makes them better), it's better prepare to ramp up the testing budget, and maybe do a bit or code refactoring.
Seeing how you ill-advice people with easily disproven falsehoods http://it.slashdot.org/comment...
Your post history shows you ill-advise & are easily disproven for stating falsehoods http://it.slashdot.org/comment...
"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." - by raymorris (2726007) on Sunday August 10, 2014 @06:20PM (#47643835)
You're proven incredibly wrong for stating falsehoods here http://slashdot.org/comments.p... and funny how you shut up in this exchange here calling others here spammers then (which you post history clearly illustrates also) when facts by the truckload shot you down here http://it.slashdot.org/comment... funny what you said isn't true in the 1st link above and your reputation is that you don't know too much from those links and stated things that are not truth raymorris.
Same here. Usually the coding mistakes occur in the easiest code, and are usually the easiest to detect and fix. The hard and undetected bugs are the ones that are the result of multiple pieces of code interacting in unexpected ways, easy, medium or hard at the individual code chunk level doesn't really matter.
The other source I have found is leaving unspecified paths open to users. You think that you don't have to prevent a user from doing something because it should work. It is actually more effort to prevent that use case. Then, you get bit in the ass because the user expects a different behavior, its not tested very well since it is unspecified, and often no one even really made a conscious choice to "add" the behavior which has effectively become a feature which now needs to be supported.
I have seen many books on software development that say that a significant part of a senior developer's job is supposed to be teaching, thereby increasing the overall team's productivity. Of course what an MBA would say is that the senior developer is not doing enough programming and direct the senior developer to stop helping others to the detriment of the team.
...could eliminated by removing copy and paste. Most of my bugs seem to happen when a block of code is not quite DRY-able, I copy-paste-modify the block, and then miss some small detail. (Of course, eliminating copy and paste would also reduce my coding speed by about 90%, so I guess it all evens out.)
"The wisdom of the Patriarchs was that they *knew* they were fools." --Master Foo
1. Programmer hooked up to EEG, EDA and other sensors.
2. Office flooded by "We are the Borg, you will be assimilated" posters.
3. Programmer finds API for EEG.
4. Sensors discarded - "For God's sake, Jim, at no point was the sensor intended to measure THAT! No, just turn it off before the CDC arrives. I'm serious, Jim! No, don't bring that thing anywhere near me!"
Take your pseudo-political bs elsewhere, I am not talking about being 'interchangeable cogs' at all. Sure, not everyone has the smarts to be a coder. That's painfully obvious. But if someone has the smarts to be able to write code that works - even if it is sloppy, horrible, and badly-designed (what you would typically describe as 'bad coding'), then they can be trained to write better code.
If someone sucks at the absolute basics and can't even write a loop without help, then you should obviously kick them out.
A fool and his hard drive are soon parted.