-
You’ve talked a lot in the past about releasing regularly and constantly having a shippable product. At the same time, companies like Google and Facebook have the “single branch” approach where everyone commits to the master branch, so anyone can break anything at any given time. When you’re operating at the scale of these companies, with thousands of developers, do you think the approach of continuous deployment to one branch is flawed?
-
You mentioned in your lightning talk about being naive in the face of expertise that you had assumed it was an immutable fact that developers would never like writing tests. As students, much of our work is graded by an autograder where other people take the time to write the tests, and we generally only have to worry about writing the code. Do you think teaching computer science in this way reinforces the idea that developers should not be worrying about testing? And how do you think CS education should change to adapt a test-first approach?
-
I know that Agile scrum is supposed to be practiced on small teams, I’m curious as to what are the effects that team size has. Say, if you have a growing project, what would be the pros and cons to splitting up teams as size increases versus keeping the same teams and just have them grow from a small size to medium size.
-
While practicing Agile scrum, I know that ideally all story points that have been committed to during the sprint are supposed to get completed. In actual practice, that doesn’t always happen. In this case, what would you recommend as a solution? How to handle this carryover
-
Related question to this: say you’re in a situation where you have a large story that is just about done at the end of the sprint but there’s only just one small part left in it (i.e. review). What’s your view on claiming “partial credit” for this story in the sprint that just ended, thinking to help the team’s velocity to be reported more accurately, and then create a new smaller story in the next sprint to finish up the work?
-
I had a previous internship experience where software updates were made first and then unit tests were written. A different developer wrote the tests than the developer who made the updates and the test-writer wasn’t supposed to look at the software updates. Would this practice of development independence give the same benefits as test-driven development, what are your thoughts?
-
How would you explain the difference between Scrum and XP, as instances of Agile?
-
Are there companies that follow XP ad literam, ie, TDD and pair programming for everything?
-
-
Save marick/0a092c6c23cc60aa0af7ebcb8a6df74e to your computer and use it in GitHub Desktop.
You mentioned in your lightning talk about being naive in the face of expertise that you had assumed it was an immutable fact that developers would never like writing tests. As students, much of our work is graded by an autograder where other people take the time to write the tests, and we generally only have to worry about writing the code. Do you think teaching computer science in this way reinforces the idea that developers should not be worrying about testing? And how do you think CS education should change to adapt a test-first approach?
TDD is an effective technique but it takes a lot of practice to do it well so it's a tough thing to teach someone that is also learning something that is not TDD at the same time. Justin Searls wrote an excellent post about how teaching TDD can end up with people becoming disillusioned with it if they find what they learned doesn't (initially) work well against real-world problems: http://blog.testdouble.com/posts/2014-01-25-the-failures-of-intro-to-tdd.html which I recommend, I found it helpful.
While practicing Agile scrum, I know that ideally all story points that have been committed to during the sprint are supposed to get completed. In actual practice, that doesn’t always happen. In this case, what would you recommend as a solution? How to handle this carryover
In my experience the First Rule of Agile Teams is to admit "that you're not doing real Agile"; having been at a nominally Agile development organization for over a decade, I have never been on a team that worried about this. If you are in close contact with the people that are accepting the delivery of what you're making, then they know what your status is. The story points stuff is primarily useful in helping talk about how much work you think something is going to take, but no plan survives contact with the enemy, as they say.
Related question to this: say you’re in a situation where you have a large story that is just about done at the end of the sprint but there’s only just one small part left in it (i.e. review). What’s your view on claiming “partial credit” for this story in the sprint that just ended, thinking to help the team’s velocity to be reported more accurately, and then create a new smaller story in the next sprint to finish up the work?
To answer a question with a question: is it possible to break your larger story up into something smaller that would be worth showing to customers? If so, make that a slice and finish that, and then work on the next slice. The main thing I would caution against is something like "it's done except for 5 bugs.": if you want to call a story done you should feel comfortable walking away from it as it is.
I had a previous internship experience where software updates were made first and then unit tests were written. A different developer wrote the tests than the developer who made the updates and the test-writer wasn’t supposed to look at the software updates. Would this practice of development independence give the same benefits as test-driven development, what are your thoughts?
No.
Many of the benefits of test-first development come from the salutary effects of growing the code incrementally using the tests to help make a usable and testable API. You'd lose out on those benefits in that setup. I'd recommend sitting those two people at the same desk.
I don't work in an organization of that scale but I do work on a trunk-based project like that. It's possible for anyone to break anything at any given time but you apply safety procedures to mitigate that risk. In my team's case those procedures are: