Which is better, elegant untested code or ugly tested code?

We periodically pose a question to our devs on slack, then post the lightly edited conversation here.

Hacky-Slack Logo

Our first Hacky Slack question comes courtesy of Sam:

sam

I keep thinking about this premise. If you had to choose development priorities between elegance and testing, which would you choose?

A. Elegant code that is released with minimal testing, or

B. Poorly written code that’s been tested thoroughly before release.

Any insights?

danny

Gah. Both are bad, but I guess I would go with B if I absolutely had to choose

sam

I think B pretty well sums up most of the toy industry…

(which I often found pretty frustrating)

danny

In the past, we’ve seen what chaos can happen when folks have made an elegant but untested change…

sam

yeah, it was an attempt in the direction of elegance…

dylan

Elegant code is also much easier to unit test though.

Testing messy code can mean a system is thoroughly tested, but the code isn’t really tested

marc

the really annoying thing about this scenario is that “tested thoroughly” means “we have run it a bunch of times and nothing too bad has happened yet” and not “we have a well-developed test suite that we can use for future work”

dylan

I’m just thinking back to last June when I made a document for a client about how we should refactor their code to make it more elegant, two of the reasons being “it’s easier to test, and it’s harder for bugs to sneak in”

skot

Messy code puts so much pressure on the dev engineers, since they are the only ones who really knows how the messy code works.

dylan

Yeah, that too

sam

so, is the sweet-spot for production: decent, testable code that gets thoroughly tested?  Since elegance usually takes too long for production and really gnarly code is not really testable (not to mention a nightmare to maintain).

dylan

Yes, though I’d argue a degree of elegance doesn’t have to be so time consuming.

sam

and maybe bonus points if it it leads to it being more testable…

danny

I think it’s important to think about the tests just as hard or harder than we think about the code. I think that’s what’s really missing in many implementations

It’s not a pure software example, but an example anyways: Skot probably spent ~4 person-months designing our Data Logger’s original hardware and firmware, then another ~6 person-months designing the test jig and test automation suite.

dylan

Don’t get me wrong, developing the testing part is way less fun, but it’s the organization’s job to prioritize that.

Bottom Line: A or B?

danny

I would still go with ugly code that has been well wrung-out (not using the word testing here on purpose because happy-pathing stuff repeatedly isn’t really testing)

but I want to emphasize that this is definitely a “do you want me to cut off your hand or your foot” kind of question

zeke

Good code tends to be a lot easier to read and test, so it’s not an equal time effort to do either

Legibility and testability might be actually what makes it good code

dylan

Also in my experience, code that is more clear and legible is more likely to do what you intended it to do. Granted, sometimes your code can’t be super simple, but still. If it’s broken up into more simple chunks it’s more likely to do what you meant it to.

skot

It depends on the application.

  • NASA: This cannot fail, but we’ll only use it once → B
  • Tesla: Maybe some things can fail, but we can OTA → somewhere between B and A
  • Facebook: ship it! → A if there is time