• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Paul Clapham
  • Devaka Cooray
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Frits Walraven
Bartenders:
  • Carey Brown
  • salvin francis
  • Claude Moore

Which things can make Java code hard to debug ?  RSS feed

 
Greenhorn
Posts: 26
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What are the unintentional practices which make Java code hard to debug ? For example, not including source jars. Recursion (language agnostic) ? etc.
 
Marshal
Posts: 13447
222
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Unintentional technical debt. I'm going by the definition that technical debt is a lack of understanding in the code you're working with. Notice that I said "in the code" not "of the code." That is to say, the code does not clearly reflect the writer's understanding of what the code is doing. The code is cryptic, complex, and convoluted. It lacks clarity, coherence, and cohesiveness.

Code that is difficult to debug is more often than not difficult to unit test as well. There will be many hard dependencies that force you to bring them into a test harness, making testing slow and cumbersome. This also contributes to technical debt.
 
Marshal
Posts: 64172
215
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mindprod has a long list of strategies to make code unmaintainable
 
Saloon Keeper
Posts: 20657
122
Android Eclipse IDE Java Linux Redhat Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think my number one vote is this:


I've been nailed by this in C and Java both.

ALWAYS parenthesize your conditional clauses!

BTW, I've always understood "technical debt" to be what you get when you don't keep dependencies up to date. Because software usually rots from the outside in. To me, what Junilu is describing is more like failure to understand and to explain on the developer's part. And if you don't understand it to begin with, your problems are probably going to exist long before the debug phase.
 
Junilu Lacar
Marshal
Posts: 13447
222
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Watch Ward Cunningham's explanation of the Debt Metaphor. In it he says something to the effect of "when the software contains zero understanding, your interest is total and you'll make zero progress."

At a SPLASH conference working session that I attended, we concluded that the currency of technical debt is NOT quality as many people tend to think. It's time. You borrow time by rushing software out the door so you can gain more experience with it. However, if you fail to pay back what you borrowed through refactoring to make the code reflect your increased understanding of what needs to be done, then you will continue to stumble and fumble with the code. When that lack of understanding is complete, you go bankrupt from taking forever to do anything.

Two forms of technical debt:

1. Intentional - code is factored well enough so that it's easy to update once we learn from our early experience with it.

2. Unintentional - code written to "just work" but isn't made to reflect any understanding and isn't refactored to reflect any learnings about what it's supposed to do.
 
Tim Holloway
Saloon Keeper
Posts: 20657
122
Android Eclipse IDE Java Linux Redhat Tomcat Server
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's a completely different world than the one I've been living in.

In the circles I travel in, technical debt is what accrues when you subscribe to the false notion that "software doesn't wear out". Technically, that's true. But the hardware that the software's running on changes over time, as does the OS, and eventually lower and lower levels are affected: as I said, software rots from the outside in.

The debt here is in terms of the amount of work that's required to restore the software in question to full functionality. And just like a loan with interest, the longer you delay paying that debt, the higher the debt becomes.

Until one day the bill comes irredeemably due. At which point the debt is so high that it cascades into the cost of daily operations and you either have to drop everything and do a major repair job or find a replacement product ASAP.
 
Junilu Lacar
Marshal
Posts: 13447
222
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:That's a completely different world than the one I've been living in.

In the circles I travel in, technical debt is what accrues when you subscribe to the false notion that "software doesn't wear out".


This is an example of what Martin Fowler calls Semantic Diffusion where the meaning of a term changes the further away you get from the original usage. This has also happened to the term "Agile Development" in general.
 
Junilu Lacar
Marshal
Posts: 13447
222
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have to say though, as far as semantic diffusion is concerned, your definition of technical debt is not very far off from the original idea. I've seen more diluted definitions that are devoid of any semblance to the original metaphor.
 
Ranch Hand
Posts: 523
Chrome Linux VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When I was just starting out, coding in 8086 assembly, I inherited a routine which I don't remember what it did but had a very odd conditional.  Essentially along the lines of


A bit of testing showed that, indeed, 2 + 3 did not return 5 if I removed the condition.  Dug into the code, found the real problem, and lost all respect for the original developer.
 
What could go wrong in a swell place like "The Evil Eye"? Or with this tiny ad?
Create Edit Print & Convert PDF Using Free API with Java
https://coderanch.com/wiki/703735/Create-Convert-PDF-Free-Spire
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!