Learn how to work as a highly functional software development team with helpful tips in my FREE guide to "Organising SW Dev Teams" which you can get here ➡ www.subscribepage.com/organise-teams-guide
@amitev2 жыл бұрын
"Good software comes from teams, that are able to clearly separate, what the system needs to do from how it achieves it" - a lot of wisdom in just a single sentence.
@andrewnimick21752 жыл бұрын
If you come to us with a solution we may have a problem....
@amitev2 жыл бұрын
@@andrewnimick2175 what?
@redwrath52 жыл бұрын
Dave are you sure you don't work at my company? It seems you always upload episodes on the current issue I'm facing right as I start to face it.
@ContinuousDelivery2 жыл бұрын
So the bugging devices are working then 🤣🤣 Very pleased to be of some help.
@JacquesOosthuizen6962 жыл бұрын
So true!
@PickledDragon2 жыл бұрын
Hey colleagues. How do I find you on the intranet?
@eriklintsev2 жыл бұрын
Same here ☺️ some synchronicity detected
@brianmulder492011 ай бұрын
this should be on everyone's repeat-annually playlist to keep us on the path
@azw2540 Жыл бұрын
Thanks
@CountZero2 жыл бұрын
To my point of view: Platform Teams are Value-Stream Aligned Teams FOR Stream-Aligned Teams, but the value is not directly aligned with the customer (the one who pay!), instead it's a derivative to the value to customer (commit small, often, with trust, delivering value as fast as possible). That's the way we approach our role in my organisation. I work in a CI/CD/CLOUD platform. The principles you've exposed are similar to those applicable to end-user but in my case, the end-users are the teams who write/operate code for the customers, We are considering ourself as small enterprise/startup within the company.
@Microman65022 жыл бұрын
That’s how I think about it too. I like the way you described it as a derivative value stream. I’m wondering from listening to what Dave said if my concept of ‘platform’ is too loose though. I haven’t got a platform in the sense of a great big lump of software that the teams insert software components into. What I’ve got our platform team doing is assembling a carefully curated set of enabling components and the infrastructure scripting ’glue’. So things like SSO, Kafka, caches, etc and tools that support deployment. I need to dust off my team topologies and make sure I’ve not become confused :)
@ContinuousDelivery2 жыл бұрын
No I don't think that is "too loose", sounds like a good approach to me. Some of the text in the video actually recommends that approach if I understand you correctly.
@user-xx7tv7cc1y2 жыл бұрын
Platform teams who treat their developers like customers will build great platforms. Also in my experience, the best platform engineers are actually developers because they know what developers want.
@apostolosstamou90652 жыл бұрын
Hello Dave, thank you so much for the invaluable content you offer through your books and videos. One question that I have is when you mentioned (around 16:20) that the new platform build will fail during CI, because Team A code breaks. How will the execution of the Team’s A test suite be triggered in this case so that the platform team to know that their new build failed? I am asking this because i) a platform might not even know which its customers are (imagine a popular platform that has dozens or hundreds of teams using it) and ii) Platform code and Team’s A code are in two different repos. Personally, the only way that I see a platform build to fail in the way you mentioned is through some sort of contract testing (but even this without 100% guaranteed results, because the platform cannot know how each team uses its APIs). I would very much appreciate your point of view. Thanks again for your contribution to the software development community.
@ContinuousDelivery2 жыл бұрын
Well the easiest way to organise CI in this case is to test everything together all the time. Keep everything in a single repo, and run all the tests on every commit. You can make these kind of breakages visible through architectural techniques, using static typing for example, or you could try using contract tests to confirm that nothing has changed in the interface. So there are a variety of techniques. I'd advise thinking of it from the perspective "What do I need to know to be happy to release?" that should define the scope of your constant, CI, testing.
@apostolosstamou90652 жыл бұрын
@@ContinuousDelivery Thank you for your time and response.
@Mozartenhimer2 жыл бұрын
I'm going to parrot this video in my meeting today. Hit the nail on the head with one of the big problems we're having.
@ContinuousDelivery2 жыл бұрын
Pleased that you found it helpful.
@jonnypop002 жыл бұрын
This was Great! definetly a hot topic for us right now, perfect timing. The way you explain things makes it so easy to understand, appreciate you doing this. Can you do one on Complicated Subsystem teams next? There are so many parallels between platform and complicated subsystem, would love to see how you understand the differences.
@johnboikov13602 жыл бұрын
Call me Peter because I'm a disciple! I'm only just starting out but CD has already helped to make progress with projects without feeling overwhelmed. I don't have to think about everything at once and this immediately makes the journey of software engineering doable and enjoyable. I'm reading "Modern Software Engineering" and I highly recommend it, I'm only a third of the way through and yet it has already changed the way I conceptualise software development. It's no longer just "coding" or "crafting" or " programming", now it's design and engineering. I also have a biology background and it has been interesting to see parallels between actual evolution and the " guided evolution" philosophy of software development. Once you get code-to-repository you have what you have, much the same way that sets of genes work when in homeostasis in organisms, you can only change what you already have and to completely change something is extremely energy intensive. Even in the context of genetic mutation, the most successful mutations (those passed on to next generations) are most often the smallest, a major change to an organism's code more often than not leads to fatal consequences due to the complexity of the underlying interaction structure. We are coding "living" software when we stay engaged with the code in our repositories through consistent small commits. Thanks Dave! You've got some of my money and attention and I foresee you'll get a whole lot more from me in future! (I'll just confirm though that I'm not joining any cults, I'm allergic to tinfoil hats and unbridled groupthink)
@ContinuousDelivery2 жыл бұрын
Thank you for that! 😎 I don't want to be in any cults either, when someone points holes in my arguments, and shows me a better way, I am grateful. That is how knowledge, and practice progress, it's a process of evolution too. I very strongly believe in treating SW dev (and nearly everything else) as an exercise in guided evolution. So I think that is what the process of science and engineering is too, we gradually accrete knowledge and discard the ideas that we have found to be untrue. I try to avoid being dogmatic, but maybe we should market tinfoil hats with a CD logo 🤔🤣🤣
@johnboikov13602 жыл бұрын
I was going to reply “You can guide my evolution anytime” but I think that may have come off in the wrong way…
@ContinuousDelivery2 жыл бұрын
@@johnboikov1360 we *need* those hats 🤣
@johnboikov13602 жыл бұрын
Yea verily O Great Farley, deliverer of continuity, frequent tester of code!
@ContinuousDelivery2 жыл бұрын
@@johnboikov1360 🤣🤣 "Science is the belief in the ignorance of experts" - Richard Feynman
@ilovepickles74272 жыл бұрын
This is what I've been struggling with on a solo project. I've literally just started to copy/paste my platform code into different modules just so I don't have to have another day where I wake up and decide to change my service and end up breaking my entire app. The approach I've taken is to have one canonical version of the platform code that is always up to date and well tested, but it's never imported by anyone. Then I just copy/paste the bits and pieces of the code that I need into the different modules. It's like a poor man's version control. It's a ridiculous approach in many ways but I haven't had to deal with irrelevant code-breaking API changes caused by a change to the platform. Designing a good, extensible, reusable, stable service is hard, and when you are the only developer you can absolutely waste your life away on it when there are other features that need to be built. Once more of the application is built I will move the platform code into its own repo and enforce stricter version control requirements. But while the platform is still being fleshed out I stay away from coupling with it with a 10 foot pole. As always great video.
@azw2540 Жыл бұрын
So so good - really impressed by that.
@alanarnfeld42852 жыл бұрын
@dave. thank you for the video, great content. I would like to challenge/extend your model, that platform teams need to understand the needs and plans of the consumers and stream aligned teams they are supporting but also to be a world class platform they should also understand end users as well, no matter how many layers there maybe. This allows them to understand a wider picture of problems to be solved than may be presented by a stream aligned team alone. What do you think?
@ContinuousDelivery2 жыл бұрын
It always helps to have a good understanding of the context of your problem. I don't think it is necessary to have a detailed understanding of everything though. As a minimum, I think that you should have a laser focus on the direct consumers of your service, and understand the broad aims of the layer beyond that, then you need to know what the software is for, and the better you understand that the better choices you can make, but you don't need to tie every feature change in your low-level platform directly to an end-user feature in my opinion.
@sciros2 жыл бұрын
To a point, yes, but one of the most significant merits, in my opinion, of a service platform is that it frees up the business to orchestrate this "catalog" of services in novel ways and bring new experiences to market. It is a major enabler of business agility.
@TomVahlman-bz9nj3 ай бұрын
@alanarnfeld4285 I agree 100%. You can argue that a platform team may have it focus to provide self-service API:s regarding non-functional requirements (Kubernetes, Ansible and/or Terraform) or that the platform may provide API:s supporting functional requirements (API:s used by "stream aligned teams", e.g. working with a Salesforce Financial System). In the latter case the platform team probably needs a deep understanding of the end user as well as of the business services (technical understanding) that the platform supports. A deep understanding of the business domain is probably required in order to enable business agility for the organization in the best of ways. The platform services may even conceptually belong to the same bounded context as the services in the Financial Cloud using the same core domain objects. 🏸
@Nebulorum2 жыл бұрын
Google has an approach of Apps using a client produced by the platform. When the platform changes they update the clients and have to make sure all Apps work with the new client.
@DuniC02 жыл бұрын
I'd love a more detailed explanation of API versioning
@harryhu4575 Жыл бұрын
Most of it is fabulous and well told, but I do have one different view on the mission of platform teams reflected from the example mentioned in the video, I want to discuss it. Without a clear definition of what is the mission of platform teams, we might over-engineering our organizational structure again. That is, should the platform team focus on anything that can be called as a platform, for instance the service mentioned in the video that convert the binary from hardware to Json for downstream applications, or only the platform that tackle extraneous cognitive load, for instance loading a hardware test simulation setup which doesn't bring any value to the final product? To me a platform-like service is not a mission for platform team because it's still part of our product solution and should be managed by some stream-aligned team, but a click to provision a simulation of that hardware to generate some muck binary to test this platform-like service should be owned by platform team. In other word, the platform team maintains only the internal platform serving developers only, will never be part of the product solution.
@dlabor19652 жыл бұрын
22:10 Thank you very much for talking. 🙂
@MisFakapek2 жыл бұрын
I could barely focus on the content with this T-shirt 😂
@PavelHenkin2 жыл бұрын
That's the hook - Mr Farley is trying to drum up support for his t-shirt business by talking all that codin' stuff.
@ContinuousDelivery2 жыл бұрын
🤣🤣 My plan is to lure everyone in, and then spring the rule that you must wear a silly T-shirt to watch.
@andrewshatnyy65602 жыл бұрын
This is gold!
@ashleymcgee35362 жыл бұрын
It’s like you looked right into the heart of our system. It’s creepy how you laid out the Ivory Tower. That’s exactly what happened to us.
@vladvesa82962 жыл бұрын
I wrote a for loop to click on the like button 1M +1 times, but only one time the like is registered.
@johnboikov13602 жыл бұрын
I'm sure there's a StackOverFlow post about this... we could troubleshoot this issue XD
@scr33tch2 жыл бұрын
Exceptional!
@amitev2 жыл бұрын
19:48 Tolerant Reader pattern
@jon18672 жыл бұрын
🔥That shirt though🔥
@black-snow2 жыл бұрын
All the sliding right and left does weird things to my brain. Can you just stay in one corner? I wouldn't mind if half the screen was empty when you don't need a picture to make your point :)
@jonassteinberg37792 жыл бұрын
Basically what I hear is building a good platform is virtually impossible and ultimately developers *have* to learn operations.
@-Jason-L2 жыл бұрын
9 out of 10 platform teams are unnecessary and are the result of poor architectural approach and org structures.
@TomVahlman-bz9nj4 ай бұрын
@-Jason-L Agree that approaches always can be improved. This video also describes incentives for having a platform team, which is to reduce the cognitive load on engineers and to create self-service API:s, providing consistency to end-users: kzbin.info/www/bejne/nZndpHWjbduCo9U
@ytuser13082011 Жыл бұрын
It all makes little to no sense. Just a bunch of jibberish and buzzwords.