TDD is a meme and you shouldn't be writing tests before you even know what your modules will look like.
Writing code is an art form. It takes intuition and freeform thought to structure things.
Couldn't agree more. TDD is workable when you're well staffed and have some discretion over deadlines. Otherwise it's an incredibly difficult sell from a business value standpoint, unfortunately. Especially if you're in an organization where certain delivery timelines are expected regularly
Most of the cost of software is after the initial build. TDD helps keep it decoupled so it's easier and cheaper to maintain in the long term. TDD software probably has better TCO.
😂 In a fit of frustration on Friday afternoon bc I couldn't get specs to cooperate I put this message in slack. I'm kidding of course, mostly....
TDD has its place, in some scenarios it's the only sensible option, but its benefits in general are massively overstated.
Writing code is more like artisanship. I feel I've got more in common with someone who builds bespoke wooden furniture than a painter.
TDD is the only way to create code that is maintainable and extensible. Unless of course, what you are making is utterly simple.
Writing code is a science, not an art. The problem is that humans have spent less than 60 years doing code and we do not have the hang of it completely that is why point 1.
I tend to agree that TDD is a bit excessive, but I strongly believe in a BDD approach which is very common in Domain-Driven Design. Writing the failing test cases that describe how what use cases, policies and rules a system should have is much more likely to be known at the start of a project than if "computeXYCoordinates()" returns false :)
Writing code is a mixture of both!
Computer "programming/coding" is the practical application of such theory. It's also what leans more in the direction of....
_ is the only way to create code that is maintainable and extensible
That's what they said about COBOL.
And when some wise guys at Cambridge said, hey we've invented a replacement to COBOL called "CPL" everyone said "We don't need yet another programming language!"
(CPL -> BCPL -> C -> C++/ObjectiveC -> Java/C#/Swift/Kotlin/Go/Scala/...)
So, I've added another of my unpopular opinions:
We will always need Yet Another Programming Language
Because as Adrián said, we're pretty new at this, and so we need better tools. We're still in the software stone age.
Thank you for the quotation. I have the same opinion. We don't need too many more programming languages and frameworks.
With the programming languages happen the same that with the mobile phones. The unique reason new ones are needed is to make the old ones obsoletes and try to take control of the market.
Can someone really tell me why was Ruby needed in the moment of its creation? What does it provide that could not be added to existing languages?
The principle of "Do not repeat yourself" that science respect is not not followed most of the time.
Or would somebody build an space ship from that material?
Writing code is hardly science, any more than writing fiction is. We are craftsmen and -women, not scientists.
I think the truth exists somewhere in the middle. I did a coding dojo with a brilliant manager a few years back on TDD, and learned a lot about the value of unit tests.
The first advantage is that it gives you a usable API (API is UX). It's all too easy to get tunnel vision and write an unusable API because you've never attempted to use it. The "doesn't compile" step in TDD makes sure that you are trying to use the thing before making the thing.
The other advantage is that it prevents you from solving problems that don't exist. The specific example we had was roman numerals. At the start of the session I felt a bit of dread: roman numerals are, superficially, pretty hard to parse. Working through "I" to "III" to "MCVIII" resulted in a complete solution that was far simpler than the one I conjured up before we started coding.
But, you'd never get anything done if you followed TDD strictly.
I think the middle ground is writing your code while visualizing the test. This ensures that you are writing units (which are easier to use and obviously easier to unit test).
Write the code. Does it work? Write a test to prove it. Write more tests as you think of ways to break it.
Found a bug? Fix it. Write a test to prove it was fixed.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.