Comments by "Andrea Laforgia" (@andrealaforgia) on "Kent Beck On The FIRST Testing Frameworks, TDD, Waterfall u0026 MORE | The Engineering Room Ep. 16" video.

  1. But you customers can start using those features straight away, even though feedback on those features comes a few hours/days later. The important thing is to always keep your system in a releasable state and optimise for complexity, so if anything needs changing, it can be quickly done.
    2
  2. Waterfall has never been the answer. There is a common misunderstanding in the industry that Waterfall is a “model”. No one — and I mean no one — in the history of software engineering has ever presented a “Waterfall model”. The idea that software had to be developed in subsequent phases was adopted by the US DoD. They never understood that what Dr. Winston Royce was presenting in his 1970 paper on how to manage the development of large systems was a model to avoid (he wrote something along the lines of “don’t do it this way, it invites failures”) and proceeded to explain how to produce those systems iteratively. He even mentions involving the customer in a very similar way to what the Agile Manifesto describes. Royce himself was a supporter of iterative and incremental methods. The industry understood the opposite and a “Waterfall model” dominated it for 20 years, until the adaptive methods reemerged and Agile was formalised. We have always knows, however, that software should never be implemented with a “Waterfall model”. Customers don’t need predictability. That’s an extremely common fallacy. Customers need a software that solves their problems. They only need predictability when needing predictability is the only option we give them. If you ask me for a software, and I tell you that you’re going to get it at some point in the far future, then of course you want to understand how long it’s going to take and how much it’s going to cost you, before you embark on a journey where you won’t see results for a long time. If, on the other hand, I agree with you to release limited-scope features continuously, frequently, so you can evaluate them, give feedback and adjust, limit your financial exposure, and decide, at each step, if you want to continue investing in the product or not, you are not going to need predictability. Remember: “Waterfall” was never a model for software development. We have known that software must be developed in iterative and incremental ways for 70 years now.
    1
  3.  @adambickford8720  If you are saying that a lot of companies implement a fixed scope + fixed budget + fixed time policy and they come up with hefty fees when you don’t deliver according to their fancy dreams, you are right, but that’s only because they have not yet understood the nature of software and insist on applying a model that DOES NOT work for software. The people demanding that way of working are the same that object to the (sensible) arguments against long-term estimates in software starting their sentences with “Well, if you build a house, you want to know…”. Software is not houses. Companies that adopt those contracts are not successful at delivering software. It’s proven by data. The 2015 CHAOS Report front the Standish Group collected data from the industry proving that Agile is 3x more successful than Waterfall and Waterfall is 2x more likely to fail, so yes, Agile is the right answer for software development. But, as I said, we already knew that. There are a lot of different agile contracts that can be adopted to implement software agilely.
    1
  4. I’ve been applying that idea for a very long time now. It is a very natural thing to do once you have some experience. I tend never to mix behavioural changes to structural changes. If I noticed, for example, a typo, or I spot a function that needs implementation (not interface) refactoring, I do that in a following PR (to be done soon after the one with behavioural changes I’m working on). PRs, for me, must have a very limited scope.
    1