|
I suppose they have been inspired by the paste assistant in CP 
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
LG says it’s developed a new material that can create displays with “a surface as hard as glass and folding parts as flexible as plastic.” Is that a folding phone in your pocket, or do you just have too much disposable income?
I guess that's more of an "and" question.
|
|
|
|
|
If I wanted such a big display I would buy a tablet...
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Technical debt impacts the whole company, but it especially affects engineers as more tech debt means more bugs, performance issues, downtime, slow delivery, lack of predictability in sprints, and therefore less time to work on new exciting projects. Declare technical bankruptcy?
|
|
|
|
|
I love technical debt. No employees want to work on "old stuff". Meanwhile, I'm paying off my mortgage. 
Technical debt is a buzzword that I believe has no real meaning.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
charlieg wrote: Technical debt is a buzzword that I believe has no real meaning.
I think you're correct.
It seems to me that what people increasingly call "technical debt" is just... code. The stuff you wrote yesterday. You know, the stuff that actually sells licences, seats, whatever.
There is far too great a trend to declare everything over a certain (ever-shortening) age as "legacy" and pretend that one should just start again from scratch. No. This is a lazy and, frankly, incompetent approach. Sure, I accept there does come a point when starting afresh makes sense but it should never be a common choice. The cries of "legacy" are becoming too common to be realistic or sane.
Coding is about maintenance, not just the new and shiny.
Yes, I know that the spotlight and fame tends to get focussed on the new and shiny, i.e. on the re-invention of problems already solved with "legacy" code, and on those who work on the new and shiny, but this does not make maintenance any less important, any less necessary, or any less valid.
Everyone wants to be a new and shiny superstar. This is understandable perhaps. But it doesn't mean that wasting money on starting afresh every year or whatever is justified, sane or sensible.
|
|
|
|
|
For us, technical debt is code that (appears to) works fine, but that everyone recognizes could use a rethink/re-implementation without changing the result. We have a number of things that are technical debt. Some are (much) more involved than others, and most of them are in the back-end. The two most annoying to me are:
0) For instance, we have a table that has over 600 columns, and that requires a crapload of dynamic sql to access. This could easily be stored in an unpivoted fashion and eliminate the dynamic sql altogether, yes still provide the same data that was expected.
1) Another technical debt item is our javascript. Instead of using a single function to create a grid that accepts an "options" parameter, we have about 30 different functions that create their own grids, each in a wildly imaginative way. We could significantly reduce the code footprint if we used one grid function to rule them all.
".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: We could significantly reduce the code footprint if we used one grid function to rule them all.
Obligatory XKCD[^].
Between devs who don't know that it exists, and devs who need an option that it doesn't support but are afraid to modify it, 18 months after creating the OGFTRTA function you'll be back to at least 31 grid functions.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
If code that uses the grid function is well documented to indicate the existence of the function, you shouldn't have that problem. When beginning work on an established product, most of us look through the code to see how something was done and imitate that methodology as closely as possible, and chances are pretty good that you'll notice the comment about the existing grid function.
Since you know all of the properties of the grid ahead of time, the grid function can be written in such a way as to support all of its potential properties, and handle the absence of associated properties in the options object (default functionality), making the function robust and reasonably future-proof. That way, the options object only has to be initialized with properties that matter to its current implementation. It ain't hard to do or conceptualize.
".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: It ain't hard to do or conceptualize.
Famous last words! Have you visited QA recently? 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
This is all fine and well, but the underlying assumption is that it needs to change because it's nasty. Are you trying to add functionality to this mass of porridge? If so, then I grant the technical debt. But so many times, when people say technical debt what they really mean is old code, old products, etc.
Even if the products are still producing revenue.
One place I worked at had developed a system that interfaced with all 50 states driver databases. Insurance companies would submit batches of customer names (think hundreds of thousands at a time). The system would sort the requests by company, state - send them to the DMVs and then parse the responses back. It was written on a "legacy" system (VAX, OpenVMS, mostly C code). Because it was not fancy, and it wasn't using "new technology", etc they were actually going to chunk it.
I had an Ernest conversation with the VP telling him if that was the company's direction, I'd purchase the system in a heartbeat. And I was serious.
The system sits in a corner and still makes the company 40 million cash a year.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
I see technical debt as being existing code that works (reasonably bug-free), but in the interest of ease of future maintenance, or to support upcoming features, should be refactored. We have a poorly designed database back-end that has been overcome by events, and it could really use a good general refactoring.
One instance of tech debt for us was that we made infrastructure changes in our back-end almost two years ago that were intended to support a new feature that we finished started at the beginning of August, and finished last week. I had to implement the back-end stuff without visibly changing the current functionality. We're all glad that I did that infrastructure stuff back then. Otherwise, we'd still be working on the new feature.
The product I work on is a "living" app where requirements change on a weekly basis. Maintainability is the key, and right now, it's not very maintainable. I was working to change that, but well, you know - DoD. I would simply add comments to stored procs when I had to go look at them for some reason, but now I can't do that because of our scrum/agile rules. It's maddening to have to work with code that's 14 years old that has almost no comments, and there's simply no way you can commit the intent of hundreds of stored procs to memory. You MUST have comments in the 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
|
|
|
|
|
realJSOP wrote: I would simply add comments to stored procs when I had to go look at them for some reason, but now I can't do that because of our scrum/agile rules. It's maddening...
 Maddening? Your rules need to be double-tapped.
|
|
|
|
|
upvoted
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Technical debt means the necessary maintenance wasn't done, so now there is debt to pay off. If poor code isn't refactored, ideally before it is merged, it leaves land mines for those who follow.
There needs to be a business case (net payoff) for rewriting code. If it's stable and doesn't need to support new capabilities, there isn't one. However, if it has to support new capabilities, but adding them will be difficult, or if it's the root cause of lots of bugs, rewriting it can make sense.
The desire to rewrite without a business case has been around for a long time. Soon after starting my first job 40 years ago, a senior manager described it as, "I want 2 + 2 = 4 on the screen" and being told, "Yes, we can do it. But it won't be elegant, so we need to rewrite the operating system."
I actually wrote an article[^] about rewrites.
modified 12-Sep-21 10:44am.
|
|
|
|
|
Microsoft VP Steve Dispensa from the Windows Management team explained why Windows 11 should feel snappier and more responsive than Windows 10 on the same hardware. Don't worry - they'll get back to slowing things down again real soon.
|
|
|
|
|
Walking with coffee is something most of us do every day without considering the balancing act it requires. All this time I have been (mostly poorly - and pourly) demonstrating my mastery of physics!
|
|
|
|
|
Quote: Walking with coffee is something most of us do every day without considering the balancing act it requires.
And even more if you try it after 4 or 5 coffees 
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Irrelevant anecdote:
I spent some time working in a couple restaurants before I became a programmer. An old hand taught me an important trick when carrying a cup of coffee, or indeed any container of liquid: don't watch the container while you carry it. When you watch what you're carrying you tend to overcompensate for motions of the liquid in the container, plus you always respond well after the motion, leading to greater spillage.
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: don't watch the container while you carry it
This.
I learned this from my dad when I was 15. When you're on a ship at sea, carrying coffee has to be developed into an art form. Early in your career. I can fill a cup almost to the brim and not spill a drop.
".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
|
|
|
|
|
The rise of remote work is truly changing the landscape of hiring developers and finding talent. But are companies better able to find The True Senior Software Developers in 2021? "We're gonna have a problem here"
|
|
|
|
|
Quote: But are companies better able to find The True Senior Software Developers in 2021?
Of course... the new AI based HHRR Softwares for candidate selection are exceptional 
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Someone needs to tell the douchebag who designed that web site that silver-on-white text is difficult for 'senior' developers to read  .
Or was that the point?
Software Zen: delete this;
|
|
|
|
|
Senior Developer is a bogus title. You've slogged through the work for 5+ years at the same company. How do I give this guy a raise? Let's call him a "senior developer."
One place I worked - all senior developers.
Just another bogus term left over from HR.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
 Then they have to invent a title higher than senior, then something higher than that, ad infinitum. At a place I know of, they have senior foo, lead foo, group foo, senior group foo, principal foo, and probably a few dozen more I’m blanking on. 
TTFN - Kent
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
