
Good and Bad Technical Debt (and how TDD helps) (2013) - Brajeshwar
http://blog.crisp.se/2013/10/11/henrikkniberg/good-and-bad-technical-debt
======
mherrmann
Nice article. I’m also a big fan of Acceptance Test-driven development. If
anyone is interested in ATDD for web apps, they should check out Helium
([http://heliumhq.com](http://heliumhq.com)). (I’m one of the cofounders). It
lets you write executable test scripts of the form

startChrome();

goTo(“Google.com”);

write(“Helium”);

press(ENTER);

click(“Helium – Wikipedia”);

assert Text(“Helium is the second lightest element”).exists();

This is Java, Python bindings are also available. Note how no reference to any
HTML source code properties is required (thus the tests can be written in a
TDD style, before the implementation).

I should also point out that Helium is a commercial product, so you (/ your
company) has to pay to use it.

~~~
giulianob
Does your product provide proper page objects? The way it's used in the
examples (where the test specifies the direct page interactions) will quickly
create difficult to maintain code. For example,
[http://canvascode.wordpress.com/2013/11/20/maintainable-
auto...](http://canvascode.wordpress.com/2013/11/20/maintainable-automated-ui-
tests/)

~~~
mherrmann
Good question. The answer is no. You still need to write the page objects
yourself. But it's much easier. Compare

driver.findElement(By.xpath("//input[@type='text' and @value='First Name']");

with

TextField("First Name");

Helium makes it much easier to identify the elements of the PageObject.

~~~
giulianob
I just recommend instead using a custom data- attribute to identify your
elements so you don't rely either on text, HTML structure, or CSS classes
since all of those can change but may not affect functionality therefore
should not break your test.

~~~
mherrmann
That's surely a good solution. It requires write access to the source code of
the web application being automated though.

That's not to say that Helium is a silver bullet. It certainly always depends
on the context. For instance, I know of a bank here in Austria that generates
a lot of the Java source code for their internet banking app from an abstract
model. They also generate page object code immediately from this abstract
model, which is therefore always up to date and precise. This is one example
where I would say using Helium would probably not pay off.

------
LargeWu
There's a slightly different take on this that was presented last year at
RailsConf

[http://confreaks.com/videos/2448-railsconf2013-of-buyers-
and...](http://confreaks.com/videos/2448-railsconf2013-of-buyers-and-renters-
and-keeping-a-roof-over-our-heads)

tl;dr: Different kinds of technical debt have different interest rates. Paying
loan shark or credit card rates for a long time is bad. Paying mortgage rates
is fine. Not having any technical debt means you over payed up-front.

~~~
wwweston
That's probably about as true as saying "not having any financial debt means
you overpayed up-front" \-- which is to say, yes, it's possible there's an
opportunity cost which means you don't make an economic profit. But it seems
to me this isn't always legible, and beyond that it's difficult to think of
any situation in which it's more expensive to pay up front if you have the
option.

A lot of times you _don 't_ have the option because your resources at hand are
scarce compared to what you need/want to buy, so debt is part of the calculus
of allocating your current and (hopefully) future resources. And that's fine.
It seems to me that's different from saying "no debt means you overpaid up
front."

Plus, that sounds like the kind of thing non-technical management might deploy
to neutralize discussion without having to engage with the issues at hand.

~~~
aleem
If you over-engineer today and then fail tomorrow you'll lose a lot more out
of pocket. If you build an MVP and then fail you'll lose a lot less. In the
over-engineering scenario you will essentially have "overpaid upfront" when
you do fail. The amount overpaid is relative to what you could have paid.

~~~
wwweston
This strikes me as being a different problem that needs a different metaphor
-- over _buying_ up front rather than overpaying. Or, as people sometimes say,
scope creep.

------
znep
These graphs are almost identical to the graphs of all too many Java
generational garbage collection cycles I have seen in my life. Eden is the
stupid stuff you do when figuring stuff out that hopefully never makes it into
a commit unless shit gets crazy, survivor space makes it into a commit and
maybe a release but hopefully gets cleaned up quickly, then once in a while
you have a cleanup of the tenured generation.

This is when you eventually come back and do some bigger refactoring and
cleanup to drop back down before you hit your ceiling. But you have to decide
if you want to stop all other development while you do this, or if you can be
smart and pull off tricks to coordinate doing the work while stuff still
happens and/or parallelize it without having too much overhead. All without
really knowing for sure where the ceiling is because other stuff is going on
outside of your JVM.

If your major GCs can't successfully clean up your survivor space then you end
up caught in a loop of endless GC attempts without making progress, looking
for anything you can clean up or refactor to reduce TDD, with very little
success. You start wondering if it is even possible or if you should just
SIGKILL it all and start over.

Sadly, the TDD side of it doesn't fit into this analogy ... at least not yet.
You could definitely work the dark side of TDD into this though... brittle,
inflexible poorly factored tests that are in and of themselves technical debt
and take up valuable memory you could be using to scrape by.

------
davidgerard
Yep. Technical debt analogises to financial debt quite well. It's not as
fungible, but similarly you can fall into debt, take on debt in a planned way,
discover you're not as clever at managing it as you thought you were, etc.

I also highly recommend Denise from Dreamwidth's famous post on the subject,
which is a great intro to the concept for not-so-technical people as well (it
was written to explain to the user base what they'd been doing):
[http://denise.dreamwidth.org/57248.html](http://denise.dreamwidth.org/57248.html)

------
wtbob
> All this begs the questions “yes, but How?”.

No, it _raises_ the question.

Otherwise, a great article.

