|
I'm going to ride your comment instead of the top level because yours is the antithesis in a sense and it's why I don't want to really argue for the one I'm about to make, but recognize its cogence all the same.
If you don't worry on it and you let things run amuck for a long time, it *might* be easier to argue for that rewrite/tech facelift you're going to very much want in 5-10 years. When you greenfield it and it comes out of the gate as pristine and maintainable, the ROI in support/feature tickets will be apparent. Sure, it would be apparent if you rewrote bits of it last week too, but...
|
|
|
|
|
Matt Bond wrote: use good architecture/inheritance/coding concepts (DRY, SOLID, encapsulation, etc.),
Except that all of these things can be done to excess. Too often I've waded through ponderous codebases that have unnecessary levels of abstraction, or encapsulation (getter and setter provided for the same attribute - why not just make the attribute public). I think these things have a U curve of complexity/cost tradeoff - some of these things are useful/necessary, but more of a good thing, is not necessarily a good thing.
Matt Bond wrote: Keep all things as simple as possible, but no simpler. -said someone, somewhere
Exactly
|
|
|
|
|
You don't have to worry (so much) about technical debt if you are never going to update a program once it's delivered. If it's going out on a ROM for a video game or it's the landing program for a Mars rover, it's either good enough or not, but you'll never update it.
On the other hand, if you're deploying every day, like for a web-based business, then you're always maintaining code, and technical debt is a killer.
The way you make someone care about technical debt is to make them responsible for it. Reviewing module tests to ensure they cover the whole interface is one way. Making the person who submitted the broken code fix it is another way. A third way is to show managers that repairing tech debt after a bug is reported is more expensive than taking the time not to insert it in the first place. Technical debt is compound interest. It makes everything more expensive. If you're in a continuous maintenance cycle, it will eventually choke you. You'll have to staff up again and again to fight the growing mountain of debt. It's a business-killer.
|
|
|
|
|
There’s a difference between technical debt and shoddy work.
If the code is not written such that it’s stable and bug free,then it shouldn’t be rolled out.
If it’s merely missing features or ‘could be’ written to be more efficient, then rewrite it when doing some enhancements or bug fixes in the area.
Adages such as
‘If you don’t have time to do it right, when will you have time to do it over?’ (referenced by @GregUtas) and
‘Fast/cheap/right: pick two.’ come to mind, but it’s near impossible to change the mind of someone entrenched in their thinking.
Good luck,
Time is the differentiation of eternity devised by man to measure the passage of human events.
- Manly P. Hall
Mark
Just another cog in the wheel
|
|
|
|
|
The proper way to deal with it is to make accommodations in the project schedule. However, the corporate big wigs probably won't want to understand that technical debt is inevitable in any software project, and to protect their bottom line, they'll insist that time allocations to resolve it be removed, and thus, it lives on in the software.
This problem becomes apparent when a "dev lead" insist that the latest wiz-bang framework is implemented in the software with no team experience in said framework, and the team implements code without a full understanding of that framework until somebody has an "ah-ha" moment and realizes that "we should have done it this way". This "ah-ha" moment leads to a mid-stream change of direction in implementation, usually meaning that existing (tested and approved) code is left in its current state, and all new dev going forward uses the "ah-ha" strategy, instantly creating technical debt to bring the now "legacy" design" into alignment. This alignment technical debt that will never be addressed because corporate doesn't want to approve the tasking because the the old code "works", disregarding the obvious advantages of doing so with regards to future maintenance.
This is what we in the business of writing code call a "cluster-f*ck".
We're experiencing that in our code base right now. Someone (before I was employed) decided it would be a good idea to use React for our app, and nobody on the team had *any* experience with it. Add to that several assumptions being made about the project (converting an existing Oracle Forms app to a web app), and we have a couple of "ah-ha" variations of our "framework" code to deal with, as well as an impending 3rd derivation. It never ends.
".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 argued with my compiler by quoting Nietzsche at it: "All things are subject to interpretation - whichever interpretation prevails is a function of power, not truth".
It wasn't impressed. It refused to compile my code.
Apparently my compiler is more powerful than I am. 
Maybe I'll see how it feels about Foucault - challenge the grand narratives of C++.
It is one of those days. I'm going to produce weird code.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
"God is the code, the code is God."
But now you have me thinking about this as well. It seems to me that -- with C at least -- the pre-processor is what does the compiling, in the linguistic sense. It takes code from various files, and compiles it together into one monolithic file for further analysis.
The pre-processor is therefore the compiler. What we traditionally think of as compiling should have a different term for it.
|
|
|
|
|
Maybe translation would be a better term. In fact, both C and C++ have the concept of translation unit, which seems to correspond to an individual .c or .cpp file. Logically, each of these is compiled separately, and the specs contain some arcane rules that seem to imply that this be done in theory, if not in practice. But for efficiency, I think it can all be compiled as one big file. That's what I do in my static analysis tool, which does much of what a compiler does but stops short of laying out memory and generating executable object code.
@code-witch is likely more expert on this and may weigh in.
|
|
|
|
|
You covered what I know. 
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
A red-letter day!
|
|
|
|
|
Maybe you should have quoted from the night song:
Quote: But I live in mine own light, I drink again into myself the flames that break forth from me.
I know not the happiness of the receiver; and oft have I dreamt that stealing must be more blessed than receiving.
Compiler would have recognized you are an Übermensch and not resisted you.
Mircea
|
|
|
|
|
A closely related Nietzsche quote: "Everything the state says is a lie, and everything it has it has stolen."
|
|
|
|
|
On matters of the state, I'm a bit more Stirner than Nietzsche as German philosophers go. 
Although I have to concede that as I've grown older the value of the commons is less lost on me than it once was.
I like the idea that we're ants, and we can direct our collective efforts through meaningful self-governance.
There are things a government can do that individuals cannot meaningfully do. That's often a bad thing. As I've grown older, I've become more aware of the good - things like the Internet, the initial moon landing, so much research. Hell, even the census. Sometimes we try to do things like this through other means and it either makes a few people very rich and becomes exclusive, or it simply can't reliably scale. Sometimes, like when we privatize prisons, it can become abhorrent, because it creates a profit incentive along the wrong lines. Imagine lobbying a government to pass stricter laws and longer sentences so you can lock more people up in your prisons. That's a thing that actually happens. Sometimes it's just better to tax.
I've probably said too much, but considering how much thought time i spent on this post, I'll risk hitting send.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Imagine district attorneys who won't enforce those stricter laws. Heck, they won't even enforce the regular ones.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
honey the codewitch wrote: it creates a profit incentive along the wrong lines
Like a local senator in my state who ran for governor (and lost) who votes down every proposal to decriminalize or legalize marijuana for any use because she owns a majority share of a company who does drug testing for companies.
There are no solutions, only trade-offs. - Thomas Sowell
A day can really slip by when you're deliberately avoiding what you're supposed to do.
- Calvin (Bill Watterson, Calvin & Hobbes)
|
|
|
|
|
The parasitic class, ever with us.
|
|
|
|
|
And there's more than one class of parasites.
There are no solutions, only trade-offs. - Thomas Sowell
A day can really slip by when you're deliberately avoiding what you're supposed to do.
- Calvin (Bill Watterson, Calvin & Hobbes)
|
|
|
|
|
Quote: Imagine lobbying a government to pass stricter laws and longer sentences so you can lock more people up in your prisons.
In the 50's and 60's Larry Niven wrote a bunch of short stories on using prison inmates as a sort of living organ bank to draw on when a contributing member of society needed a transplant. He wrote that as the need for transplant organs grew, lesser and lesser crimes sentenced you to prison. One of his stories was about a man arrested that knew he would be sentenced to the organ bank. He escaped, caused murder, mayhem and destruction, then was insulted that when he was caught again they only convicted him for his original crime - his 3rd minor traffic offense.
|
|
|
|
|
Wordle 1,128 4/6*
⬜⬜⬜🟨🟨
🟩🟩⬜🟨⬜
🟩🟩🟩⬜⬜
🟩🟩🟩🟩🟩
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Wordle 1,128 3/6
⬜⬜🟩⬜🟩
⬜⬜🟩🟩🟩
🟩🟩🟩🟩🟩
Within you lies the power for good - Use it!
|
|
|
|
|
🟨⬜⬜⬜🟨
🟨🟩⬜🟩⬜
🟩🟩🟩🟩🟩
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
Wordle 1,128 4/6
⬛⬛⬛⬛🟨
🟨⬛🟩🟨⬛
🟩🟨🟩⬛⬛
🟩🟩🟩🟩🟩
Ok, I have had my coffee, so you can all come out now!
|
|
|
|
|
Wordle 1,128 4/6
⬛🟨⬛⬛⬛
🟩🟩🟩⬛⬛
🟩🟩🟩⬛⬛
🟩🟩🟩🟩🟩
Jeremy Falcon
|
|
|
|
|
Wordle 1,128 5/6*
⬛⬛⬛⬛🟨
🟩⬛⬛⬛🟨
🟩⬛🟨🟨⬛
🟩🟩🟩⬛⬛
🟩🟩🟩🟩🟩
|
|
|
|
|
As a big DEC fanboi, I often have to quote...
"There is no reason anyone would want a computer in their home."
Ken Olsen, president, chairman and founder of Digital Equipment Corporation (DEC) 1977
(As I did a few moments ago on another thread.)
But earlier this month I read a book by John Kemeny -- creator of BASIC. "Man and the Computer", 1972
He makes some predictions through the year 2000. Some pretty much correct, others not so much.
Mainly he predicts people using teletypes or terminals at home to dial into their networks to work on a dozen or so central computers.
Where he was wrong was that home computers were about to be a reality -- and few people would use a dumb terminal at home.
But still, technology aside, he describes such activities as using a computer to order groceries for home delivery. And E-mail, news reports, etc.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
