Devs are SHEEP. Which is good when the leader writes secure code Programmers with security chops are seen as more productive and influential workers whom other coders strive to emulate, according to security researchers from North Carolina State University and Microsoft Research. A sextet of security researchers has produced a trio of studies on the topic, finding that programmers are …
This post has been deleted by its author
Programmers with security chops are seen as more productive and influential workers who other coders strive to emulate, according to security researchers from North Carolina State University and Microsoft Research.
The problem here is the same issue that inflicts itself upon almost the entire IT industry: Ego.
I have never yet met a cowboy developer who could recognise that they were A) a coyboy, and B) a problem. I have, however, worked with a lot of mid-range devs who drank their own Kool-aid and thought they were the best developer in the team/company/country.
After 20 years professional experience, constant skills refresh (Thanks PluralSight & Channel9), some professional certs, and a couple of degrees, I think I'm a reasonable developer. I'm certainly not the best developer I've ever worked with, not even in my personal top 5. I get very tired of fixing crap rolled out by devs with five minutes experience, using tools with a shelf life of an egg sandwich, just because they read about it on someones bogcast the night before and figured it might be fun to try.
Secure software may never come about, no matter how much effort we make. It absolutely will not happen though, without an industry regulator to enforce standards of skills and ongoing development of those allowed to work in the industry - something akin to the BMA.
I have never yet met a cowboy developer who could recognise that they were A) a coyboy, and B) a problem
That's the Dunning–Kruger effect. It's very common in this line of work :-(
I get very tired of fixing crap rolled out by devs with five minutes experience, using tools with a shelf life of an egg sandwich
Tools are a small piece of the problem; you can produce good code with next to no tools, and you can produce utter shite with the best tools in the business. It's more about intent: does the coder really care about producing something of value, or does he just want to bash off the Kanban ticket and tell Management that he's "productive"?
I worked with a guy not so long ago who refused to use any sort of static code analysis tools, then complaines when his code failed review. Frequently, it wouldn't even compile... But the problem was actually much deeper - his management was equally incompetent; his manager once expressed surprise that you *could* fail code review.
And therein lies the problem: until you get management that is both competent and willing to do the job properly, you're going to get people producing crap - it's seen as "quick", so it's "productive", and the problems down the line never seem to matter. But, as I've said so often before, Management seems already to have been captured, and the only way to make it into the ranks of these decision-makers[1] is to become one of them, thus precluding the possibility of anything getting fixed...
Vic.
[1] That's assuming you wanted to do so; I've avoided management for most of my career. I became a manager in one job - I hated it, and I was crap at it.
Vic,
It wasn't me btw, on a related note I have pondered the same, funnily enough the f'wits (in my situation) who replied didn't come up with a terribly coherent response...
Plus some that did reply were hiding behind the cowards' curtain, which I still don't understand!
Thanks for the link, cognitive biases, and there relation to creativity/problem solving is one of my fave subjects.
Have one on me!
Cheers,
Jay
Cheers,
Jay
Just a thought : if I'm not mistaken, El Reg does not count votes on your posts when they're anonymous.
So, by trolling you anonymously, any downvotes they garner are not put to their total. Upvotes either, but given the amount of perfectly valid posts I wanted to upvote but were made anonymously, this does not seem to bother the people posting anonymously.
Unless, of course, they don't know either.
Thanks for the link, cognitive biases, and there relation to creativity/problem solving is one of my fave subjects.
Then you should definitely check out David McRaney's blog youarenotsosmart.com, much of which was collected into his book of the same name (which I prefer to the blog, personally). Nice brief descriptions of common fallacies that have been substantiated by methodologically-sound research, with citations. I don't know of a better primer on cognitive bias.
The downvoters are in denial, they still think they are the best developers on the planet, regardless of what you write, because they can open VisualStudio, copy-paste-edit and their shite "compiles" and when run, displays a .... clock ... that ticks away.
Yes, they have a natural talent to handle sponges and buckets, but that will not deter them, they sincerely believe they are the greatest of the greatest developers.
Either of you downvoters care to tell me *why*? I didn't think this was a particularly controversial post...
Who can say? Maybe for the generalizations about "management". Personally, I wouldn't downvote someone for that - I generally wouldn't even bother arguing about it, even though I think it's a false and pointless generalization - but maybe it struck a nerve with someone else.
Around these parts, a few downvotes often give a post a bit of credibility. If it doesn't get any downvotes, its information content may be low.
@Vic
Tools are a small piece of the problem; you can produce good code with next to no tools, and you can produce utter shite with the best tools in the business.
I agree with your reply to my post. I may have used the wrong word when I said "tools" though... I was thinking more along the line of one of the hundreds of 5 minute languages or js frameworks that are popping up just now, or one of the far too many minor NoSQL toys. The stuff that won't be around next year, never mind next decade.
There's nothing wrong with "minority" languages or NoSQL - The excellent RabbitMQ is produced in Erlang, which is great at what it does and not great at stuff it wasn't designed for.... They just need to be used appropriately and with the concept of needing 10 years of support and enchancement after go-live.
Back in Uni, we were taught about Fagan Inspections, which was probably the first kind of formal code (or document or whatever) review. It all seems so sensible that it makes you wonder why everyone doesn't do it. There are various aspects that make it so effective:
The biggest advantage from it seems to be "cultural". By making sure that the review is never about the person producing the code, it makes it easier for that person to accept the review as constructive criticism of what they've produced and not as a personal slight. Better still, if there's a mix of more and less experienced people, the less experienced can learn a lot about what makes good code and the common mistakes and pitfalls. I would guess that this would be particularly true if there's someone with some experience in writing more secure software since writing defensive code (eg, bounds checking or making sure that variables are always initialised) often isn't something that less experienced developers even think about.
Very few companies have time for the kind of mentoring that's often needed to bring junior developers up to speed on proper development practices, so you often see them making the same mistakes time and again. I agree with you that in some cases you get programmers who can't even see that they need help and, as you say, they confuse business (ie, being busy) with productivity. Often they resent being corrected. That's why I think that these kinds of inspections have as much a cultural aspect as technical ones.
The fact that this manager you're talking about is so clueless echoes what Fagan said (IIRC) about how important it is to properly educate the management so that they buy into the cultural aspects. Unfortunately, as with some developers, some managers seem like they simply can't be taught. I'm sure everyone has plenty of experience with incompetent, micro-managing or bullying managers. No doubt they're also suffering from the DK effect.
Obviously inspections like this take time, but I reckon that if done right it's the least painful way of getting people up to speed and a great way of getting out of what someone else described as "crisis-driven" software development.
A possibility for others adopting particular tools after seeing a coworker use them is that the coworker has already done the tedious, time consuming task of getting to grips with integrating the tools with the dev environment and using the tools in a useful way, and so other workers can get up and running quickly with the new tools with far less learning curve pain.
I'm certainly not a "coder" in the sense of the article. I know damned well however that I'm a cowboy. I just leave the cowboy aspect parked for those moments when the rotary aerator has met the airborne waste particles. Its about the only time its called for, and usually not even then. I have command and control tools that require that I understand the basics of coding and shell scripting, and I've found scripts from folks that had absolutely no commentary in them. I've found my best "security" in ensuring that I leave a comment on *why* something is there and *what* its supposed to do -- but as I noted, I'm not a coder in the sense of the article. Bounds checking and object validation are *not* beyond me and are done where appropriate, even in bash/korn scripts and python and perl it can be done.
I find it staggering the number of developers out there that think that in an enterprise, they should be running application development code in their user accounts. I keep pushing them to use the app account that is set up for this *(and backed up and audited and secured properly)* and they do nothing but whine at me about the "extra work it adds".
As a programming consultant, I have worked in just about every environment. The places I like to work the most are the ones where I can code on a dev server, but do not have access to the production server.
The benefits to that configuration are enormous. No more worrying about what my code is going to do, if it's a cockup, I just roll back the data and go back to the drawing board. I can debug to my heart's content, destroying the same data again and again until I get the whole procedure right. And when the code has been approved and is ready to be put into production, well I can't do that so if there is cockup then, it's no water on me.
When, on the other hand, I have to go and work on production environments (and it happens depressingly often, and not just in mom-and-pop shops), I take an inordinate amount of time in analyzing the code changes required, implementing as many safeguards as I possibly can and doing dry runs (no data change) until I'm as sure as I can be that nothing bad will happen. I hate working like that, but that's the job.
Pascal,
I had an 'interesting' job about 10yrs ago in a well known outsourcer, after some serious shit hit the 'public fan' the Group FD said (I quote) "I don't care what it costs, just f'ing fix it".
The internal IT bods were amazed that I wanted multiple (duplicated) environments:prod/test/DR, the dev environmemt was a bit cheaper, but functionally similar.
Folk that should have known better actually suggested having test & dr on the same environment. I asked them how they would fault-find without having anything 'working' to test it on when something BIG happened...?
I am certainly no coder - and fine with that, methinks the real skill of a senior techyish-manager is having the confidence to ask f'ing stupid questions; the responses to which often involved the use of 'umm', or 'err...'
Cheers,
Jay
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
