|
I think we would be better off with better testing and verification methodologies. The cost of software has been an issue for a long time. Requiring certification will go nowhere once the cost of doing so is realized.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Here in the DoD/US Air Force they already make us get IA certification, even though most of it doesn't apply to us. Air Force Manual 17-1303 says:
"... software developer/engineer/programmer positions requiring less than 4 years’ experience as an IASAE Level I"
"... software developer/engineer/programmer positions requiring 4 years or more experience as an IASAE Level II"
DoD Directive 8570 outlines the IASAE (IA System Architects and Engineers) level requirements but basically we all have to get a CompTIA CASP (Advanced Security Practitioner) certification. The problem is that 80% or more of what CASP covers has little applicability to software development, but we have to know all that stuff and pass the test to keep employment. It's basically a money-making scheme IMO.
|
|
|
|
|
We teamed up with researchers from New York University and the University of California, San Diego to find out just how effective basic account hygiene is at preventing hijacking. Employees must wash passwords before logging in
|
|
|
|
|
I prevented a million attacks on your account on my server!!
Statistics by Google.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
The only thing I'm sure is that every few months they attempt to prevent my mail client from IMAPing on my account by annoucing suspicious activity at my IP and urging me to disable "less secure" access; by which they mean anything but their web access. 
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
If an employee is not available then please wash your own hands password.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
modified 22-May-19 18:30pm.
|
|
|
|
|
In the nearly two months since Vice President Mike Pence directed NASA to return to the Moon by 2024, space agency engineers have been working to put together a plan that leverages existing technology, large projects nearing completion, and commercial rockets to bring this about. I remember 'Where it's at' being a little catchier than that
"That was a good drum break"
|
|
|
|
|
I think we should let Hollywood and Pixar simulate it. It'd be cheaper and probably a lot more interesting -- I mean, just imagine discovering the real monolith!
And besides, given social media, we'll have endless debates anyways as to whether or not we have a real outpost on the moon. Only this time, we'll make it public that this is a Hollywood creation, and then the conspiracy folks can get on the "no, it's real, we're just told it's Hollywood because they don't want us to know about all the alien tech they've actually discovered!" 
Latest Article - A 4-Stack rPI Cluster with WiFi-Ethernet Bridging
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Microsoft says that a known issue will block Windows 10 from booting after trying to restore the system to a restore point created before installing a Windows 10 update. And people ask me why I drink
|
|
|
|
|
Yet more proof of how good an idea sacking all the dedicated testers in favor of devs testing their own code prior to merging was. 
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
That makes the restore point nothing more than a waste of disk space.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Following the US crackdown on Chinese technology companies, Google has cut off Huawei’s Android license, dealing a huge blow to the besieged phonemaker. "No soup for you!"
I'm sure there's no forking solution to this impediment!
|
|
|
|
|
Are Trendy Developers Ignoring Tradeoffs and Over-Engineering Workplaces? - Slashdot[^]
The problem with "keeping up" isn't with the developers as much as it is their employers. The employers continually fail to recognize that technology moves along at an admittedly too-fast pace, and they don't see any monetary gain to be realized from up with it.
In point of fact, the longer they wait to move to a more modern tech stack, the more it's going to cost them to do it, in both time and money. The devs play a moderate role in this, because they are resistant to change for the sake of change, but at the same time, the devs are usually the first ones to identify the need for change, because they are the ones mired in 10-15 year old code bases that are so heavily patched that nobody really has a grasp of what's going on. The stake holders don't want to allot time because they want new features, and the bean counters don't want to commit the money to a rewrite, and the devs become disenchanted with the whole thing because they have to maintain "crap code" in "ancient technology" that was end-of-lifed/abandoned years ago.
Trade-offs? I think not. Money? Yep.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
#realJSOP wrote: Trade-offs? I think not. Money? Yep.
To say nothing of safety. Much old code was written using "unsafe" APIs such as the original C string API, and in many cases is just begging for buffer overflow errors.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Just because something could be unsafe, doesn't mean it is.
|
|
|
|
|
We must look at two cases:
- Writing new code. Given the number of bad actors out there who will attempt to exploit any possible breach, not using the "safe" APIs is tantamount to professional malpractice.
- Upgrading or modifying old code. This should be treated like renovations in an old building are. Replacing a light fitting does not require that the whole building be brought up to code, but a major renovation does. Reasonable people may disagree on the meaning of "major".
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
today's "modern tech stack" will be obsolete next week. it's impossible to "keep up".
|
|
|
|
|
In business school we studied trends and their profitability. The early adopters were usually unprofitable as were the late adopters. The best niche were the second or third wave of adopters who let the early adopters sort through all the problem issues.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
The aversion to updating the tech stack is mostly about money.
Corporate overloads don't want to commit to splitting the team for maintenance and new dev, and by the time development is complete and the product has gone through the testing phase, a "new thing" has been introduced, and the stake holder wants the newest shiny object, which really isn't compatible with the way the new code has been developed.
Tech moves so bloody fast that it almost destroys the co-concepts of code re-use (how can code be re-used if the basis on which it was developed is no longer "a thing") and separation of concerns ("concerns" seem to get more fragmented every day, and need to be micro-separated). Devs can't possibly hope to keep up because tech keeps leap-frogging their skill set.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
#realJSOP wrote: The aversion to updating the tech stack is mostly about money.
Surely to say it is "mostly about money" is to belittle the significance of it. Isn't it surely about basic business sense.
I.e. It makes little sense to change basic strategy in the middle of a project. Once a technology stack is chosen, see it through until (at least) the end of the project.
You can view this as "mostly about money" but I see it as being about strategic sustainability, deliverability, and the basic requirement of there being a business and a job to come back to the day after tomorrow (metaphorically speaking).
|
|
|
|
|
n business school we studied trends and their profitability. The early adopters were usually unprofitable as were the late adopters. The best niche were the second or third wave of adopters who let the early adopters sort through all the problem issues.
I presume you studied the same issues, reaching the same conclusions, in engineering school, too.
Thanks for chipping in on this important topic.
Though I trained as an accountant, I usually see myself as more engineer than a bean counter. Alas, all three constituencies have good points. Nevertheless, both engineering and business are all about making considered compromises.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
You remind me of a comment I heard back in the days of Snow White and the Seven Dwarves[^] and have never forgotten. It was a lament, maybe from a senior engineer at Univac. Referring to bringing new technologies to market,
You can come first and get the glory. You can come third and get it right. Why do we always come second? I've seen so many (and been involved in some) examples since.
73 de
Peter (licensed since 1960s, inactive now)
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Don't pretend there isn't a massive cost on "keeping up". It's not just money, but time and stability. The idea that if something isn't "modern" it's broken is absurd. Going with the latest fad massively increases bad code and abandoned technology as it gets dropped for the next latest thing.
Quote: the longer they wait to move to a more modern tech stack
Which modern stack? What if you pick wrong? I've interviewed at companies and worked on several projects which picked wrong. (In retrospect the architecture and/or design was sound for most, but the technology picked had become an impediment.)
And it does cost money and that's a valid consideration. I worked on a project which was painful because the embedded devices were stuck in 2003. They could have been updated to modern hardware (and thus more modern development) but at a massive cost with marginal benefit for the customer. Try telling a customer they need to spend tens of millions of dollars so the software engineers will have an easier time.
|
|
|
|
|
Joe Woodbury wrote: What if you pick wrong?
Generally speaking, you always pick wrong. 
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I agree with the 'if it's not fixed, think very hard about how you try to fix it' crowd. The fact of the matter is that, at least for desktop and back end type applications, the tools to do them perfectly well have been around for a good while.
The drive to 'keep up', to me, seems more to stem from the fact that a lot of people who are software engineers are more interested in the process than the final product, and they measure their own 'prowess' not in the code they've created but in how many of the details of the language and libraries they know. And partly because the fairly broken interview process at most software companies also tend to emphasize these things when they are much less important than other things.
Particularly people who are sort of serial monogamist mercenaries, moving from one company to the next and working on someone else's dream I think are more likely to be obsessed with keeping up with the language for its own sake because they aren't that interested in the software they are creating and they feel that doing so will make it even easier for them to move to the next company.
If you are an entrepreneur, then it's completely the opposite. Your customers don't care what language features you use, they want good software with lots of features. So the pressure is very much to find a set of tools that work and stick with them. As the code base grows it gets harder and harder to make fundamental changes because it's just brutal and your code base will remain in a constant state of destabilization.
I'm luckier than most in that my very large code base is only used by me (currently anyway), but making fundamental changes is a terrific slog and guaranteed will introduce subtle bugs that won't show up until the new code is in the field.
I recently went through the entire (1.1M line) code base and converted it to use the new type safe C++ enums (enum class.) That was incredibly brutal, and only massive amounts of coffee got me through it. It also introduces a lot of bugs (by my standards anyway) that I had to chase down. It was worth it in the end, and it greatly increased compile time safety. But it was small compared to retooling a large code base for a whole different technology with a good sized team.
Further back I completely rewrote my UI framework from scratch and all of the extensive UI code in my CQC automation system that depended on it. It literally took me a year. I worked on some smaller things on the side during that time, but mostly it was a year devoted to that massive upgrade of the code base. Sort of equivalent to what it would be like if a large, GUI-rich program switched to a new UI framework that was very different from the old one and had to significantly change the entire presentation and interaction scheme across the board. Though in my case I was writing the UI framework as well.
Again, worth it long term, but that's a year of no new features, and it would have probably been ten times more brutal in a large team environment. And in a far more likely business scenario where a year without new features just couldn't happen, you'd have had parallel development on a pretty significant scale and all the craziness and bugs that would involve later to bring it back together.
Explorans limites defectum
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
