|
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).
|
|
|
|
|
Member 9167057 wrote: 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).
We have 20 ASP.Net WebForm apps  that we maintain right now. With regards to login/registration/environment/layout, they all work the same. At that point, they diverge into their specific domains. Beginning in February (and on my own time at home), I started writing a new MVC5 template that we can use as a jumping off point for rewrites. All of the shared functionality has been implemented, saving months of dev time. At least the various devs can concentrate ion their apps' content instead of also having to deal with the tedium of common infrastucture stuff. Some of the apps are small enough that they can be re-written in a matter of a few weeks.
In order to pull off a re-write, the team has to be deep enough to be able to withstand carving one/two people off to do the the new stuff, while having enough sufficiently skilled devs maintaining the soon-to-be-legacy code.
".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
|
|
|
|
|
this thread has me thinking about game development.
Duke Nukem Forever had some blame toward 'lets change to a newer game engine (many other issues but this sticks out)
Open worlds where I often think, wow, looks great, why don't they reuse 90% and make a different story. IE spider-man ps4 2018, replace with another marvel character. change some physics, spend some time on new mechanics, make it for a fraction of the cost?
But alias, most end up having the some of the large parts redone to meet the Next New Thing.
|
|
|
|
|
When I studied for my computer science degree, it was all about computer science. When I studied for my business degree, it was all about business. The concepts of this post are a lot bit of both.
When I look at this post the first thing that comes to my mind is, how long does your code base need to survive? Are we looking at an application with a lifespan of 5 years, 20, 30? I do a lot of government work and see the last two numbers quite a bit, whether by planning or just the arena. I will focus just on the 5 years. Name a technology that was the new thing 5 years ago, is it still around? If you based you new application on it 5 years ago and it is, great, but you still have to rewrite as you are now at end-of-life. If the stack isn't still around, now you have a product that has either been rewritten a couple of times, or is in sore need of a rewrite now. What is the cost of that? What is your ROI? TCO? Basically what is the true cost of using that stack for 5 years. That is the business end of it.
Developers, we tend to look at, oh here is a new shiny toy and I want to use it. Meanwhile your boss is saying, no it will be too expensive. "Keeping up" is a game of chasing the shiny new toy, regardless of business cost. Short term that may be great, long term that can be very expensive. Always "keeping up" HAS a significant cost to a business. Not having a stable framework for more than 6 months, HAS a significant cost. Always "keeping up" can be so expensive that a company goes under for no reason other than "keeping up". I have never been a person willing to follow the trends. I find a stack that works, can be maintained and will last a significant amount of time, and use that. I mean seriously wasn't Ruby on Rails supposed to completely change our industry (switch this out for one of hundreds of trends)?
To me the whole concept of "keeping up" smells of a junior or mid-level developer who hasn't stopped and stepped back, to look at the picture of a whole business and ONLY cares about code. Without a business, there is no code, if chasing a new shiny object can't support a business, it shouldn't be done period. Moving to updating frameworks and code in a way that supports a business and is done in a cost effective way, is what a senior developer should have in his mind. You have to support the business and they will support you.
|
|
|
|
|
"Workplaces" -- I keep thinking this is referring to, well, the workplace. You know. Office. Cubicle. Windows. Water cooler.
When did this word get hijacked to mean whatever the hell it means in that post?
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
|
|
|
|
|
It's part of the UN's Agenda 21, and is the major cause of global warming.
".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
|
|
|
|
|
Amid soaring demand for enterprise mobile and Web apps and scarce dev talent, delivery times often average more than 4 months, says a new survey from low-code tooling vendor OutSystems. That's because you have to change your web framework monthly (at least)
|
|
|
|
|
Is it just me, or does four months not seem all that long for a potentially complex application that presumably needs testing, documentation, and some kind of support services to be put in place.
How long should an app take to develop? How long is a piece of string, I suppose.
|
|
|
|
|
Quote: "Our 2019 survey shows that many IT departments are facing a multitude of disruptive forces when it comes to digital transformation and application development,” said exec Steve Rotter in a statement. “The threat of digital disruption and the need for digital transformation has been a driver of IT strategy for years. Add to that the current uncertain global economic outlook, and it becomes obvious why business leaders are so concerned about agility today.”
Eh? Am I just incredibly dense or is that just a word salad?
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
I think it sort of makes sense, albeit in a consult-speak sort of way...
|
|
|
|
|
"said exec Steve Rotter" - that's how execs talk - lots of words, no actionable info.
|
|
|
|
|
A new invention uses magnets to record computer data which consume virtually zero energy, solving the dilemma of how to create faster data processing speeds without high energy costs. Magnets. How the frek do they work?
Of course, the article doesn't seem to mention him retrieving the data from the magnet.
Then again, the title says that it was 'Virutally energy-free', not 'virtually'. So maybe it's an adverb appropriately describing the energy use.
|
|
|
|
|
Like that strip from "B.C." where the dialog runs something like: (quoted from memory)
- My brother has invented a vehicle that runs on water.
- That sounds really great! What does he call it?
- A rowboat
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
