Thomas Pepe

  Home  |   Contact  |   Syndication    |   Login
  11 Posts | 3 Stories | 13 Comments | 0 Trackbacks

News

Article Categories

Archives

Post Categories

tellerb

Myth 1: Sloppy code is like a loan (technically)

Technical debt is commonly thought of like this: We can just borrow technical debt from the software development process like you would from a bank (by the way in our metaphor the loan agents at the technical debt bank work for our company).  Then later, we will pay off that debt in incremental payments.  Again, we own the collectors and can put off their demands until later.  Although technical debt can be a useful term and the metaphor works for describing the unavoidable cost of taking coding shortcuts and how that cost increases with time; The term "technical debt" is often used to describe what is actually sloppy code

Technical debt isn't sloppy code and the terms should not be used interchangeably.  Technical debt is a deliberate tactic taken to overcome obstacles to reach a goal.  Whereas sloppy code is often a misguided attempt at get-er-done.  Technical debt is a welcome part of a healthy development life cycle.  Sloppy code is not.

The shortcomings of sloppy code are too often unclear understanding or unclear description of: the problem domain, the specific problem intended to being solved, or the procession of steps that follow one another. These rarely result in faster, cheaper, or less complex applications.  Piling on more and more sloppy code can even bring a project to a scratching halt. (I’d like to see a bigger monetary loan do that.) 

Technical debt when used properly should be done sparingly and with certainty that it won’t cost until after some tangible benefit is realized, like customers interacting with the product.  If we are “paying the price” for technical debt before then I think “technical debt” is really a poor name for what is being done.  It’s really more like technical robbery.mb101310_02

 

Myth 2: Sloppy == fast

Just because you are being sloppy doesn’t mean you are making progress any faster.  If this is common sense then why do so many projects seem to loose sight of it.  If technical debt is getting in the way before the code has even been released it may be a bigger issue than simply “getting our hands dirty” to get the job done.  Calling a problem technical debt won’t alter the effects of a poorly understood problem domain, an inappropriately skilled technical staff, or poor management of resources.  Nor will it make up for directionless and ambiguous code.  

Heads down development at a time when knowledge workers should be “heads up” questioning is like going 100 miles per hour in the wrong direction. Unlike technical debt writing junk code gets us further from our goals, not closer.

 

Part 2 coming in two weeks…

posted on Tuesday, March 6, 2012 1:03 AM

Feedback

# re: Myths about Coding Craftsmanship part 1 3/9/2012 8:51 PM Developer Dude
Or sloppy code could just be due to incompetence - the inability to write quality code regardless of the amount of time spent.

# Re: Incompetence 3/12/2012 9:23 AM Tom
That may be true but I want to address the bad code that otherwise talented and knowledgeable developers allow themselves to write. Even inexperienced / naive coders can write high quality code if the proper guidance is in place and even experienced developers can write code with any number of problems down the line when the wrong environment discourages coding craftsmanship.

The discussion I would like to have is 1 to defend the practicality of craftsmanship when it comes to code and 2 determine what can be done to foster higher quality code within our offices.

That said, the issue if incompetence in software development is worth discussing. Perhaps I can bring it up in a future blog. Cheers.

# re: Myths about Coding Craftsmanship part 1 3/13/2012 7:45 AM ari tikka
sloppy code is interest of the competence dept

ari

# Competence 3/13/2012 12:08 PM Tom
Thank you, Tikka. This is precisely what I want to talk about. Talented developers can have good reason for writing code with technical debt (assumptions) in order to release a product on time and including an expected feature set using limited resources. Sloppy code can be written by talented developers if they don't make / stick to a plan or perhaps even if they have given up.

Incompetent developers aren't capable of writing "good" code. I really think the pool of incompetence is smaller than you think. Many people who write "bad" code can probably improve. Many who write "good" code can probably improve as well. I hope we can have a discussion soon about strategies that would make it easier for people to transition to better code.

Post A Comment
Title:
Name:
Email:
Comment:
Verification: