Hi, I normally contract in MSBI, SQL, Data Arcitecture, Oracle, .Net/.Net Core, API development, React, focusing on www.cryptostatto.com at the moment. Reach out if you see any synergy.
Agreed that you write a test which fails and the goal is to write enough code to get it to pass. This leads to code which may not be great but "behaves" as expected.
The key thing I have read about TDD is it a design process. It reduces big upfront design decisions. So where you say the following, I cannot agree.
"TDD is the practice of writing software by making unit testing the most important concern."
I did proper TDD ONCE for a cube library I was writing, and it naturally teases out structure. If I found myself really struggling to tease out a design, then TDD can help break it into smaller chunks/units.
Onto the second difference of opinion - Waterfall. I suggest you read - Software Project Survival Guide by Steve McConnell. He outlines, to me, what Waterfall really is about. Keeping a project to budget, and even - canning it early on. In this book he makes the point that an upstream fix is up to 200 times less expensive than a downstream fix. He doesn't say, it can't be done. This idea that once components have been released in an agile methodology, it won't take time to replace them is a myth. McConnell mentions "Thrashing" which would be the TDD phase or prototyping phase of the project. It is a bit like, planning for a journey, and keep changing your mind, but once you are on the journey it is hard to go back. This is normal.
So, many thanks for the article, very useful for many people - but I just think it a bit bold to overly sell the Unit Testing part of TDD, and to put Agile above Waterfall.
As a product guy, I tend to agree that Waterfall is needed in the first phase of the product definition and roadmap creation aspect. But, when you are in the development phase, if requirements were not clear enough , then trying to figure out the requirements while building is not good Agile. I agree that people get confused with Waterfall and Agile. You can have both, Start with Waterfall, lock your requirements, do agile development and then test in waterfall. I have seen too many projects go haywire when you don't respect the need for clarity upfront.
Hi, I normally contract in MSBI, SQL, Data Arcitecture, Oracle, .Net/.Net Core, API development, React, focusing on www.cryptostatto.com at the moment. Reach out if you see any synergy.
Okay, I took a couple of days to think about this (kind of :).
The challenge with Agile is, it is a training tool only. Agile is great as a way to train people who can't communicate, who can't plan, and can't think on their feet - to do that. Once they have those skills, there is no longer a need to keep doing it.
Agile feels like an unnatural, pervasive intrusion into the project. The processes are laboured, draining, and artificial. Conversely, despite Waterfall having many faults - it would be natural, if something wasn't working - to call a meeting. To rename a meeting and call it a 3 Amigos is stupid. Has anybody sat in a 3 amigos, when there are four people, thinking - which one of us isn't our friend? "Burndowns" is an abstraction away from what effective people do - getting things done. Have sat in retrospectives with people literally slashing their wrists because the graph wasn't a perfect line.
Drivers don't continually say 10 to 2. They move past that phase.
A Product Manager loves Agile because they think they have a handle on what the team are doing, and they can bubble up progress - but it isn't true. The tasks lose their meaning and sense, with managers saying things like we are 70% done for this sprint and our burndown spiked at this point. The product owner doesn't have a clue about it. The Product Owner wants to get on with their normal job - not spend all their time with a development team. Every project which is Agile, results in the manager/scrum master not having a Scooby about what people are actually working on.
We don't spend our time, running 2 week sprints, but if we were getting our house renovated we would not undertake an agile methodology.
Again - Waterfall wins because it is a natural process. We discuss what we would like to do, we figure out how long we think it will take, and we start on that journey, and we review it.
Am I fan of Waterfall, not entirely - many times iterative wins, but Agile just sucks.
It is a shame, because the spirit of agile, and the manifesto really made sense. Agile has been hijacked.
Okay, happy Friday.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the article Evandro.
Agreed that you write a test which fails and the goal is to write enough code to get it to pass. This leads to code which may not be great but "behaves" as expected.
The key thing I have read about TDD is it a design process. It reduces big upfront design decisions. So where you say the following, I cannot agree.
"TDD is the practice of writing software by making unit testing the most important concern."
I did proper TDD ONCE for a cube library I was writing, and it naturally teases out structure. If I found myself really struggling to tease out a design, then TDD can help break it into smaller chunks/units.
Onto the second difference of opinion - Waterfall. I suggest you read - Software Project Survival Guide by Steve McConnell. He outlines, to me, what Waterfall really is about. Keeping a project to budget, and even - canning it early on. In this book he makes the point that an upstream fix is up to 200 times less expensive than a downstream fix. He doesn't say, it can't be done. This idea that once components have been released in an agile methodology, it won't take time to replace them is a myth. McConnell mentions "Thrashing" which would be the TDD phase or prototyping phase of the project. It is a bit like, planning for a journey, and keep changing your mind, but once you are on the journey it is hard to go back. This is normal.
So, many thanks for the article, very useful for many people - but I just think it a bit bold to overly sell the Unit Testing part of TDD, and to put Agile above Waterfall.
As a product guy, I tend to agree that Waterfall is needed in the first phase of the product definition and roadmap creation aspect. But, when you are in the development phase, if requirements were not clear enough , then trying to figure out the requirements while building is not good Agile. I agree that people get confused with Waterfall and Agile. You can have both, Start with Waterfall, lock your requirements, do agile development and then test in waterfall. I have seen too many projects go haywire when you don't respect the need for clarity upfront.
Okay, I took a couple of days to think about this (kind of :).
The challenge with Agile is, it is a training tool only. Agile is great as a way to train people who can't communicate, who can't plan, and can't think on their feet - to do that. Once they have those skills, there is no longer a need to keep doing it.
Agile feels like an unnatural, pervasive intrusion into the project. The processes are laboured, draining, and artificial. Conversely, despite Waterfall having many faults - it would be natural, if something wasn't working - to call a meeting. To rename a meeting and call it a 3 Amigos is stupid. Has anybody sat in a 3 amigos, when there are four people, thinking - which one of us isn't our friend? "Burndowns" is an abstraction away from what effective people do - getting things done. Have sat in retrospectives with people literally slashing their wrists because the graph wasn't a perfect line.
Drivers don't continually say 10 to 2. They move past that phase.
A Product Manager loves Agile because they think they have a handle on what the team are doing, and they can bubble up progress - but it isn't true. The tasks lose their meaning and sense, with managers saying things like we are 70% done for this sprint and our burndown spiked at this point. The product owner doesn't have a clue about it. The Product Owner wants to get on with their normal job - not spend all their time with a development team. Every project which is Agile, results in the manager/scrum master not having a Scooby about what people are actually working on.
We don't spend our time, running 2 week sprints, but if we were getting our house renovated we would not undertake an agile methodology.
Again - Waterfall wins because it is a natural process. We discuss what we would like to do, we figure out how long we think it will take, and we start on that journey, and we review it.
Am I fan of Waterfall, not entirely - many times iterative wins, but Agile just sucks.
It is a shame, because the spirit of agile, and the manifesto really made sense. Agile has been hijacked.
Okay, happy Friday.