I am happy to be the thousandth subscriber of this channel 🎉
@ThePassionateProgrammer8 сағат бұрын
Me too. This is very exciting. Much more to come!
@Nojo5242 күн бұрын
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 ❤
@ThePassionateProgrammer2 күн бұрын
Do I agree with the testing pyramid? Yes, in general. Software applications are so varied that it is hard to make rules around testing them. How we test and what we test is very different of we are building code for a pacemaker versus a social media app so there are no hard and fast rules here, IMO. However, I strongly believe that all code should be tested and I prefer to have unit tests for the behaviors I build, which I create as a result of doing test-first development. Unfortunately, there isn’t good guidance yet around doing this well and we still have some fundamentals to cover on this channel before I dive into TDD. When I have good unit tests that validate the outcomes of my APIs, they give me the freedom to refactor code later. But the way I see most devs write tests, they lock down the implementation in the test and when they go to refactor their code their tests break. This is even more so for integration and system tests so when you change implementations those tests must be rewritten. We have more opportunities to create implementation-independent tests at the unit level so that’s where I focus my testing. So, unit test can save a project or it can destroy a project by locking down implementation and preventing code changes. “The same medicine that can cure you can also kill you,” as Billy Bob would say. I hope this helps and I will make videos about this in the coming months so stay tuned.
@Nojo5242 күн бұрын
@@ThePassionateProgrammer Awesome! Can't wait on this topic. Another great topic that would interest me is on how a mocking framework could complicate refactoring too since it knows too much of the implementation.
@ThePassionateProgrammerКүн бұрын
Yes, exactly! I’ve seen mocks lock down implementation making it difficult to refactor code. I don’t like to use mocking frameworks a lot. I prefer to create my own mocks and shunts that can abstract out implementation details. You’re right, I should do a video about this but I have a long list of videos to create and I want to try to be inclusive so non-developers get value from my channel also. Thank you for your comment and stay tuned for more.
@ThePassionateProgrammer3 күн бұрын
Cool, thank you. I’ll check it out!
@skulver3 күн бұрын
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.
@ThePassionateProgrammer3 күн бұрын
Is this the book? www.obeythetestinggoat.com/pages/book.html
@skulver3 күн бұрын
@@ThePassionateProgrammer Yeah, that's the one.
@francoisconstant59864 күн бұрын
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 !?
@easing_rain3 күн бұрын
Yes, push on save is the way :)
@ThePassionateProgrammer3 күн бұрын
Yes, some teams commit to a staging server first as a precaution. But look at Google. Everyone always commits to trunk every day. If 60,000 can commit daily without branching then anyone can. Feature flags holds part of the answer. They are on my list of things to cover in a future video. It’s a long list.
@vibovitold2 күн бұрын
@@ThePassionateProgrammerhow to maintain co-existing released versions (eg. Android 13 and 14, or different versions of Chrome) if you only have the trunk? are you sure they use feature flags for that? that sounds like a nightmarish amount of ifs, and simply recreating the headache associated with branch management in other form and other place
@ThePassionateProgrammer2 күн бұрын
@@vibovitold I don’t know how the teams at Google handle different versions or support different hardware from the same code base because I haven’t work with them. However, you could use feature flags for that instead of branches. I am okay with branching as long as they are short-lived. Branching for experimentation is fine. We just don’t want to have many long-lived branches. We have a name for when teams create feature branches that they don’t integrate until just before release, it’s called Waterfall.
@smallbig8576 күн бұрын
How do you do PRs/Code review without branches?
@ThePassionateProgrammer5 күн бұрын
The short answer is feature flags but there’s more to it than just that. Maybe I’ll make a video on it.
@user-tg6ls4tg2s2 күн бұрын
So the merged code is reviewed directly on main?!
@ThePassionateProgrammer2 күн бұрын
@@user-tg6ls4tg2s Yes, but hidden from execution by feature flags.
@joaquinnunezgarcia92796 күн бұрын
Thanks for sharing your experience
@ThePassionateProgrammer5 күн бұрын
My pleasure!
@typosbro_6 күн бұрын
I didn't know I'm a gambler
@ThePassionateProgrammer6 күн бұрын
We all are every moment, Bro.
@SimGunther8 күн бұрын
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
@saltybaguette76838 күн бұрын
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
@ThePassionateProgrammer8 күн бұрын
Yes, start simple and build incrementally, that’s exactly what I’m saying. Or in Kent Beck’s words, “Do the simplest thing that could possibly work.” Once it is working it’s much easier to build upon. Big up front design is Waterfall and a waste at many levels. Incremental software construction is a core idea behind Agile. So, they did not teach you this in school? What did they teach you about code quality, software principles, acceptance testing, design patterns, and refactoring? These are what I consider to be core skills for software developers.
@saltybaguette76839 күн бұрын
Off-topic but we need an answer: Emacs or vi-derrived (vim, neovim...)
@ThePassionateProgrammer8 күн бұрын
I prefer IDEs, like VSCode or Eclipse… or Sublime for Markdown.
@fashionrebelution9 күн бұрын
This content is so helpful. Please keep them coming.
@ThePassionateProgrammer7 күн бұрын
You got it!
@andydataguy15 күн бұрын
This video was wildly helpful to me. Thank you 🙏🏾
@ThePassionateProgrammer13 күн бұрын
I am so glad. You are welcome!
@MalushJ15 күн бұрын
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..
@ThePassionateProgrammer13 күн бұрын
Yeah, I forgot to mention that TODO tags in comments are fine. Thank you for pointing it out.
@ChrisAthanas16 күн бұрын
I think your camera is out of focus, please check your settings. Audio is perfect.
@ThePassionateProgrammer15 күн бұрын
Sorry about that. I’ll use a better camera next time.
@fashionrebelution17 күн бұрын
I never put comments in my code. Wait, do I write code?
@ThePassionateProgrammer15 күн бұрын
Do you write code?
@skulver17 күн бұрын
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.
@ThePassionateProgrammer15 күн бұрын
Yeah, but at least you know which one the computer believes is correct.
@SteveKuo17 күн бұрын
To me a comment is either a lie or an apology.
@ThePassionateProgrammer17 күн бұрын
I thank that is so profound. Thank you for sharing that, Steve!
@ActualJosiahPreston17 күн бұрын
Great way to say it.
@GeneraluStelaru19 күн бұрын
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.
@ThePassionateProgrammer13 күн бұрын
You have an inaccurate perspective on what test-driven development is about and how it is practiced. No wonder it doesn’t work for you!
@gauravtejpal890112 күн бұрын
Constant iteration incremental change can be a very positive approach. It actually happens in any code base when the program becomes big, anyway. So why try to avoid it? Our thinking should evolve along with the creation of our program, why not!
@ThePassionateProgrammer12 күн бұрын
@@gauravtejpal8901 well said, thank you!
@fashionrebelution21 күн бұрын
Thanks for sharing the great suggestions.
@ThePassionateProgrammer21 күн бұрын
You are so welcome!
@i-am-the-slime21 күн бұрын
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.
@ThePassionateProgrammer20 күн бұрын
Good questions. It’s hard to answer the proportion of analysis (what) verses design (how) I do because it is ongoing and iterative. I probably spend twice as much time in analysis, talking to users, creating acceptance tests, getting feedback, etc. versus coding in the beginning of a project and that proportion reverses towards the end of a project. Regarding your second question: How to remove dependencies so that your tests test only your code is the subject of many videos and I hope to make some of them. Yes, the short answer is to ‘mock’ the database so it is out of the test but that doesn’t mean to use a mocking framework. Mocking frameworks are slow and add a level of complexity that I find distracting. Creating my own fakes and injecting them is super-easy while promoting clean code habits that make code more testable and extensible. I’m all in favor of automation but mocking is one area I prefer to do by hand. Are you familiar with techniques around dependency injection and creating ‘hand-crafted mocks’? If not then I can make a video about it.
@vadimemelin294122 күн бұрын
Thank you for sharing the experience!
@ThePassionateProgrammer22 күн бұрын
You are welcome!
@saltybaguette768324 күн бұрын
Great video, after a few months as a Junior, I'm starting to really resonate with these subjects
@ThePassionateProgrammer24 күн бұрын
I’m glad you are finding value on this channel. Much more to come… And thank you for suggesting the topic for last week’s video. It’s been doing really well.
@TennysonHull29 күн бұрын
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.
@ThePassionateProgrammer29 күн бұрын
I deeply appreciate your comment. Thank you!
@megamaster766729 күн бұрын
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.
@l0gic2327 күн бұрын
Yeah, I was keeping up until sometime around the half way point, I think... Vocabulary expanded suddenly... Then we were talking APIs... Method signatures.... Etc... Wish the example stayed simple or connected the dots (probably left on the cutting room floor due to the algo).
@l0gic2329 күн бұрын
I bet a whole video could be made on Metaphors and naming...
@ThePassionateProgrammer29 күн бұрын
Excellent idea! I’ll work on it and base it on the ideas from George Lakeoff’s book, Metaphors We Live By, an amazing read!
@egonkirchof29 күн бұрын
I never write tests for my code. Because it is flawless. Always.
@ThePassionateProgrammer29 күн бұрын
I don’t believe you. Humans (and AI) make mistakes. The REAL mistake is being in denial of it!
@egonkirchof29 күн бұрын
@@ThePassionateProgrammer Aren´t the other mistakes REAL as well ?
@nickbarton319126 күн бұрын
@@ThePassionateProgrammerPretty sure that was humour.
@successengineeringamplio19 күн бұрын
You're missing the point. Tests aren't to validate what you wrote. They are to clarify what you will write.
@egonkirchof18 күн бұрын
@@successengineeringamplio Wrong.
@BartEnkelaar29 күн бұрын
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.
@ThePassionateProgrammer29 күн бұрын
Very smart! Yes, only keep tests that create new distinctions. Use assertions to specify behavior! That way your tests become much more valuable.
@MrDpof29 күн бұрын
My issue with scrum started when it bacame a full time job...
@ActualJosiahPrestonАй бұрын
Thanks for this.
@ishankadkАй бұрын
Waiting for the Demo!
@Ic3q4Ай бұрын
gud vid ngl but if you ever consider adjusting the speaker at the end literally blasted my ears
@madeinpoty3704Ай бұрын
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/
@ThePassionateProgrammer29 күн бұрын
Great, best of luck!
@5WLuminousАй бұрын
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
@ThePassionateProgrammer29 күн бұрын
Don’t let missing Step 6(a) hold you back. Let’s of great developers don’t have CS degrees (including me).
@5WLuminous28 күн бұрын
@@ThePassionateProgrammer I mean, I haven't, It's just been a process of evaluating how low level I'd have to go to create the database structure and whether that structure would be feasible for one person to create. I wish there was a way to get funding/have someone evaluate the concepts without risking them bein' stolen
@NuncNuncNuncNuncАй бұрын
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.
@anthonyhawkes4101Ай бұрын
You also end up with a lot of wasted time rewriting tests when you need to rewrite something because of moving goals or needing to re-architect something. Even with properly decoupled code and forethought, I think TDD is a good idea but in most environments it's a lot of overhead - as you might end up just throwing code away - including the tests. Client asks for feature x You write your test, then your code Client no longer wants feature x- Any time writing tests is now wasted. As you develop incrementally, you'd have probably moved on from feature x to another feature. (unless you wrote a test straight after in which case you're in the same boat anyway)+ I think an "abstract" test could be useful - a template of the code what you think the test might look like in the end without the logic
@alf5197Ай бұрын
@@anthonyhawkes4101 You can still write tests for things that are unlikely to change soon or for critical pieces. Debugging is a lot of time thrown away as well, and TDD can help reduce the amount of debugging.
@BartEnkelaar29 күн бұрын
You might end up in the same place as with other strategies, but I personally end up in a much better place design-wise and I definitely get there faster. I also find it a lot more fun since I've gotten there in a way that has given me about 20 dopamine shots of success instead of one dopamine shot at the end. So I get to higher quality faster and have more fun. Good enough for me. Now I don't always do TDD. If I'm building a website e.g., I get this rapid iteration from just hacking css in the browser, which I then copy to the css files in the project. It's not strictly TDD but it's essentially the same process. I have a hypothesis, I test it & I apply it.
@BartEnkelaar29 күн бұрын
@@anthonyhawkes4101 Time spent on tests that are thrown away is definitely not wasted. You've used the creation of the test to verify the design of your API and used it to structure your thoughts on what your code has supposed to do. This is very powerful in directing your mental model in a way that improves the design of the solution. As a matter of fact I delete a significant amount of tests I write regardless on whether a feature is sunsetted or not. As during my design process, there are different slices of functionality I want to test, but when the production code has reached a satisfactory state I will reassess my test suite and remove or merge redundantly overlapping slices. Keeping your test suite manageable is part of delivering quality code.
@ThePassionateProgrammer29 күн бұрын
Great answer! Well said.
@mackomakoАй бұрын
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?
@ektedАй бұрын
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.
@nargileh1Ай бұрын
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.
@johnknapp5048Ай бұрын
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?
@ThePassionateProgrammerАй бұрын
Hi John, thanks for your thoughtful comment. It's true that not all engineering teams prioritize innovation within their sprints. However, if innovation is important, it's essential to make time for it. Companies like Google and Microsoft allow some of their developers to spend some of their time each week working on projects they believe will add value. In my view, innovation and continuous improvement are critical aspects of a software developer’s role. The best developers I know always strive to find innovative ways to enhance their skills and the software they work on.
@ashleydickson62Ай бұрын
Sadly scrum could be more useful if people were abstract about it, but it gets turned into a process and all hell breaks loose
@GeirGulbrandsenАй бұрын
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".
@ThePassionateProgrammerАй бұрын
Great points, I totally agree. Time spent on defect mitigation is a far better metric than defect density. Thank you!
@ldaniel8466Ай бұрын
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!
@robertrenbris2334Ай бұрын
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.
@ThePassionateProgrammerАй бұрын
Wow, you are so right. This is what I experience in many organizations as well. And I agree, it’s a lack of trust that is at the core for a lot of managers. I think that perhaps managers don’t trust developers because they don’t understand the issues we face. How can we help them understand and support us better? I hope to explore these issues more on this channel. Thank you for your insights.
@robertrenbris2334Ай бұрын
@@ThePassionateProgrammer Thanks. I am an atheist, but to be honest I think that to some degree we need some more of that Jesus Christ spirit in our culture. The western civilization was built as a high trust society, and we are currently loosing it. Perhaps one way to deal with growing mistrust is to talk about it openly. Ask the managers straight out, if they want that extra status report or planned deadline just because they do not trust the developers to put in an effort otherwise? Also, we really need to hammer down the idea that software development in general is impossible to plan. Software development can never compare to an auto-assembly line. Every single line of code we write is unique, and in almost every work we do there are unknown factors ready to make any plan fail. What managers needs to understand is that if they just give developers a bit of a breathing room, and some freedom, they can do all kinds of evaluations after the work is done. After the work has been done, we will know how long time it took! Then the managers can do all kinds of evaluations of how much code was written in a given amount of time, and what the productivity of programmers were. Then they will have plenty enough data for their charts.
@BadVoodoo11Ай бұрын
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.
@donstratton6343Ай бұрын
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.
@ThePassionateProgrammerАй бұрын
What are your sources of information about user stories? My friend Ron coined the term. User stories DO NOT have to only come from users. The first part of a story is the role, “As a _____,” That role could be a user, stakeholder, executive, an external system, etc. But it is better to have the focus of a user story be the outcome of applying the business rule rather than the business rule itself. Read Mike Cohn’s book, User Stories Applied if you want to learn what user stories are and how to use them well.
@donstratton6343Ай бұрын
@@ThePassionateProgrammer Thank you for replying. The focus is a study of the events that cause the business area to do work. Data arriving at the business area creates a total business response from the perspective of the business. An alternative and more comprehensive approach to user stories is event analysis driving requirements definition that becomes the foundation for conceptual design. My source for user stories was while working in a large corporation in the US in the 1990's witnessing user stories missed only to be demanded as essential later while other stories were included that were really outside the scope of the business area. I saw this happen on three separate projects.
@taamcyatАй бұрын
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 😂
@capoditutticapi6528Ай бұрын
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?
@ThePassionateProgrammerАй бұрын
One step towards a solution to the failure of Scrum software development is to include technical practices from Extreme Programming that support iterative development. There are solutions to the challenges in Agile but you have to look for it. I think that enterprise software development is the most complex activity that humans engage in. There are no quick fixes. If you really want to understand the issues and learn some real solutions then that’s the subject of many of the videos I’m making.
@kylewilson4097Ай бұрын
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.
@johnforrest695Ай бұрын
"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" simple answer is that you won't but that does not invalidate the whole approach. The basic Agile aim is short iterations so you can get customer feedback. In the initial phase of the project that probably means partial functionality, perhaps almost test harness like, to be able to demo something. Later it will mean partial functionality. The thing is that you get customer feedback and adapt from it.
@ThePassionateProgrammer29 күн бұрын
Yes, exactly. Well said! Thank you.
@IskelderonАй бұрын
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.
@nixquevАй бұрын
So it's like a spellcheck... On steroids all right... I don't find it that impression personally but I'll keep checking.
@ThePassionateProgrammer6 күн бұрын
Here’s what my friend, ChatGPT has to say about being a spellcheck on steroids: “In forging a collaborative bond with AI, we must recognize it as more than a sophisticated calculator; it's a wellspring of creativity that can complement our own. It’s about creating this dance-knowing when to lead with a human touch and when to follow AI’s intricate steps based on thousands of underlying patterns it discerns. The collaborative effort isn't about issuing commands; it's about dialoguing, challenging, and guiding AI to illuminate roads less traveled by human thought alone.”