Comments by "Michael Stover" (@michaelrstover) on "Continuous Delivery" channel.

@aurelienrb If one is doing trunk-based dev, one would run the tests locally before pushing. Mr Farley uses Pair programming for reviewing, so the code is already reviewed.
1
@aurelienrb We do pair programming remotely. I actually like it better than in person pairing. And I do gradual, incremental changes without the sandbox of a branch. There are other ways to sandbox.
1
"As a user, I would like this web app to look nicer". I don't know what I'd do with that. If a story doesn't come with well-defined acceptance criteria, how can I know when I'm done? Whenever we have this kind of story, it bounces back and forth for days between dev and qa folks in disagreement about what "nicer" means.
1
@ModernSoftwareEngineeringYT Your main example is "make it easier to find a song". And the problem is the same. The only way this works is if we have a real extreme programming setup and the stakeholder can see results multiple times a day to provide feedback. Otherwise, I try something, get feedback a day later, try again, get feedback a day later, try again... All trying to guess what "easier" means. It's no wonder we get to the point of demanding stories come with acceptance criteria so we have a prayer of getting it done.
1
@andrealaforgia well, you would casually throw out a whole category of capable programmers then. I don't think the world is improved by narrowing the types of people we allow to contribute.
1
My solution would be a once a day code review meeting done on a single PR for the team. Ie, the team works on a sprint "trunk" during the sprint. Every developer pushes changes to it as they work. Once a day, the team gathers (perhaps in place of scrum standup) and goes over the committed changes since the day before, resolves issues and merges the PR. Obviously, your teams would have to be small (ie, no more than 5 devs).
1
Dave, do you worry your efforts to train humans to engineer software better will soon become obsolete? I tend to think no current 10-year-olds will have careers as "software developer".
1
Seems as though if you judge the "probability" of needing to do some big change in the future as pretty low, then using that to determine the future cost can leave you in a position where it is logical to do fairly little up front to reduce the future cost, but then if that need does in fact arise, there's no way it looks like the right decision in hind-sight. Once faced with the reality of the big expensive re-work, most people will be saying "oh we screwed this up so bad, let's NEVER make that mistake again!"
1
Write a test for behavior that doesn't yet exist. Assert the behavior does what it's supposed to do. Run the test and see it fail on that assertion.
1
@alesgaroth Also, in my experience, a complex UI with automated UI tests will have flaky tests that sometimes fail and require in depth investigation to determine if the failure was "real" or just happenstance. Further, when making a software system with a very large portion being a UI in a browser, how do you write that code TDD? Are you going to startup your browser environment for each test? I'd be snoring by the time it was ready.
1
So if a customer calls your company to report a problem, do you expect developers to be on all those calls? Or do you expect a customer support person to try to help the customer and, if necessarily, create a bug report that goes to the dev team? I don't quite understand what's being suggested for this scenario.
1
@upgradeplans777 Ok, but you didn't really give real answers, you just basically asked "don't you want it to be better?", which ultimately doesn't help. And no, I can't get support-level access.
1
To my ears, no one makes as much sense as Allen Holub. Mr Farley a close second :-)
1
I suppose the "huge surface for security vulnerabilities" maybe refers to the idea that you're goal is to make a new REST endpoint or something, and your first step was to activate the end point and then get busy over the next few weeks making it work.... Well, maybe don't do that. Make an encapsulated module/package/whatever with a testsuite that does the work the business logic. Connecting it up to an active endpoint might be the last step you do. Also, feature flags can turn such things on/off. So, it's in the code, but it's "released" until ready.
1
If you're going to replay my order every time you restart your system, exactly how many copies of your book are going to get piled on my doorstep?
1
@ModernSoftwareEngineeringYT I must be misunderstanding something. If it replays everything that ever happened since the beginning of time, then every restart would take longer and longer than previous ones.
1