Practices. I guess for us, some of our practices came from book called extreme Programming explained by Kent Beck. And I would say it was written at a time where a lot was going on, right, jobs were being sent offshore, right. There was an emphasis on getting work done. It was really kind of confusing, how to keep that sustainable pace. And the XP book, really kind of jumped out and just said, hey, we're going to show you what it looks like to get everybody in a room and to really move fast forever. And some of them or some of the ways to get there was based on these practices. So keeping design simple, so not over engineering over architecting, right. Start small and literate naturally. Start with the test re factor ruthlessly. So this is where some of the red green re factor mantra came from. Having short releases with that minimum viable product. So you could ship and Tyson's point, so you could get feedback from your customers. Ideally they're pretty close, right. So they're on site, even they're may be working as part of that balance beam that we'll talk about more and sure, continuous integration delivery retrospectives and really collective ownership. I would say is the most interesting, and when you think about some of the different disciplines within engineering, you might think of platform engineers who are supporting production, developers who might be doing front end or back end. Or even data scientists who are putting together large, big data systems. Being able to move around those different areas is important. And the idea that if one person leaves the company, work doesn't stop from happening. So collective ownership and thinking about teams a little differently. More so as that unit of a team versus the individual, let's say Mike who's the only one who knows how to stand up a Cassandra database. So those are practices that we do day to day. And I think a lot of them apply to how we think about architecture as well, which is interesting. And I guess where they stem from is a handful of principles. So we're going after a few things like quality work, right? We want incremental change. We want that rapid feedback from our customers. We want an open honest communication. We wanted people to tell us if the app that we built is usable or not, right? If they're going to enjoy using the application or if we should change something. And then naturally just anticipating change or embracing it, right. Change happens, so why not plan for it as opposed to not planning for change. So those are principles and then maybe peeling the onion, one more layer back they are based on values, right? Again, some of these pop up simplicity, communication, right. So we value tight small communication groups, right? We don't want to wait a week for an email or two weeks for a meeting to get scheduled with somebody who's going to influence what I'm doing today in a code base. Or today in an application architecture and then sure there's a value of courage, right? That's tied in there as well. Lastly right, if you think of the traditional project and you have things like cost time, quality and scope. Mainly what we're doing is we're trying to reduce costs, reduce time while keeping quality high if not even through the roof. And the lever that we have these days is scope, right? So that's the one that will tend to say if something is in or out of scope and that's where, these concepts of things like minimum viable product and whatnot come from. So those are our variables and I guess we mentioned the phoenix project and they talk about the three ways in the phoenix project and the three are here, which I would say correlate over that pretty nicely. Right, the flow work is all about getting things done, iterations such that you could get things in front of your customer, right? Fast feedback loops, right, reducing meetings, reducing time that you need to schedule a meeting or time for asynchronous communication, right? Some folks don't necessarily think about the cost of distributed teams or remote teams and then the asynchronous nature of some communication there. And then also, having that culture of continuous learning and experimentation. So I guess last slide for this section and it will queue up quiz for you here potentially as well as an assignment. There's a great article no silver bullet by Fred Brooks, Fred talks about the essence of software and some of the things that are accidental, right? Believe it or not, improvements to a language he would call accidental versus the essence of building a system that knows how to do air traffic control, for example, right? The essence you can't remove from the software that we're building, right? But accidents, you can. And his big thing, right, is that there's nothing out there that's going to improve one order of magnitude within a decade in terms of our productivity, reliability and keeping things simple. So there's no silver bullet.
