• 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
  • Paul Clapham
  • Jeanne Boyarsky
Sheriffs:
  • Devaka Cooray
  • Junilu Lacar
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Tim Holloway
  • Claude Moore
  • Stephan van Hulst
Bartenders:
  • Winston Gutkowski
  • Carey Brown
  • Frits Walraven

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

 
Greenhorn
Posts: 21
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.
 
Sheriff
Posts: 13176
219
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: 63461
207
  • 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: 20510
115
Android Eclipse IDE Linux
  • 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
Sheriff
Posts: 13176
219
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: 20510
115
Android Eclipse IDE Linux
  • 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
Sheriff
Posts: 13176
219
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
Sheriff
Posts: 13176
219
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: 488
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's that smell? Hey, sniff this tiny ad:
Become a Java guru with IntelliJ IDEA
https://www.jetbrains.com/idea/
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!