Comments by "Dean Schulze" (@deanschulze3129) on "Where Agile Gets It Wrong" video.

@ContinuousDelivery - You are very fortunate if you can trust your team members so much that you don't review their code. That kind of trust is rare. The vast majority of teams use the trust but review approach.
3
Bingo. We need rigorous testing of the various ways of developing software to see which practices work, and which do not. No one has tested pair programming against solo programming. Controlling for all the variables would be challenging, but without such tests saying one practice is better than another is subjective. It's worth noting that agile consulting was born from a single failed project -- the C3 project at Chrysler in the late 1990s. But that team was the self-anointed best team in the history of software development so who are we to question them.
3
Another reason that pair programming is no substitute for code review is that in some organizations your code has to be reviewed by multiple developers. In some cases one of the reviewers has to be an architect.
3
@McGrigorNZ - We keep hoping that Dave will break out of his cocoon.
2
The best comment by far. You cut right to heart of the issue.
2
Good point. It would be a judgement call when to create a feature branch. Like a surgeon deciding which procedure to use in a particular case. Unfortunately, too many mangers and architects aren't willing to let their developers make that call.
2
@ForgottenKnight1 - I said it was unfortunate that managers are not willing to let their developers make that call. It would be better if managers would let their devs make that call.
2
A non-dogmatic approach would be to say that you don't have any metrics showing that TDD or pair programming works better than anything else. They work well for your team because you hired developers who want to work that way. If TDD and pair programming worked better than the alternatives then after two decades there would be strong evidence for that. But there really aren't any metrics showing TDD and pair programming are superior. Dave is right when he says that arguments from authority aren't sound. So why does he use Carl Sagan as an authority? At 8:33 he says "...the necessity of having a model of why A works better than B that allows you to compare it to the alternatives." Models need to be tested, though. When did you test the different practices of software development against each other controlling for all the variables? It's ironic that an advocate for test driven development ignores the need to test the practice he advocates against alternatives. Dave cites SpaceX as an example of the success of TDD. But the flight control software for the space shuttle was written using waterfall. Why did he leave that out? These two examples show that very different practices can succeed in producing large, complex software systems. Neither is a reason why anyone should adopt those processes, however. This is a kind of argument from authority: 'SpaceX uses TDD so should you' https://www.fastcompany.com/28121/they-write-right-stuff
2
@ContinuousDelivery - Ummm, that's what I wrote. SpaceX was written with TDD and the space shuttle was written with waterfall. Unless you're objecting that I left out Trunk Based Development. TDD and Trunk Based Development are two different things. You still need to come to grips with the fact that waterfall has produced a lot of very good software.
2
@ContinuousDelivery - And that lack of good data is the real problem. Given the importance of software development to the global economy we really need good data. Not data on student projects, but data on real projects done by experienced developers. What is needed are controlled experiments on real-world projects using professional developers. That would give us reliable data. No one is even talking about doing realistic experiments on this scale, however. But we need them.
2
@leesoftwareengineer - Unit tests are coupled to the implementation at the function/method level. That's why they are unit tests instead of integration level tests.
1
@TonyWhitley - When has TDD ever required higher level testing like integration testing? It's always been about JUnit level testing.
1
@jprince1993 - Testing the public APIs is vital. It makes much more sense than exhaustive testing at the method level. I've never seen a TDD advocate say that testing should be at the public API level, however. It's always JUnits at the method level.
1
@BernardMcCarty That test was done using college students, not senior developers so it's pretty much worthless. Also it was a one week project that was part of a course so it was very artificial. I've not seen a realistic test protocol that controls for all the variables of software development, let alone a realistic test.
1
@ContinuousDelivery - Can we see links for those small scale experiments? I never said there was data for any approach. That's the problem, and no one should go around saying their preferred software practices are supported by data. Your preferred practices are pair programming, TDD, and trunk-based development, correct? Any other practices to your methodology?
1
Dave, I finally got a chance to look at these. Your first two links are 404s. Your third link say just the opposite of what you claim: "Results: TDD novices achieve a slightly higher code quality with iterative test-last development (i.e., ITL, the reverse approach of TDD) than with TDD. ... The quality-related performance of professionals using TDD drops more than for students." You previously asked me where the data is that shows that TDD is inferior. Ironically you provided that data. Why can't you be honest about this?
1