Comments by "Dean Schulze" (@deanschulze3129) on "Continuous Delivery" channel.

@jangohemmes352 - Please explain how unit testing the various functions in a microservice makes the entire service scalable.
1
The idea that predictability is bad because we are going to learn so much so fast that our velocity will increase a lot during the course of the project is just fantasy. That might be true for new grads figuring out how to use source control, or for teams made up of developers who don't have any experience in the tech stack they are using. But not for teams with senior developers and architects.
1
@dafyddrees2287 Yes, corporate bureaucracy makes the C levels feel comfortable while trusting their engineers is just unthinkable to them. Like a life without cigarettes is unthinkable for a nicotine addict. So in that sense the analogy works.
1
@JordanEdmundsEECS - I appreciate your insights onto the difficulties of testing UIs. But have you ever written a backend that was a distributed system? Unit tests are worthless on distributed systems. You need to test the entire system as it will be deployed in production.
1
That kind of thing happens all the time.
1
@talideon - Pivotal need to hear that. They seem to demand 100% pairing. I've been "pair programming" quite a bit lately since I'm learning a proprietary Angular framework. It has a long learning curve. One hour a day or so of screen sharing is typical. I've also found that I need to think things through on my own before I have really learned a new API. Listening to someone else talk me through it is OK for an introduction, but I have to work with it myself to really learn an API. Having to recall things from memory is an essential step in cognition.
1
Partitioned data has its downside. When you denormalize data and a microservice updates its data any other copies of that data in other microservices also need to be updated as well. This means eventual consistency. There are several ways to handle the data consistency problem, but they all add complexity and end up coupling the services at some level.
1
4:50 Why didn't they rollback the change? Rollout the FIX just as quickly? Oh my. The patch leaves the system with a BSOD. You can't rollback from a BSOD. That requires manual intervention. Dave sounds like the Joe Biden of software.
1
You need integration tests if your code integrates with another application. Unit tests are almost worthless when writing a distributed system.
1
Farley starts out by saying that feature branches are bad. Everyone should commit to the same branch (the trunk). I can see some benefit to that. It may reduce merge conflicts. But then he goes from talking about the problems with pull requests to advocating pair programming. If pair programming is as beneficial as he claims it would be widely used. That goes for the other fads that consultants push, like TDD. Uncle Bob Martin used to go around saying the TDD would become the minimum standard for professional conduct in software engineering. He likened it to surgery with and without anesthetic. Maybe you've notice that uncle Bob hasn't been as vocal about TDD defining the boundary between professionals and amateurs. That change happened when I called him out on one online forum and asked him point blank if he considered Linus Torvalds and Peter Norvig to be amateurs because they didn't practice TDD. The dirty, unspoken secret of pair programming is that it comes with mandatory hours. There's a company that does real estate analytics that I really wanted to work for because I love real estate. Their recruiter called me and told me, with resignation, that they had hired Pivotal to setup their software development process and Pivotal had mandated PP with mandatory hours of 10 - 6. She said that she had not been able to hire any developers who wanted to work under that regime. I told her that I wouldn't be a good fit for that regime either. Now maybe Pivotal was being crazy like a fox. They dictated a regime that no one wanted to work under, so this company would be left with no other choice but to outsource their software development. Maybe to a company like Pivotal. Maybe there are problems with PRs, but there are much bigger problems with PP. And PP advocates don't want to discuss them publicly.
1
@Macknull Do you have any data to back up your claims that the results for studies done on students are also true for senior devs?
1
@kasperstergaard1592 OK, but trunk-based development doesn't mean pair programming. One way of doing development is that everyone commits to trunk and branches are for releases.
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
Or how about if TDD advocates started explaining TDD properly instead of just complaining that all explanations are wrong. Unit tests are worthless in a distributed system. You need to test the entire system deployed the way it will be deployed in production. I've yet to hear a TDD advocate explain how to TDD a distributed system. They can't seem to get past unit testing.
1
This video touches on what software development has become in the last decade. You have application code. You have IAC code in Terraform, Cloudfromation, Pulumi, etc. You have pipeline code in github actions, etc. What does this mean for TDD? I'd like to hear how you would TDD your way to a realistic cloud application, for example a real-time data pipeline in one of the clouds. Is TDD even relevant for provisioning resources in the cloud?
1
Unit tests are worthless in a distributed system. That should be pretty obvious.
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
@ComradeOgilvy1984 - I don't think the Wright Brothers is a good analogy for software development. They had to create the field of aerodynamics while they were creating powered flight. They created the first wind tunnel. They did a lot of work on internal combustion engines getting a high power to weight ratio. They had their own engine builder. That would be like developers having to create their own language and compiler while they were creating their application.
1
Studies based on students are worthless on professional teams where developers typically have 5+ years of professional experience. Students are often learning the basic idioms and patterns of a language. A lot of students don't know how to use source control systems. So their experience doesn't translate to the professional world, let alone high performing teams compromised of the top 10% of professional developers.
1
@mistalan Answer his final question. If you try to do that you'll see that your comment is nonsense.
1
@ErikLevin - That isn't what I said. Do you have a response to what I said which is if TDD actually worked better than other processes why isn't it in wide spread use? Respond to my argument, not to its inverse.
1
@someoneelse5005 - Who disagreed with "understand what your code is supposed to do"? You are using a very dishonest tactic in trying to attribute to me something I never said. The rest of your post is unsupported assertions and mindless drivel. The mindlessness is what drives fads that aren't supported by metrics or data. Come back when you have some data to back up your claims. Until then you're just a mindless fanboy.
1
@Ashton666 - You love to make unsupported claims. You assume as an article of faith that "TDD is in the best interest of ALL of those involved in software,". Neither you nor anyone else has shown that. You say it "can be mathematicaly shown to be wrong!" that "humans have all the needed knowledge to assure the a given decision leads them to their best interest". But who ever said that? Or even assumed that? You create a false assumption and then proceed to show it is wrong. Duh You assume that TDD is some kind of magic that will solve the problem of not having enough information. I said that professionals usually do what they believe is best for their customers and their company, but you've turned this into people doing what they think is best for them. Those are different things. Your writing is incoherent and your thinking is even more so.
1
@ErikLevin - Answer the question. Tell us why TDD has not been widely adopted if it is so good? Do you have any metrics showing that TDD works better than other approaches?
1
@ErikLevin - I meant it as a question that leads to a conclusion: If TDD actually worked better than other approaches then why wouldn't it be in widespread use? My conclusion and that of many others is that it isn't any better than other approaches. You seem to know this when you admit that you don't have any metrics to the contrary. Smoking isn't widespread (at least not in the US). It's pretty rare. Kind of like the use of TDD.
1
Ummm. Linux wrote Linux without TDD. Is that madness?
1
"don't write a specific test for every class" Who agrees with that definition of TDD? TDD advocates say that you have to write a test before you write any code. You need to come up with a new name for what you and Uncle Bob are suggesting. And when did Uncle Bob give up on the normal definition of TDD?
1