I am happy to be the thousandth subscriber of this channel 🎉

Hi Billy Bob. Would love to hear your insight on unit testing vs integration testing vs E2E testing. Do you agree with the testing pyramid? I appreciate your knowledge. Please do a video on this ❤

Cool, thank you. I’ll check it out!

I really liked the approach to TDD expressed in the TDD with Python book. He starts out with user stories and the tests become a fairly literal expression of the user story. It also tends to lead to a code structure where the code itself naturally aligns with the functionality you want to express. I find that when I take the time to come up with some user stories and map them to tests in this manner it really helps with creating good tests. When I don't I tend to have a lot of little tests checking some small part of the functionality which tends to become an illegible mess. With regard to mocks, I like to have an option for the mock to go either to the live API or to the mocked result. Too many times I've found a bug because a third party API has changed, or because I made an incorrect assumption about how it behaved when I was implementing the mock and the tests all pass but it breaks when exposed to real world data. Maybe there's a better approach but I find that tends to be a minimal effort for maximum reward version.

Without branches? Really? I generally don't like branches with too much work in it (big releases ones) for the reasons you've mentioned but I don't see how to work with a team of developers without branches at all. Do you let juniors and people new to a project commit code straight into the main/master branch !?

How do you do PRs/Code review without branches?

Thanks for sharing your experience

I didn't know I'm a gambler

TL;DW testing individual components only makes sense for libraries to see if the details are logically sound (most common testing done today) such as having a class named MathTest What the most common testing should be is Given-When-Then output mappings for the given inputs in a class named BusinessClassTest without major concern for details before implementation

On thing I'm going to try you talked about is starting simple. Then if simple doesn't work, look to design patterns. Starting with grand architecture and design patterns leaves me in coder's block, unable to write any code because I've got no clue what to do

Off-topic but we need an answer: Emacs or vi-derrived (vim, neovim...)

This content is so helpful. Please keep them coming.

This video was wildly helpful to me. Thank you 🙏🏾

The only time I leave a comment is with a TODO tag where I plan to comeback and remedy the problem later and remove said comment. I think contract comments are generally fine as long they are kept up to date.. anything else should be auto generated..

I think your camera is out of focus, please check your settings. Audio is perfect.

I never put comments in my code. Wait, do I write code?

The problem with code as documentation is that the code tells you what the program does, it doesn't tell you what the programmer wanted to happen. The ridiculously simple example I use is to imagine seeing the following in a piece of code: // Increment the counter counter = counter - 1; Now without comments a future developer trying to proof read or fix an error in this code has to scan back and forwards through the entire chunk of code to try and figure out what is the error while the commented version will immediately jump out as a mismatch to a reader.

To me a comment is either a lie or an apology.

If you're not completely familiar with the codebase and business logic, starting with the tests is a waste of time. Sure, you could do it, but you'll be constantly updating them during implementation.

Thanks for sharing the great suggestions.

Thank you for this video. What would you say is the ratio between the time you spend specifying what to do and actually doing it? How do you test things that go to a database for example? Do you "mock" it? I'm not a big fan of that, rather build an in memory version of a DB which I guess is just a more complicated way of mocking things and I guess I'd need tests for the test implementation.

Thank you for sharing the experience!

Great video, after a few months as a Junior, I'm starting to really resonate with these subjects

I really enjoyed this video and approach. You've given the most comprehensive yet sussinct introduction to the mindset (and working theory) behind good TDD I've yet encountered. I've consumed endless content on the matter in the form of courses, articles, and videos, and nothing really motivated me to incorporate TDD into my practice like this video. Most content does a decent job of explaining the what/why and maybe the how from a technical standpoint, but I love how you provide a clear path on how to approach the mindset from a practical perspective. Thank you for the insight. I will try this approach on the project I am just starting.

I feel like this video makes a lot of sense when you already know what he's talking about, but if you haven't lived it or been in these situations enough it can be cryptic.

I bet a whole video could be made on Metaphors and naming...

I never write tests for my code. Because it is flawless. Always.

Thanks for the update! Great process! Also thanks a lot for mentioning the importance of small tests that verify an assumption which you later throw away. I think deleting tests is as important to the design of quality solutions as writing tests is.

My issue with scrum started when it bacame a full time job...

Thanks for this.

Waiting for the Demo!

gud vid ngl but if you ever consider adjusting the speaker at the end literally blasted my ears

Thanks for the video! I'm going to try to apply some of these actions in my daily life, let's see how it goes. Brazilian greetings o/

Step 1: Fix the economy so memory becomes cheap, it's literally just printed nowadays anyways. Step 2: Treat binary bits as a 4D array, scrap the old memory systems. Step 3: Bring programming closer to dealing with real data. When you move a photo on your screen, you're moving it in ram as it would be on screen. Saved in memory the same way, as a physical array of bytes. Step 4: Since memory is now places, programs and objects can be allocated their own processors Step 5: create a laptop that has multiple processors all running 1.5ghz, 24 cores each. Load balance objects by their methods to run accross cores since each object has a defined space in memory so you dont need to be limited by memory accessing resources. step 6: Realize where objects are has to be a fixed location in a logically accessible space and that not doing so is what cripples our progress with computer science Step 6: Realize you didn't finish your computer science degree

15:35 I still don't see the value of TDD if you still expect to have a pile of bugs. I see the value in tests, but not testing first if you end up in the same place with as other strategies.

Yes, please, demo it! :) How would you approach developing a client app such as Android app. What would you test? And what not. What would be first part you would develop?

Software development has utterly lost its way, and agile/scrum is a huge part of that downfall. Modern development methodologies give permission (i.e. demand) for corporations to interfere with their development teams on an hourly basis. I used to be 100% productive. In the face of a scrum master, a product owner, and dedicated QA teams, my productivity is maybe 15%, my quality is lower, and my morale is 0%. You can't expect developers to care if the company spends all its effort sabotaging them on a daily basis.

As a software test automation engineer I've also been highlighting the benefits of quick QA feedback, to leverage that the dev is still in the optimal mental context. Like deploying test automation so it's useable by the whole team and can run it themselves. Incidently having more testing done pre deployment on test environment saves me time to write more test automation.

It's nice to see you talking about innovation but other than a spike on a new lib or something, how many engineering teams actually bake time for innovation into sprints? So David, what's the solution to that?

Sadly scrum could be more useful if people were abstract about it, but it gets turned into a process and all hell breaks loose

Thanks David, that's an interesting list. I'm not immediately sold on the value or reliability of Defect Density, and I don't feel it fits with the rest of your list. Firstly there is a problem of construct validity; what exactly is "a defect", what's the unit of measure for "a defect" and how can you compare one defect to another? Would it not be more useful, and easier to compare, something like how much time is spent fixing defects? That would cover misunderstandings, miscommunications, implementing the wrong ting, or the thing wrongly, as well as mistakes in code. This would also tie in well with "Time to value", "Time spent coding", and to some degree play along with "Efficiency of feedback loops".

Imo what lots of people are missing when condemning scrum: what is the alternative? I worked with several companies, all had their free style software development. All had the same typical issues So, guys. If not working with scrum, how do you want to work? The how needs to be answered. I am a scrum master with developer background. I recently joined a team, which was really in a bad shape. The manager called it scrum but honestly it wasn't. My first action was: get the management out of the daily I think that a scrum master has to work 80 percent with management and po and 20 percent with the developer. The management and po are mainly the reason why it sucks. They want it to manage the developer . And they don't understand what is key: Create an environment where everybody feels safe, reduce hierarchy, give them the support they need , create focus. When you understand this, then scrum starts to work! But when you as a scrum master are just following the manager, then you are wrong about your job. What I also observe : The classical management comes from waterfall and they love waterfall, they love the controll, the deadlines, the possibility to blame the devs One of the toughest parts is it to show the way from classic or even iterative waterfall towards e.g. software development using user stories and developing potentially shippable products every sprint. It's tough to teach them that development is rather research than construction. It is a journey with too many unknowns to control. The way to satisfy the stakeholders is to deliver small things regularly not by pushing the developers such that they stick to the deadlines until they are dead! We need the role of a sm or agile coach. But this person needs to understand that the people, who make decisions, are the people who create the environment! You must have balls and to build a powerful team and not to go with the flow of fears from the management!

As allways it is greed and lack of knowledge that gets in the way of excellence. Amongst the middle managers there is a greed to finish more tasks fast, and according to some random plan. This collides with the inherent nature of software development that has many unknowns as is hard to predict. So Scrum becomes a method for micro-management and oppression, rather than team collaboration. The scrum master becomes extended management. Time estimates becomes contractual deadlines that developers are supposed to meet. Standup meetings are used for status reports. Essentially, the real core cause for the breakdown of Agile and Scrum is lack of trust. Agile and Scrum is supposed to work in a high trust environment with highly motivated developers, where there is mutual trust between developer and management, but when trust goes out the window, it all breaks down.

People blame traditional project managers as if they could not change. The real issue is the demands of projects hasn't changed. Company leadership demand absolute certainty of cost and schedule despite not having discovered their full requirement. The same companies are dependent on skills that doesn't make sense for them to invest in at scale so engage consultants further exacerbating the need for absolute cost certainty. There will always be someone who will take on this challenge. People need work. And companies will always jump at a solution based on the best demo /pitch they think meets their requirements without investing and understanding the requirements or even contracting to a well thought through set of outcomes. This disadvantages all parties involved in a project.

Strongly disagree about the user stories approach. User stories generate a solution from the user's perspective, a perspective that may not state the total business response to an event. What if a better business solution would make that user's role obsolete? Business requirements derived from business rules, not wants, drive solution design from a business perspective. You seem to want to discard a waterfall approach based on good practices in the programming phase. The baby is being thrown out with the bath water.

Its Fragile development. Its effective on paper. Its like having F1 races with 100 pit stops. Software development was never meant for non tech managers and clients to be so involved in the process. You can tell its some scheme from the $deptartment in their attempt to turn devopment into a business model. Nice try. Its make sense only on paper and to folks who know nothing about software development. If you have junior devs and a non-dev lead, then consider the project taking 300% longer 😂

So what's the solution? I'm not sure what the problem is exactly either? Get rid of timeboxes? Get rid of POs? You've stepped away from Scrum. What alternative framework are you offering?

I'm often a bit puzzled by how to apply agile to real products. Starting from a blank white-board, developing an MRI scanner (work I lead for ten years) I don't see how at the end of the first sprint you can have anything shippable or of value to hand to a customer. Taking a product owner's story 'generate an image of the patient's ankle and display it on a screen' is the work of years and the detailed technical aspects of implementing the code needed are more than a single product owner can readily deal with. Now try to break that work up into two week sprints with planning and demo eating a couple of days of the ten available and the amount of rework that will result from not planning how to build the overall system in a way that scales and performs as needed (finding out that 'the simplest thing that could possibly work' is 100 times too slow and needs to be completely redesigned seems pretty likely). Then tell management that the product will ship when it ships and that the team will certainly periodically need to redesign large sections of the code as the design evolves and the business end of things will also have a problem. I can see how it would work for small, incremental updates to simple, existing systems but I have never seen a credible explanation for how agile done as described by its gurus (not scrummerfall or other approaches that use the words and some of the individual practices but miss the bigger point) can possibly work for real products of significant complexity.

I've encountered so many wrong implementations where it was just abused to micro manage the teams and punish them for imagined sights that I'm deep in the camp of people who just react with disgust and steer clear of job offers that involve Scrum.

So it's like a spellcheck... On steroids all right... I don't find it that impression personally but I'll keep checking.