Live data from Hacker News

How to Write Unmaintainable Code (1999)

doc.ic.ac.uk

71–72 of 72 posts

Re: How to Write Unmaintainable Code (1999)

#71
post #40

Earlier quoted context omitted.

I can imagine this being more helpful if you lacked access to a debugger, and lacked the time (or desire) to build debugging tools by other means... Which I imagine is plausible in that context.

No, they have debuggers and modern dev tools. They just prefer to read code from paper when they have to really focus on it for a long time.

In my experience, it's less about reading code on paper than it is the other thing you mentioned:

>then they annotate it with a pen while thinking about whatever problems they are solving.

Paper and pen offer a lot of options you don't have in vim (or emacs/notepad.exe/etc ;)). Circling, doodling, arrows, underlining, furiously scribbling...

Re: How to Write Unmaintainable Code (1999)

#72

Earlier quoted context omitted.

TDD will leave you with a load of tests which prevent you from changing the code. BDD on the other hand should leave you with a suite that isn't coupled to a specific implementation. Part of the information contained in a test is the intent of the verification being performed, and part is code for mapping that intent onto the implementation. The latter part can be discarded during a rewrite. Cucumber/SpecFlow etc. ma…

> and part is code for mapping that intent onto the implementation Wait, what?! The more I listen people talking about TDD, the more I discover I always misunderstood it, and the less I want to actually understand it.

The thing is, unit tests that are affordable to implement, are not wort it. Their objectives should rather be verified with language choice, programming techniques, and assertions. Tests that are worthwhile to write are those that test interactions of multiple subsystems. But those are not unit tests any more. If you end up _actually needing_ TDD, then that proves you are using the wrong language and/or the wrong technique.
Post reply on HN