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.
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).
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.
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.
It seems that the theory behind sofware development doesn't matter anymore and the they're is a global hype on languages like Javascript that is dangerous becoming the ground stones of apps without being so mature as language or some optimal for execution.
It is like if some new tech allows to recycle the garbage in a new material javascriptolite and they're is a boom in sell of cars with "futuristic" look, low weight and a hammer toolkit to shape it yourself to the shape you like.
Of course many skilled people will make from Javascriptolite a new market. But some day people will start to read again physics and mechanics.
Or would somebody build an space ship from that material?
That's an unfortunate accident of the English language. It's not a problem elsewhere (mann/frau, uomo/donna, etc). Ask a computer and it would say "woman contains man so the former is more generic".
I think this isn't a fight we should be focusing on, there are much bigger battles to fight for gender equality, this kind of petty and surgical word picking just brings bad name to the whole issue, which so many feminists fail to understand.
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!
It's science!
Computer "SCIENCE" is theory. The way that mathematics, physics and information work together to "determine how many users this application will be able support under peak hours" is a bit of physics, math, and probability all in one!
A very common feature in science is that it's very hard (and sometimes impossible) to prove that something is correct, so we often deem things correct enough if we can't prove it to be false.
That's unit testing :)
Computer "programming/coding" is the practical application of such theory. It's also what leans more in the direction of....
Art!
There are 100s of ways of writing code to perform the same observable behaviour. It takes skill, practice, patience and empathy to create code that is timeless, well-designed and readable for future developers.
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.
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.
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.
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.
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).
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.
Yep.
_ 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.
It seems that the theory behind sofware development doesn't matter anymore and the they're is a global hype on languages like Javascript that is dangerous becoming the ground stones of apps without being so mature as language or some optimal for execution.
It is like if some new tech allows to recycle the garbage in a new material javascriptolite and they're is a boom in sell of cars with "futuristic" look, low weight and a hammer toolkit to shape it yourself to the shape you like.
Of course many skilled people will make from Javascriptolite a new market. But some day people will start to read again physics and mechanics.
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.
The word
Craftsmenhas nothing to do with gender it does mean-womenaswell.Craftswomenis not even a word in English.That's an unfortunate accident of the English language. It's not a problem elsewhere (mann/frau, uomo/donna, etc). Ask a computer and it would say "woman contains man so the former is more generic".
I think this isn't a fight we should be focusing on, there are much bigger battles to fight for gender equality, this kind of petty and surgical word picking just brings bad name to the whole issue, which so many feminists fail to understand.
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!
It's science!
A very common feature in science is that it's very hard (and sometimes impossible) to prove that something is correct, so we often deem things correct enough if we can't prove it to be false.
That's unit testing :)
Computer "programming/coding" is the practical application of such theory. It's also what leans more in the direction of....
Art!
😂 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....
hahahaha