|
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
|
|
|
|
|
Moving along with all the new tech costs as well, often without amortization. Imagine a world where there's the framework de jour, following every single trend will be a great way to keep developers busy by simply following the latest trends, constantly porting the current product without ever adding new features because keeping is a monumental task in of itself.
Don't get me wrong, I don't argue for sticking strictly to "If it works, don't fix it". Had mankind always stuck to this way, we'd be still living in caves. But you seem to be suggesting the opposite and that's a great way to be stuck forever as well. The solution is the middle ground.
|
|
|
|
|
I'm not saying change everytime a new thing comes along, but you get to a point where it becomes almost impossible to find anyone with experience in your chosen stack.
We have a ASP.Net web forms code base that is 13 years old, and that has had no major changes in that time. The problem is that it's been worked on by more than two dozen different people over that time, most of whom were not at all interested in commenting their code. This has caused us to have things like a dozen versions of a javascript grid object (as opposed to a single one that accepted a configuration object), a folder hierarchy that is a freakin nightmare to navigate, and a handful of pages that don't use a master page. As you might imaging, the code is highly spaghettified. Given the high turnover rate, you'd think they'd at least have a document regarding what's been done and where it's located, but, well, we don't. We can't even piece together a history of changes because they've changed source control software at least half a dozen times over that 13 year period. It's a freakin free-for-all, and because it's getting harder and harder to maintain, it takes longer and longer to add new features, and the project is in real danger of being EOL'd.
Periodic rewrites are truly the only way to avoid these problems.
To be clear, I'm not talking about changing tech mid-stream, I'm talking about periodic rewrites while maintaining the old code base.
".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
modified 20-May-19 10:24am.
|
|
|
|
|
Periodic rewrites may alleviate the symptoms in your case, but what about solving the root cause? Why is there a high turnover? Is it really the code quality (and in that case, a single rewrite would solve everything) or something else? Speaking from experience here, I've inherited a project that's been worked on by several people, some of them less sane than others (replaced 2 nested loops for string processing with 2 function calls, just as an example). I swear that this thing has been paid for by the line in some past, at least, that's the only sensible explanation I have for some of the mess I've cleaned up. Now I've been a couple years over that thing and despite some issues yet to fix (speaking of less sane, packing binary data into strings is so stupid, I wish stupidity hurt more than it does, namely apparently not at all), the thing is looking better than ever before.
Treat the cause, not the symptoms. If a high turnover causes the project to be a mess, rewrite it once and then get one programmer, well-paid & otherwise motivated, to maintain it. That's not the only sensible action here. Ever-changing VCS is another symptom of deeper issues. Is it, maybe, the exactly one we're talking here namely the wish to always stay up-to-date, the angst to remain stale, that causes bad decisions? What about the multiple grid objects? Why not picking a language with a proper standard library that already has a grid object? One doesn't need to be a bad craftsman to blame their tools if the tools are rightful to blame (although I suppose that JS is pretty much bare of any alternatives in your case, I'm a desktop app developer). Why not refactoring/rewriting the thing ONCE and establish useful coding practices? Let's suppose there's a good reason for high turnover (there can't be, but let's just roll with it), factor out often needed parts, such as said grid object, in a common library, easy to find, so everybody new will pretty much stumble upon it themselves (assuming they're not utter newbies not having touched anything but a student project before, but that's another solvable issue).
Cleaning up years of technical debt and/or sloppy code ain't easy and to be honest, I remember myself doing something similar, namely small changes, not disturbing the big picture too much in the moment but severely hampering the design in the long-term. Well, I was a noob back then and we had a senior engineer supervising me preventing issues like you described in the long run.
Rewrite it ONCE and then keep it clean.
Anyway, you have a case that's rather different from the one the discussion opened with, namely developers chasing trends somewhat for the sake of it. On the other hand, maybe not. Maybe the reason for your several grid classes is developers trying to keep up with how a grid class should work and dismissing the existing ones because the trend changes.
|
|
|
|
|
Member 9167057 wrote: Why is there a high turnover?
DoD contract. Every 2-3 years, a new company under-bids the encumbent, and because they underbid, they can't afford to keep the people already doing the work, and have to hire new, less-experienced (to meet the pay scale) people. Eventually, the code base gets so screwed up, the project is simply killed off, a new company is brought on to do the same thing all over again, and the cycle repeats itself.
".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
|
|
|
|
|
There's no remedy for that situation. A customer looking at costs above all else (i.e. quality) surely won't accept a rewrite for the sake of code quality because a rewrite is a year or so (estimate from my own work, yours may vary) with bills to pay but no new features or bugfixes (granted, a rewrite may remove some old bugs, but may just as well introduce new).
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
