Somehow or other the Firefox community has convinced itself that scanning add-ons for vulnerabilities and malware is a good idea. Luckily Dan Stillman the developer of Zotero called them out on it pointing out that it is just Security Theater.
Firefox has always had lots of really large extensions, but by deciding that they must be signed and reviewed, the Firefox community has just committed itself to a LOT of extra work reviewing the extensions. Hence the dumb idea of scanning to see if there is anything malicious in it. Now that is an arms race that is going to be lost. The guys in the AdBlock game know that, a continual game of whack a mole. Actively developed extensions like Zotero really lose out because a manual review of a large codebase takes a long time, and scanning is insufficient (as the above link describes, it is easy to create an add-on that passes scanning and does nasty things).
The Atlantic just realized that programmers are not engineers
Sorry to break it to them, but this has been a topic of conversation long before I wrote the book Software Craftsmanship, which was published nearly 15 years ago.
And then this article about testing — Doing Terrible Things To Your Code reminded me to look at it again.
QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a sfdeljknesv.
I sure wish more programmers would focus a lot of attention on testing their own code before passing it on to QA/Test. That way the QA/Test team can focus on finding the requirements and interaction defects, rather than the simple coding mistakes that are often the bane of their existence
Kevlin Henney - of Curly Bracket Languages fame has a good video of his presentation at a recent NDC conference Seven Ineffective Coding Habits of Many Programmers. As usual a very entertaining talk, but Kevlin is also spot on in identifying ways in which we are lead to make incorrect decisions about the code we are writing.
In it he references a paper from Rob Pike Notes on Programming in C. Although Rob Pike wrote that paper back in 1989 it is still relevant, as can be seen by his words about variable names:
Length is not a virtue in a name; clarity of expression is.
Interesting long article on a Kitchen Bladesmith, describing the expertise that goes into making kitchen knives, especially those for the chef market.
Zed Shaw has written an introduction to his Hard Way series and in it he writes
The one skill that separates bad programmers from good programmers is attention to detail. In fact, it’s what separates the good from the bad in any profession. Without paying attention to the tiniest details of your work, you will miss key elements of what you create. In programming, this is how you end up with bugs and difficult-to-use systems.
In The Leprechauns of Software Engineering Laurent Bossavit has an interesting take on the folklore of software development.
Software development is a hard problem.
Books like The Mythical Man Month, Set Phasers on Stun and The Inmates are running the Asylum have all pointed out in their own way that creating software is hard. Fred Brooks focused on the problem of large complex projects, and the problems that face project managers, the other two remind us that even small projects can fail because we still are not able to create software that is both easy to use and powerful enough to do that tasks that we want to do with software.
Until we are able to understand why software development is such a hard problem, we are not going to make much beyond incremental improvement. There will always be a few projects that through the operation of blind luck across millions of projects that results in seemingly reproducible improvement, but the normal regression to the mean will correct that eventually.
I didn’t see this when it was first written, but it matches with my recent experiences.
… most programmers simply don’t know where the quality bar is. They don’t know what disciplines they should adopt. They don’t know the difference between good and bad code. And, most importantly, they have not learned that writing good clean code in a disciplined manner is the fastest and best way get the job done well. – Robert Martin
Many software developers do not seem to understand the basics of our craft. Recently I’ve seen
- SQL queries that were massively more complex than they needed to be - that when simplified, without any database changes ran more than 10 times faster
- Client server applications that issue nearly 1000 SQL queries while refreshing what is supposed to be an interactive screen - the end result being that the poor user has to wait 5 to 10 seconds for the screen to refresh after conceptually simple actions
- Supposedly secure web applications that sent Active Directory usernames and passwords in cleartext across HTTP connections
- Code that created connections to external resources but forgot to free them - made for a very effective rate limiting mechanism since the external resource freed unused handles about an hour after they were last used
There have been lots more examples, but most of them fall into the category of being unbelievable if you were not a direct witness to the utter ignorance of the basics of software development that brought them to my attention.
Maybe it is time that we started to focus on the basics of the craft of coding before we get too far into creating overly complex systems that nobody can understand or fix.