So my talk is going to be on continuous deployment, even though today it's named continuous delivery. Whoops, they invited me to the long conference. So my name is Timothy Fitts. I coined continuous deployment. I was looking it up, but was that part-time block in 2007 that I actually first used the term continuous deployment? I did so while I was a technical leader at IMV. We were a startup, we did continuous deployment. I first coined it, I didn't invent it, I didn't start it. There were other companies doing it before IMV. I've seen references to Flickr doing it early 2004, late 2003. And there were a lot of trends leaning to... I just sort of pointed at, hey, continuous integration can go one step further. That's in fact where the term continuous deployment came from. Why don't you integrate and then deploy? After IMV was the CTO of Canvas, I actually got to build this from scratch at a company where people who knew nothing about it can teach them. And in fact, we got to have a bunch of capitalists, Fred Balsen, who had already continuously deployed at Etsy before he joined our board, which I never would have imagined. And then for the last five years, I've been a software consultant. About half of my time, I write code because I'm the kind of person who will find the right code. I go crazy. On the other half, I teach and evangelize and do investments in workshops and coaching. You can find IntimityFits.com or IntimityFits on Twitter. These slides are available already online if you go over to my Twitter. So really quickly, I'm going to cover what is continuous deployment. I was looking for continuous delivery. That's sort of the basic part of this talk. Then I'm going to talk about the pitfalls of getting to continuous deployment. So it's sort of the lessons learned that I've seen from organizations where they get stuck, where they have problems, things I don't like that the industry is doing right now. Lots of very opinionated sort of grantee style things. That's a little bit more intermediate. And then finally, I want to end on the future of continuous deployment, where I think the industry is headed, what I think we're going to see develop, where some opportunities are. And that's sort of like what keeps me up at night. And that's a little bit more advanced. So let's start with the definition of continuous delivery. So the goal is to produce software in short cycles, ensuring that the software can be reliably released at any time. This is pulled from Wikipedia. If you look at, for instance, like the Mark Fowler page on continuous delivery, it's a much longer explanation. But I'm really highlighting sort of the difference between continuous delivery and continuous deployment here. It can be reliably released. So I would say this is deployable at the push of a button. That's sort of the difference between continuous delivery and continuous deployment. I see Jed's nodding, so okay, I got it right. We're good. Here, I use terms deployed with these very specifically. And in the classic box model of software, they were the same thing. You would ship a thing, deploy it, you release it. We're all the same thing. But very quickly, you're going to find that deployment is something very specific. It's copying the code out of servers to client devices. It's running that code. And it's not necessarily releasing new features. Releases when a feature is turned on for a user, when they first see it. For many things, deploy and release are the same, even in continuous deployment. But for bigger features, you're obviously going to want to do something different. So what is continuous deployment? So my definition is safe, automatic deployment of frequent, small arguments. You have these things, you're doing continuous deployment. So safe. The automated process is ultimately responsible for failures. So this means that you are not personally going to get blamed. You're not going to sit in a postboard and have someone say, you're fired for screwing up and putting that bow. No, no, no. It is the process that actually guarantees the safety of this. This isn't just a tool or a technology. It's a way of looking at the people in your company. When you look at safety as an industry, as a sort of set of principles, there's a whole bunch of practices that our industry just doesn't do. You'll hear a programmer say, I got burned by that. That hurt when I did that. That failure cost me. And in terms of the safety industry, you'd be like, oh, you got burned by that? We should probably have protected you for this. We should probably ensure the safety of your day-to-day workings. And in the software industry, we go, oh, now just do more of that and faster. Don't worry about it, get burnt more. No, continuous deployment is about safety. First and foremost, we're seeing it time and time again. We're seeing it in statistics. We're seeing it in studies. When people feel safe, and it is a feeling, first and foremost, when people feel safe, they do better work. And continuous deployment is about making that happen. It's also about automatic deployment, not just automated deployment.  Now usually that means I commit, test run, it passes, okay, it gets deployed instantly. But I've seen this work just as well, where for environmental factors, the deployment couldn't happen more often than a certain amount of time. Every two hours, every four hours, maybe the employee takes an hour or so, maybe it's slow, maybe there's some bureaucratic process. But getting to automatic here is really, really important because it means there's no human process. There's no human chance for failure. There's no decision-making process in when and what to release. And so those decisions can't be made for. And frequent small commits. The smaller your unit of work, the cheaper it is to build out a good deployed pipeline and the less failures you're going to see. If I commit 10 or 20 or 30 lines of code and they go on in production, I just regret them. I didn't think about it. If I'm landing two weeks worth of changes and something goes wrong in production, now I have a problem. I can't revert. There are scheme of changes applied. I don't know what's going wrong. I don't know which line it is. Two days later, when I finally debug it, what do I do? I revert two weeks plus two days worth of changes. The smaller these changes are, the better they are for everything. It doesn't just make things simpler to debug. It decreases the lanes. So I have an idea. I build a short thing. I deploy it. I see that it fails in production. I change the way that I was going to build the rest of the feature. And really decreasing that latency and getting that feedback cycle to go very quickly is super, super important. It's a big part of continuous deployment. So I'm going through this pretty fast because I've said this many, many times in other forums. So if you have questions, whatever it's to me, and I'll try to send you links to what I have already said in the publisher. So really, really high level. Continuous deliveries, push button, continuous deployment is automatic. They have sort of the same structure otherwise. And in fact, the best practices of continuous delivery are almost the best practices of continuous deployment. The only difference is you have to push a button between tests and deployments. I also want to make a little secret. I'm doing the origin place of continuous deployment where I went sort of learned and scaled up and got to understand how it works. It was actually continuous delivery. So test with tasks, then you had to shell into a machine and type, I am going to push.  It was problematic. So we didn't have the institutional confidence to actually do continuous deployment. But in practice, during business hours, we were committing 6, 8, 10 times an hour easily. And so this was being run so frequently that if I didn't run it during business hours, someone else would. And so it felt very much like a continuous deployment that I've been evangelizing and that has worked now everywhere else. So let's just keep this a really, really tight, well-kept secret between us. Sound good? Both. Also, I'm not going to say delivery and deployment anymore because they sound almost exactly the same. So I'm going to try and say push button and automatic. Hopefully that will stick a little better. Both require a fully automated deployment and that's expensive to build. Both require significant test coverage and that's expensive to build. If you don't necessarily need great test coverage to start, you're going to get there all the time. You're going to be spending a large fraction of your development on right and automated tests. And both require deploy-piling infrastructure. And between the three of those, that's a lot of work. That's most of what people see and say, okay, continuous deployment or continuous delivery is too expensive for me. I can't afford to do it right now. I can't get management buying to build this. So when you talk about either of these concepts, you're talking about mostly the same amount of investment. And that's going to play into why I think everyone should stop targeting continuous delivery and instead always target continuous deployment. So one of the first problems I see with push button deployment is that they grow a human QA step before deployment. If they don't start with it, it happens very quickly. Because it's so easy. There's a person that are pushing a button. Why don't they test the app? Why don't they just do one, four behaviors? Why don't they do three, four behaviors? And this sets up a really bad feedback cycle. Oh, hey, there was a bug in production. We slipped a change to one of our four behaviors and we didn't test it before we hit that button. So we run a post-mortem. We have a meeting. We look around and say, how could we cause that? I could just try that. I could just try our application every time before I push the button. That's not that hard. And so we add more human QA steps. And here's the problem. That's pushing us further and further away from our ideal of low latency. That's pushing us further and further away from our ideal of automating these things. And inevitably it leads to more bugs. So I've added a human factor into our process that wasn't different before. I'm relying on it to catch serious issues. And humans, I don't know if you know this about humans, but they make mistakes. And it turns out that a developer at like two in the morning trying to push out a hot fix makes all of the mistakes. Every single one you could possibly make. And so when you see that more bugs happen, as you slow this process down or as you add more human QA, and then you have reduced your confidence in your reply. And this is what really kills. Better version of keynote. That's the best translation. More bugs lead to reduced confidence lead to less frequent deploy. And this is by far out of every single mistake that I've seen made at the numerous companies. And I've consulted for two, three, four person startups. And I've consulted for Fortune 500 global conglomerates. And I see the same pattern of mistakes. More bugs leading to reduced confidence leading to less frequent deploy. Pushing you further and further away from the ideals of continuous delivery and giving you more and more of the problems of traditional software. Now one of the really non-intuitive things about continuous delivery or deployment is that it's much harder to ship a weekly release than it is to ship 10 releases a day. Because on a weekly release, if there's a bug, I have to look at a week's worth of changes to figure out what's wrong. And odds are something's wrong. It's been a whole week. Versus I just committed and it instantly went by. Very easy to see what it was that caused it. Very easy to do accounting. Very cheap to do debugging. And so the slower process tends to get slower. And the automatic fast process tends to stay fast. And that's really the crux, is that if you have this feedback cycle, if you have the feedback cycle that we restarted, if you have the feedback cycle that says, okay, we had a bug and we're going to automate the solution to this, we're only going to consider automated solutions to finding that bug in the future, to preventing that class of failure. That actually leads to increased confidence in the system, the ability to do more deployments. Kind of counterintuitively, if you have a broken process, I can give you continuous deployment. Maybe it's just in the staging, and as long as you agree with me to only add automated things to that process, you will get better over time instead of worse over time. I don't need to do anything else. Usually when I'm brought into a team and they say, okay, how do we get to continuous deployment? I'm like, I'm going to talk to you guys for two hours and then we're going to sit down and we're going to start building it. Because the faster I set up this feedback cycle, the less work I have to do. I don't have to tell you how to automate a solution to find a class of bugs. You're good programmers, you're good developers, you'll figure that out. That's how I am if you got to where it is. That's where everybody else, when you see this presentation, it's about fantastic test platforms and amazing sort of edge case testing and all of these advanced things. They got there about like three or four years ago. They even found a bug. How do we find that automatically? I need to build a tool to solve that. It's easy to wouldn't have a concrete problem but the other problem with push button is that deploy often becomes feature-based and conflating those two is very problematic. So what happens if I, in a continuous delivery in a push button system, I want to release this new feature so I commit the final lines of that feature onto the master. But then I need to get like the marketing communication side of things so now. So it takes me about a day. What happens if there's an emergency in the middle of that day? How do I deploy it? Well it turns out I'm accidentally not releaseable. We can go live with the feature. We can rush it out. I've seen that happen. That doesn't play out very well. Especially when you're trying to release the new feature and fix a bug at the same time. Probably a critical bug because otherwise you would just have a code freeze. And so this leads to sort of hidden unreleaseable moments. You have an automatic process. You can't do that. As soon as you commit it, it's going to go live. So you can't commit things that aren't better. So automatic forces you to use feature flippers. Now if you're not familiar with feature flippers it could be as simple as a if statement. What you're doing is you're saying release is now controlled by software. It can be whatever we want. We have a 19 step feature release process where every person in the company gets to individually sign off and turn the key. That's fine. You can automate that. I don't care. You get to pick. But what it does is it changes it to software and it means that we can deploy any time we want. And we know that features are going to go live because they're hidden behind these feature flippers. But can you just use feature flippers to push button the board? Like is it a feature flipper? Like one of the gold standard practices where you continue to still agree? Yeah, it totally is. But here's what I find happens. Without this feedback cycle, without this dilute you have a top-down approach to feature flippers. I see this pattern with all of the best practices you can do to deliver it. Someone says, hey, feature flippers are great. They would solve this problem. Let's make sure you use them every time you need to. And then you have watch developers that are excited and trying to do the best effort. And you have a couple of lagging developers who just don't want to do it. And resist it.  I don't want to write those statements. And there is a lot of resistance to what I call scaffolding code.  Because it makes your code look worse. And without that scaffolding code it would look better. And so there's definitely a developer pushback. And so you have to fight that battle. Versus with an automatic deploy developer sits down to start working on a feature that's not ready yet.  I can't do this or I will cause bugs into government. And so now the developer is asking you, what's the solution to this problem? And you can point a feature for those. This is a much, much, much better model. This is something I think about a lot when designing processes when matching them to organizations. I think about it in terms of push and pull. Methodality is pushed if adoption is optional and driven by vandalism. And it's pulled if adoption is mandatory and driven by necessity. I was in the continuous integration very, very, very, very, very early. I worked on BuildBot one of the first open source CI servers. I didn't do a whole lot with it. I was in high school. But it was very interesting to me. And so when I finally got into the industry and started working, I was like, okay, I'm going to show everyone how to continue this integration. And I was going to write tests. It was going to be great. Now we're going to have a CI server and it's going to run. What did I find? About half of the people would adopt it. And they would have a relatively positive experience. And the other half would hate it and never adopt it. And you cannot do continuous integration if it's half adopted. And I found this story repeated everywhere. You would have test practitioners who loved tests and people thought that it was a personal preference. Oh, you're just a person who loves tests. You'll write them. I won't write them. Oops, I broke your code repeatedly in my bag. Tons and tons of stress. If you're trying to drive adoption of something, find a way to pull it out of the organization instead of pushing it into it. Adoption will go much, much faster. Switching gears a little bit to the next sort of pitfall I see in continuous deployment. Service-oriented architecture. I think it was a little service-oriented, but it was basically a monolithic codebase that got deployed to multiple targets. It wasn't what you think of as a sort of modern service-oriented architecture. And so we didn't have a lot of these problems. There's something that I got to learn about more as I built Canvas and as a consultant elsewhere. And so in a service-oriented architecture, you often have all four play pipelines.  Everything's great. We can deploy a few things in parallel. This looks really nice, except here's what's actually I need to build a feature and it needs to touch both the backend and the front end. And so I commit both of those changes. They start walking through their respective deploy pipeline, and then they sit here. Now probably I'm on the front-end team or I'm on the backend team. There's another team that owns pushing the button to the other service. Maybe I can talk to a couple stakeholders. Maybe I don't know who can push the button. And what I've seen happen, usually this happens once or twice and people figure it out, is that the button gets pushed in their own order and the front-end change goes out live first and now we're broken. And so service-oriented architecture presents an interesting wrinkle in complication to continuous delivery and continuous deployment.  Well, you have to commit to the backend first. And you have to watch that go out and then you have to wait while you figure out who can push the button and push the button is the time to push the button that we waited two days, whatever our delivery cadence is, and then finally go live. Now, and only now can I actually really just commit that change. If I've been holding another change off on a branch or locally on my laptop, and then that could finally go out and maybe another waiting period before I push the button, then we finally have it. This gets slow and complicated and frustrating because I can turn around and push the button on my front-end service, backend service, and accidentally shift your commit too early. And the answer generally tends to be let's add more human processes to fix this. But that was way too simple of an example. No one has service-oriented architecture with two services. In the real world, it's like 5 or 15 or 500. They just seem to grow. Plus you've got databases. Like a database is basically another service or another deployed pipeline. If you push the image changes out, they have to go off first. And so you end up in a world that looks a lot more like this.   I mean, as an application designer, as an architectural person, it's great as a lot of advantages. But people who think about service-oriented architecture are often not the same people thinking about the deployed pipeline. So the naive way of doing service-oriented architecture ends up with this, a whole bunch of deployed pipelines. Now, automatic deploy makes this nicer. Because I can commit to the back end and probably it'll be deployed before I'm actually starting working on the front. And I can sort of work at my own pace. That makes things a lot nicer. And so if you're going to do service-oriented architecture, I highly, highly recommend you do it. Continuous automatic deploy. But now you end up with this other problem which is that you've got five deployed pipelines. That's really expensive. How do you actually maintain great automated deploys with production monitoring and automatic rollback and all those great automatic deploy practices? It's too expensive. I've had startups come to me and they go, well, we've got four engineers and we're going to do continuous deployment. Well, hire eight engineers or get rid of eight services. There's no way you can afford to do 12 continuous deployment pipelines with four people. That's nuts. And inevitably, they go, okay, now my continuous deployment is over. So here are options. One is template. So you say, okay, here is how we do our deploy pipeline and everything is going to roughly fall into this. Sometimes this means standardizing on language or framework the reason that developers themselves often want server-for-aided architecture is so that they get to pick their own personal favorite framework or language or tool chain. And that's really expensive. That's an antisocial behavior that says that I want to choose my things over the expense of everyone else who will eventually have to learn all of the different tools and technologies in our application. That doesn't mean you can't have more than one language. What it means is you need to pick those considering social factors, talking to multiple people on the team and understanding that it's an extra cost at the deploy pipeline stage. My favorite system is a unified deploy pipeline. As much as possible, figure out which of your services are close to each other, talk to each other frequently and unify them so you have a single build pipeline that eventually deploys to multiple services. This means that you can share code across those services very easily because they're all building out of a single repository. It also means that as a developer, I'm not afraid of touching back-end services even though I've been on the development of the whole pipeline because I know how the system works. I've watched it happen, I've done these deploy. This is what we built out at Canvas and we hired a new engineer and after a few months they had made a change to one of the back-end services. They didn't even know it was a different service. They weren't even aware. This worked so seamlessly they weren't aware of the complications that were being made. The next thing that I want to talk about is another bad habit, bad pattern I see. Staging environments.  Staging environments are a sign of fear. Staging environments are a sign of fear. They say, okay, our process is not yet good enough to go out similar to push, plot, and deploy. Our process is not yet good enough and it has the same problem.  The shared mutable state is terrible but the shared mutable state across multiple teams across multiple deploy pipelines. So, I'll go into a larger organization and there will be four or five teams and they'll tell me, oh yeah, we're doing continuous delivery. Oh yeah, we're doing continuous deployment in the staging. That is not continuous delivery or continuous deployment. And what's worse is, because staging is so bad, having all these users, he's actually touching it. We don't even know if it works right now. You know, maybe there's 10, 20 developers using it, maybe there's 50 customers who have asked to be alpha testers. But at the end of the day, staging can be broken overnight and no one will notice. And it's broken regularly. And I see, oh, Ops needs to test a new package so they just push the change in the staging. It turns out it didn't work. But don't worry, they're going to fix it in four or five hours. So that wouldn't be too bad if you just said, okay, staging is usually broken. We're going to try to push to staging but then we're going to go live after that. That's not what happens. What happens is another negative feedback group. Be able to deploy to staging. Staging is broken. Maybe it was the change, maybe it wasn't the change. It was a different production. Myriad of issues cause this. And it leads to less confidence in deployments. And the crappy part here is if you just push that change live, it's probably going to work. You could have skipped staging. So instead of staging, what should you do? Well, I'm not saying don't run integration tests.  Whatever that means. You don't need a full Android hardware or running in the cloud exactly the same way as your production hardware is. But you need to be isolated first and foremost. Only tests should have access to the environment. At least while the tests are on. It's nice to be able to pull this aside and debug it afterwards. You have to be able to recreate it automatically. 100%. And ideally, you do so on every single test. Now, I know that in certain environments that becomes very critically expensive. You can do it daily or weekly. Stay in that environment. But don't give developers direct access to that environment. Don't give operations direct access to that environment. Don't let it turn into a second-class citizen. If someone goes into your staging and changes the schema by hand, when are you going to find that out? When you try to commit code in breaks. And that's an awful, awful, awful feedback. The other nice thing is when you look at this, you've got four or five teams that previously were all going into staging and now have their own mini-environment being stood up by the test. So now they get to test against everyone else's known good revision instead of everyone else's broken version. Because they get to pick what versions they actually pick up in the test. And so that leads to a dramatically better pipeline. A dramatically better organization. The worst part about this is the blame pipeline. Because it's always somebody else's fault and your team is broken. And this just leads to incredible, incredible stress and really negative cross-team interactions. And those cross-team interactions are valuable. If you can't ensure that they're often positive, you're going to have a very dysfunctional software organization. And I see this often come down to just staging or not. Makes a difference in how it feels to be on a team. Switching topics, again. I promise I'll tie it all back together. Git. Git is one of the things that's changed since I first started talking about Continuous Integration. Is Git bad?  I kind of like it. I kind of hate it. Got a whole bunch of issues. There's one really specific problem when it comes to Continuous Integration. Branch-based workflows. Pull requests and code reviews. That's not even Continuous Integration! Woo! I spent too long on this, I'm sorry. That's kind of that crying because you guys aren't doing Continuous Integration like 20 years later. Two steps back to the industry. No. Don't get me wrong. It's a GitHub flow model. Branch-based workflows. Those are really, really good for open-source software. When I was working on Twisted, when I was working on Buildbot, they called it UQDX, Ultimate Quality Development System. And it was like 1,000 lines of shell strips that scripted subversion and tracked so that you could do branch-based workflows that were connected to tickets. They got merged after code review. It was the GitHub flow model in 2005. And it's great for open-source software. But open-source software is not what you are probably doing day to day. You're probably at a corporation. You probably work with a team that you know. You're probably going to continue to work with that team. You probably work out of a single master branch. You probably don't accept contributions from a thousand strangers every year. You probably have a single place to deploy to or a few known deploy targets. And you probably want to get your code deployed as fast as possible because you have a high level of quality with everything. And under those circumstances, branch-based workflows don't make sense. So what's the solution? Never branch. The only time that branching makes sense is when you're spiking more prototyping code that you're going to throw away. You're going to just get rid of it. If you're going to write code and it's going to live in production, then you need to do it using continuous deployment. And you need to commit it frequently and regularly so that you can integrate with everyone and everyone else can integrate with you. Again, this isn't even continuous deployment. This is continuous integration. I'm just telling you what can't be said a long time ago. So then that always brings up the question, are you saying get rid of code? I'm definitely not saying that. There's a lot of good uses of code. But there's also a lot of bad. And the reason that people usually want branch-based workflows is because it catches bugs and it means that terrible engineers can commit code and you can somehow magically turn that into good code. And both of those things actually kind of make sense in an open source world. But again, in a closed source, in a really corporate development environment in a small team's working on their project, it actually doesn't make sense. If your code review is catching bugs, you have serious problems and those are further up the pipeline. If you can automate catching those bugs, then everyone can work dramatically faster. Because what's the turnaround time? How fast are you actually getting code reviews done? Even really good organizations like GitHub, they're deploying all of its mind, they would say the new continuous delivery and they might argue with them, but they do this model. And the only way it works is because they have hundreds of engineers that are all just picking up code review. And so their throughput is acceptable, but still surprisingly slow. They still have the problem where someone will accidentally have a branch open for two or three days and then have integration. And then try and land too much code all at once. And try and push a couple thousand lines to code out and work out all of the problems that were noncontinental. In practice, it sends up being like a week. Two or three days to write code, do a core quest, get a code review, have to fix stuff. That took a couple of days because everybody was busy and code reviews get deep prioritized because everyone wants to work on features, move their scrum tickets along. So it just falls behind and your latency increases. Everything I'm telling you about here is about reducing latency because reducing latency makes everything better. Do not do this. So how do you actually do it? How do you actually do code review? You can do it after deployment. It turns out this works really, really well. There's a bunch of human-level factors that I don't know how to automate. I don't know how to automate readability. I think at the point that we can automate ensuring readability, I'm out of a job and AI has already taken over the planet. Code review is still useful for these human factors. Promoting code reviews, code reviews, promoting knowledge sharing, minimizing your bus number, making sure that there's no aspect of your application that only one person understands. All of these can be done with code review after deployment. So in fact, that's what this looks like, is everybody commits to master code review.  The works are very, very similar to a branch-based model, but I'm looking at much smaller snippets. And I'm also not worrying about bugs, because it's already been deployed, probably been out there for three or four hours. Odds are I'm not going to find any bugs in that code. Another really good method that I like even more than reviewing individual commits is it? I don't know what your experience with code review is, but it's like two-thirds of the code reviews are nitpicks, and they're annoying nitpicks. Oh, you shouldn't have this space here in this if state. I would use this other library function, it's equivalent in every way, and I don't know why I'm telling you this, but it's my preference. I hate that kind of code review. It's awful. So instead of doing that, do a feature-level code review.  And then have another technically incumbent. I've seen this take place on a projector with the entire team in the room, where someone has sort of a line through the code, and your goal is just to explain the code to that person, walk them through it.  These are the important issues. These are the issues that you're going to hit a year from now and go back and try to do this code and go, what was I thinking? Why is this organized this way? I don't understand it. It's a valuable use of programming. So higher-level, looking at data flows, instead of looking line by line, looking at features in an intelligent way, asking about the architecture. And better yet, if you can build this into your feature release system, you can say, okay, well, every time that we're about to release a feature, we're going to do a program review, and we're going to budget a date, now all of a sudden you can build the feature slightly wrong and actually have the budget because I don't know about you, but every single time I build a feature, I get to the end and I'm like, well, that was slightly wrong. Because that's programming. The details matter, and you don't know the details until you actually build it. So, oh yeah, I wanted to tie all these things together. So it turns out that, I don't have a slide for this unfortunately, code review slows down your latency.  Push button avoids slow down your latency. And all three work together at unison to cause organizations that claim to be doing continuous delivery having two or three week latency between the time that someone's done writing code to the time that it's actually live and being run by users in production. And that is not continuous delivery. That is not what was intended for you. That is far from level one. And so these anti-patterns are unfortunately collude together to cause a lot of frustration. Everyone's like, well, we're doing all the right practices. All the right architecture practices and also all the right continuous delivery practices and then they don't mesh together. And so you need to avoid these big problems. I think I've given one form or another of this advice to every single company I have consulted with over the last five years. It is that common. People keep making the same mistakes. So if you get to continuous deployment, by far the most surprising thing about adopting it is that deployment is stress free. When people hear about continuous deployment, they think about an extremely high stress model. They think, oh, every time I deploy right now it's super stressful and things go wrong and we have postmortems and it's awful. Why would I want to do that more? Why would I do that all the time? Even if it works, even if we don't have problems, I'm going to be sweating nervously the whole time. And that's the general intuition. It's just not true at all.  On your 100th deploy, you literally forgot that it deployed. You committed and stuff just happened in the moment. It's incredibly stressful. It's easy to go, oh, yeah, we have to push this hotfix. Well, that's fine. It's going to go through all of our normal deploy pipelines. It's nothing special. I used to teach people at IMU how to handle production outages, cluster failures, and required code changes. The worst possible type of bug. It's hard to teach. You know the first mistake people make is when they try to fix higher priority bugs where dollars are on the line and you have the right code with the gun in your head? You don't write a test. You don't follow your basic class. And it turns out, you're probably going to screw up because you're under a lot of stress. Things are going to go even worse. So if you say, no, no, we always follow the process. It doesn't matter if it takes you 10 minutes extra. The company will pay for that loss revenue or something like that. You'll probably not have a bug. You'll probably push the bug. So summing up what I've learned from teaching continuous delivery and continuous deployment. Continuous anything is great. I'm not here to bag in continuous delivery. Sometimes you have to do something like that if you're shipping an iOS app. You've got a gatekeeper. You can only deliver the ones a week. You know, automatic would be better, but I've got a question about it. People say continuous delivery and continuous deployment, and they mean the same thing. I don't care. My language is living. I don't have a say in it anyway. But what I want you to take away from this is to have continuous deployment as your goal. To always be seeking the automated version. To always be continuing to try and deliver software slowly and easy. And to push back when people try and slow that down. Because if you don't set out this way, you will get stuck at roughly a one week delivery cycle. That is the pattern that I see over and over again. It doesn't matter how big your company is. It doesn't matter if you're super well funded startup or scrappy bootstrapping. It's the same problem everywhere. And now I'm out of a job as a consultant. So, I guess this is my retirement speech. Okay, so now I'm going to switch gears. We went through basic stuff, intermediate stuff. And now I'm going to bladder a little and hopefully it makes sense. So, I'm going to talk about the future of continuous deployment. Really, that's the future of software. So, just picking a project at random. I looked at a 2006 version of Buildbot. And the set of instructions were to manually go off. And they just listed these packages as requirements. You had to Google them. You had to figure out how to install them. It was all manual. You had to install that. From a Python perspective, there's no pool in your class. Contrast that with today. We're going to data warehouse project. This is a graph of the Python dependencies. There are 15 explicit dependencies. And those branch out. Each of those dependencies have dependencies which have dependencies that lead to 66 different things being integrated to a 5,000 line project. It was a huge explosion of integrations. And integrations that aren't within my organization. I can't tell any of these packages how to manage how they work. I don't know how reliable they are in updating. I don't know how frequent. I don't know how much to trust them. I deleted actually which packages we had to pick specific versions of. Because I didn't want to call out anyone. Everybody has a package manager. Even old languages that didn't have them are getting them very quickly. Everyone is stuck in the same boat having to manage incredible complexity. Projects have more effects. More libraries, more frameworks, more API integrations more frequent deployments more frequent needing to take updates and all of these things. And so what we're starting to see is the continuous deployment of things that you wouldn't traditionally consider standalone software packages. We're seeing continuous deployment libraries, frameworks, operating systems. For example, Google Analytics. You say, please give me a Google Analytics. I have this API. Google gives you the latest code. Or an API experiment. Or something else. You don't care. It's out of your hands. We've been seeing this with operating systems. By a case-by-self track, you can just say, yeah, auto-apply updates. Any hot fixes to my terminal I don't care when. All of this is towards one goal. And that is to stop wasting time trying to keep up. We're starting to get faster and organizations are spending more and more time keeping up. If you really want a good example of this, look at JavaScript. JavaScript programmers, if they've been in the industry for more than four or five years, they all have the same fatigue. They've all been around the block and seen three different frameworks evolve and become the oddest thing and then die. And they've also watched their own marketability as a developer. Just fluctuate wildly. They're apparently tightly coupled. And in fact, this ends up potentially killing whole languages. Perl 6, Python 3. We're now at like a year 10 of the Python 3 transition. And I started a new project this year. Python 2. I was a huge evangelist for Python. I can tell about four or five years ago when I realized that it's kind of dying because this transition is so extensive. AngularJS is switching the languages that it's written in. Ruby on Rails projects that are more than three or four years old, you should just rewrite them. Actually upgrading these two concepts. This is a huge problem for our industry that we're going to have to face. So here's my big prediction. The next big language and or framework, the winner will be whoever can sustain evolution across organizations, across integrations, across platforms. And that's a big shift from the current paradigm, to whoever has the best marketing and whoever shows me the best static code examples. That's what I want to use. Now organizations are starting to get smart enough. I don't know what the timeline is on this. It might be five years, might be 15. You know, I'm only mostly perfect at predicting the future. So what would that look like? Here's a hypothetical. What if your programming language doesn't support the code migration, so that your frameworks and your libraries, when they updated, when they made a breaking change to their API, they could ship with it a little snippet of code that could update your code to work with the new API. Now obviously, there's a thesis with this, doesn't there? Were you surprised how much time and effort and stress and frustration goes into like changing the casing on an accidentally mis-cased class in Python. Like some of those changes had to wait for the Python 3 rewrite. So what would that look like? Imagine you write in a tiny little language that says, okay, well, we're re-enaming old class to new class, or we're changing a signature, or we're adding a new parameter, and here's a default, so if the calling site doesn't have anything to discuss right there, it just automatically becomes null. And we're seeing a little of this right now. This is a library design just to help this transition between Python 2 and Python 3. And in Go, you have Go format, which most people just use to pass it their code and it automatically makes it look correct. They have a single correct version of how the whites should be. However, it's actually also really good to be passive, crazy command line arguments and automatically do refactoring. And you'll see in the release notes that it's not for Go. Hey, we change this minor thing, we don't think it's a big deal if you run this Go format. And I've seen people share, hey, we updated this project, here's a Go format line. What I propose is that these are going to become not just standard, but built into the way that we build and develop software. And overall, this is all pointing to one trend, which is a prioritize change in code over the static code. I don't care about the 10,000 lines of code I want to add to it. I care about the refactoring and how they integrate with other people's changes. We're a world where if I actually count up a number of developers on my 5,000 line project, I looked at all the open source contributors, all the contributions, all the patches and changes, it grows to be beyond the comprehension of any one individual. And that's a small project. Can you imagine an operating system? This focus on change I think is going to revolutionize our industry. I don't know how it will perform, but I'm really interested and I'm excited for the future. Thanks. Any questions?


Welcome to Capital Beat, a joint production between the Vermont Press Bureau and Orca Media. I'm Joshua Gorman. Joining me is Press Bureau Chief Neil Goswami. It is Tuesday, May 10th, and this is the final episode. We're gonna do a wrap-up of what happened with the legislative session. We're gonna talk about the budget. We're gonna talk about marijuana. We're gonna talk about independent contractors and everything else that came up. And so to begin, Neil, a lot of Durham and Strang coming out to nothing with this pot legalization. Tell us how things went and how things ended up. Yeah, so we'll do a quick recap of last week. Lawmakers worked pretty late into the night on Friday, wrapping up their business, voting on money bills after, I guess it was around 10 o'clock or so. They then, leaders who are leaving their positions, House Speaker Shapsmith, Senate Pro Tem John Campbell, Lieutenant Governor Phil Scott, and Governor Peter Shumlin all addressed lawmakers at the close of business, and they finally gaveled the session out right around 12, 20 or so on Saturday morning. So the legislative session is officially over. We are going to have a very new look and feel next year with the new Speaker, new Pro Tem and new Governor and new Lieutenant Governor. This is the first time this has happened in quite some time, right? Yeah, most people can't recall when there was such a historic turnover of leadership positions at the state house or in state governments. So it'll be interesting for us and the media. It'll be interesting for voters and it'll be interesting for other lawmakers when they return next year to see who is in charge and sort of who claims the power base here. Shapsmith has been a very effective and powerful speaker and he seemed to have sort of more sway over legislative affairs than the Senate Pro Tem John Campbell. And early in his tenure, Governor Schumann was more powerful and we saw that sort of wane over the years. Now in his sixth year, he was not as effective as he hoped to be. And we'll talk a little bit about that as we go through the issues. So kind of exciting and a little bit unnerving for a lot of people as we move into a new era of state government as these four gentlemen go off to different things. As you mentioned, one of the issues that lawmakers tried to tackle this year was legalization of marijuana for recreational use. We've talked a lot about that on this program before and it's been talked about on lots of programs out there but there was no sort of last ditch effort or trick up their sleeve to get marijuana legalization over the finish line. The Senate, as everyone knows, passed S241. It created a legalized retail market for marijuana. I think it had 54 retail outlets throughout the state that it would have been, that would have been permitted under the bill. But the House never really warmed to that position and really didn't warm up to anything at all regarding legalization. They didn't agree to that proposal. They tried to pass the study commission to the House Judiciary Committee amended the Senate bill to include a study commission on the issue that would report back to the legislature. Even that didn't make it through to the end. A final compromise that the Speaker and Democratic leadership in the House tried to put forward was decriminalization for the possession and cultivation of up to two marijuana plants. That also failed on the Senate floor. I think it was a 70 to 77 vote. The Senate plan, which finally did get a vote on the House floor, failed miserably, 121 to 28. This was something that Governor Peter Shumlin really wanted. He pushed for it. He worked the final weekend before the voting took place. His administration worked to find the votes and Shaft Smith had been warning him and other advocates that the votes weren't there and it shouldn't come to the floor for a vote because it would go down miserably. But they kept pushing for that vote and they got it and it turns out Shaft Smith was right. So you know, one of the things that Shaft said to us going into the weekend before that vote excuse me, is that he didn't wanna see a vote because he was worried he was going to possibly set back the efforts. Do you think the overwhelming drubbing that the bill received in the House is actually set back the cause for legalization going into the next session? You know, I'm not so sure about that. This conversation around the legalization of marijuana was certainly advanced this year. There's no question that the conversation now was about how and when, not if, to legalize marijuana. So if you are an advocate of legalization for recreational use, that has to be a positive step forward. And there's a joint legislative committee, judicial oversight committee that has agreed to hold I think six meetings over the summer and fall to figure out how to move this issue forward which is also a real step forward for advocates because the House was very, very reluctant to even consider this issue this year. House Judiciary Committee Chairwoman Maxine Grad, a Democrat from Moretown, didn't even want to take this up after the Senate sent it over. But she did so reluctantly with urging from the speaker. So the fact that there's a joint House and Senate oversight committee that will talk about this over the summer to figure out how to move it forward is a good thing. I'm sure advocates are very disappointed they couldn't get something more concrete even the decriminalization of two plants. But at the very least they have some momentum and some positive aspects to take forward into 2017 which I'm sure this will come up again. Absolutely, and I would say the opposition to marijuana actually manifested itself in the form of a counter attack with law enforcement advocating and almost getting roadside saliva tests, right? Yeah, that was an interesting thing. And people like the ACLU of Vermont, Alan Gilbert, the outgoing executive director there, raised some very serious concerns about that and it didn't pass. And it's probably a good thing that didn't pass. It seemed like there were a lot of scientific and legal questions around how effective this testing was and whether or not it actually could prove that somebody was impaired on the roads after smoking marijuana given the questions about how long it stays in your system, how effective the testing is, and also what the legal ramifications are, whether it could be used simply for probable cause or as a piece of evidence against somebody who has stopped and believed to be driving under the influence of marijuana. So in the end that was pulled out of bills that were moving ahead and they opted not to do that. We should say there was some positive developments on the medicinal marijuana front. The legislature agreed to include glaucoma and chronic pain as conditions that would qualify you for medical marijuana. And that allows you to possess and grow marijuana legally if you are registered with the state. And they also shortened the timeframe that you have to work with your doctor to be eligible. In that sense, the medical marijuana stuff did move forward. The recreational use will be another conversation for next year. I see. Yeah, yeah. There were a couple other judicial reform stuff that sort of wrapped up at the end of the year. There were a handful of bills that were sort of, the House and Senate were angling over and holding up in hopes that their priority would also advance. In the end, they were able to pass a reform of driver's license suspensions. Chittenden and Windsor counties have held license restoration days where people who have really old, outstanding traffic fines were able to go and settle them at a very reduced rate. And the governor asked lawmakers to do that on a statewide level so that people who are constantly driving around with suspended licenses and accumulating more and more fines that more than likely they will never be able to pay or just never pay. They'll be able to settle those and become a legal driver again. So House and Senate negotiators were finally able to determine that tickets issued before July 1st, 2012 will be eligible for this program that'll allow them to get their license back at a far cheaper rate. And there was another bill that Senator Dick Sears, the chairman of the Judiciary Committee, really, really wanted was reforms to how youth offenders are dealt with in the criminal justice system. The legislation will raise the age to 22 for youth offenders who can be referred to the Family Division of Criminal Court, which, as people might know, is confidential and would protect their records from public scrutiny. So all those college kids who do something silly while they're at school and they may face a criminal charge, they can now be referred to the Family Division and have their records protected as they go on to graduate and grow up and move on to the real world and look for a job. So those are a couple of pretty significant reforms that will probably have some pretty long-lasting impacts on a lot of Vermonters that the Judiciary Committees in both chambers were quite happy and proud of. Excellent. The DLS reform was one of Schumann's priorities in the outline during his final state of the state address and that was a victory that he got. One thing that he did not get that he pushed for all session was a call for divestment from fossil fuels. That's correct. So tell us about how that ended up, I guess, not happening. It's still, I suppose it could happen but it won't be a result of legislative action as the governor called for back in January. He wanted legislation that would have the state automatically divest itself from coal and fossil fuel stocks. Lawmakers were not going to do that. They simply said, no thank you. And the governor is now working sort of with state treasurer Beth Pierce and an investment committee that sort of helps her make decisions on how state funding will be invested, state money is invested. So there's a subcommittee now looking at this issue and they may or may not decide sometime in the future to divest but it won't be this sort of automatic thing that the governor had hoped to get through legislation. You know, and there's, treasurer Beth Pierce has been opposed to divesting from these stocks saying that she has a fiduciary responsibility to do what's best for taxpayers and retirees that count on this money being invested wisely. And you know, there was a lot of back and forth all session long. There were a lot of divestment supporters wandering the halls of the state house working the issue. But in the end, we'll have to wait and see what this committee decides to do. And it was something that, another thing that the governor couldn't pull across the finish line this year. Yeah, and to be clear, the Vermont Pension Insurance Committee has voted numerous times in recent years to commit to not divest. So I don't know if we're expecting some sort of change of art here or some sort of change in leadership. Is that what it's gonna take you think? Probably more change in leadership than a change of heart. It's not, you know, it's hard to say what a group, independent group like that might do, but it just seems to me that it's something that they've been unwilling to do in the past. So, you know, I'm not sure all that has changed to sort of send them in a new direction. Lovely. Yeah, so you've been doing some wrap up stories on a couple of issues. Independent contractors was something that got a lot of ink this year and it turned once again into a whole lot of nothing. Yes. Fill us in on that process. Sure, well, you know, people, there's very few people would say that the current independent contractor laws that exist that define what an independent contractor is are clear and easy to understand for employees, employers, and for enforcement agencies with the Department of Labor. They currently have a series of tests, including are you performing what they call so-called like work, meaning if you are an employer and you have employees that are, say you have a landscaping company or something and you have people who are cutting, cutting grass or something like that, that you can't bring in people who do the exact same job but then just treat them as independent contractors. And so, folks are saying that, hey, this is really stifling development in Vermont's growing tech sector that these high tech companies should be able to bring in independent contractors when they need to, if they're working on projects that might be of a limited scope and that's something that's ongoing. So, folks have been trying to, so the House Committee on Commerce and Economic Development spent most of the first half of the session, I think some of the second half, working on a bill to redefine how independent contractors would be defined. And this bill came out with universal support, a vote of 11-0 out of the committee. And when it came time to bring it up on the House floor, House Speaker Shep Smith said, I don't think this is ready right now. He was afraid there's gonna be a fight with the government operations folks and he saw that it was not, he believed that he was not gonna have a lot of support in the Senate. And so he actually asked that the bill be recommitted and this was a real blow to folks such as Corey Parrott and Heidi Sherman who serve on that committee and who are really, really pushing for this to happen. So they went ahead and they took it back and they worked on the bill and the bill appeared to die. And then magically it was resurrected with like a week left in the session. Kurt Wright asked that that committee be relieved of the bill and they're gonna bring it up on the floor. And so that kind of pushed the issue and they said, okay, we need to come up with something that's going to make it different from the bill that we didn't have. And so representative Mary Hooper from right here in Montpelier came up with compromise amendments that barely got out of committee with like a six-five vote and only with a positive vote was somebody who ended up opposing it. That would be representative Michael Markot. The vice chairman of the committee. Yeah, the vice chair who voted in favor of it just to bring it to the floor even though he didn't support the bill. And so this bill ended up dying and for folks who were really gung-ho to reform the way that independent contractors have defined this is a tough loss. And the way it died was interesting as well. It was a motion from representative Chris Pearson, a progressive from Burlington who made a point of order that it should go to, I think with the Ways and Means Committee. Yes, right, because there was going to be an impact on the state's unemployment insurance fund. And so it's going to have an economic impact that should go to Ways and Means. And so yeah, with this procedural move it effectively killed the bill for the session. Left not enough time for it to sort of come back and be on the calendar again. So yeah, very interesting. I think there were a lot of people who felt like they were going to actually be able to get this done. It's been an ongoing question for years and once again, it came up short. There was one big victory that the governor can claim this year, paid sick leave. Yes. And that seems like so long ago now. It does. But they did get that done this year. Yeah, and it was a long road for sure to make this happen. The paid sick leave bill passed the house during the 2015 legislative session. And they went ahead and then the bill went over to the Senate and there's much debate what form should this thing take? What changes are they going to make? And in the end, the Senate ended up approving the bill no fewer than twice through some interesting procedural chicanery. The bill initially passed. Never a shortage of that government. No, there wasn't. So the bill initially clear cleared the Senate and what the bill called for was employers and so workers who work in places with at least five employees or more would accrue as many as three paid sick leave days beginning in 2018. So the bill cleared the Senate and then Senator Bill Doyle out of Washington County the following day asked to reconsider his votes. And since he had been on the winning side he was allowed to do that. And so what that did is it brought it up again and allowed Senator Brian Campion out of Bennington into introduce an amendment that would have made a larger carve out for small employers so that there were basically the net result would be there'd be fewer employers on the smaller end who would have to provide paid sick leave. And so this was certainly a contentious issue and Campion's amendment was ultimately defeated and it was defeated with an affirmative vote or I should say a vote against it from his fellow County Senator Dick Sears who went ahead and switched his vote because he was upset about Bill Doyle switching his vote. And so in the end the Campion amendment was defeated and they substituted an amended version and what that does is it calls for a study to look at what the economic impacts are going to be for employers having to provide paid sick leave. Senator Joe Benning said, hey we should have had the study before we're passing this thing as opposed to studying the impacts after it's already been imposed but that's what ended up happening. So yeah, this is definitely a victory for folks who are really advocates for labor. It follows the raise in the minimum wage that came.  Yeah, another thing that happened early in the session that seems to be almost forgotten about now was the tweak to Act 46, the school governance law. What was that all about and why did they act with such haste to get that done? Yeah, I mean some people would argue that there wasn't enough haste taken. So what happened, so Act 46 is the big bill that calls for the merger of smaller school districts into larger school districts. And the advocates of this say that, hey this is going to, among other things, save money because it's going to provide for some measure of efficiency among school districts. You're gonna be able to purchase things on a larger scale and it's gonna be a good thing. But they realized that it's gonna take years, literally this thing is supposed to be done by 2020. So it's gonna take years to potentially find any savings. So they imposed this two year spending cap or I should say spending thresholds. You can exceed them. And so these thresholds are based upon, they're individual and they're based upon how much a school district spends compared with the statewide average.  And so what happened was last fall, all these school boards and these school districts went ahead and they started making their budgets and they were like, man, we cannot stay under these thresholds. And part of the larger reason is because they were hammered with this 7.9% increase in health insurance costs. I can tell you when the bill was being drafted and the spending thresholds were put in, it was kind of at the last minute and there wasn't a lot of consideration for things like, hey, what if we have a giant increase in the cost of health insurance? They were just kind of, the thresholds are just kind of arbitrarily tossed in there. And so what happened was lawmakers had to wrestle with, okay, what are we going to do? And Republicans said, hey, leave them in place. It's supposed to hurt as we were told. This is supposed to be difficult. You're supposed to make really tough cuts. This is supposed to be painful. However, in the end lawmakers came back for a special session early on a Saturday morning on January 30th to go ahead and change the thresholds. And so what this allowed them to do was to meet the January 31st deadline for school districts to warn their budgets. And so lawmakers went ahead and patted themselves on the back going, hey, look at that, we made it. But in reality, school districts had already created their budgets with the thresholds in mind. So the idea that somehow they, that the school boards were able to go ahead and make all these adjustments, I mean, they really had 24 hours to do it. So yeah, they went ahead and did it, but I don't know. So much to do about nothing perhaps? Well, I mean, it was a good thing, but it was a sort of thing that maybe should have been thought about when they were first doing the thresholds in the first place. So they went ahead and changed the thresholds for this school, the budgets that people voted on in March. And they went ahead and got rid of the thresholds for next year all together. Yeah. Okay. We mentioned earlier that in a lot of ways this was a difficult year for Governor Shaman.  One of the things, another one of the things that he failed to pull through this year was a dedicated funding source for Medicaid. Last year, people will recall he tried to push the 0.7% payroll tax, which would have raised about $100 million, including federal funding for the state's Medicaid program. This year, after he was rebuffed by lawmakers on that, he returned with a plan to expand the healthcare provider tax. Right now, hospitals and the doctors they employ face a 6% assessment on their services that they pay to the state that helps fund healthcare initiatives. The governor in January proposed expanding that to independent doctors, those outside a hospital umbrella, and dentists at about a half, around under 3%, about half of what they charge the hospitals and hospital doctors. What have raised $17 million? Again, lawmakers said no and they didn't do that. They ended up passing a fee bill this year that raises $27 million. The biggest chunk comes from raising mutual fund registration fees, $24 million, and lawmakers argued that most of that money, almost all of that money, is coming from people out of Vermont, so it won't really impact Vermonters at all. They passed a smaller fee bill, I think that was, or excuse me, tax bill, that was maybe $3 million or so. The Senate stripped out a bank franchise tax, an expansion of the employer assessment to really bring down that tax bill and focus on raising money through fees. And then they wrapped up the budget as well, late Friday, 5.76 billion total spending, I think it was about 2.45 billion in state funds. Any surprises to you in any of these money bills? Surprises, no, I guess I, I mean surprises in that by the time it was all said and done, we all knew where we were gonna be going, I suppose. There was really no, last year we saw a lot of shuffling back and forth between, for private meetings between the speaker, the pro tem and the governor, as they really had some major differences over how to raise money. This year, it seemed like it was a much smoother process. They weren't really arguing a whole lot over the money bills. One of the bigger issues, I guess, was the renewable energy siting bill that had some hangups in the end. The bill tries to give local communities more say in where these projects, wind projects, solar projects can be put in their communities. But the big thing, the big hold up at the end of the session, which sort of leaked into Friday evening to everyone's surprise was how noise standards for wind turbines would be handled. And they finally agreed that they would go through an emergency rulemaking process with the Department of Public Service until they can go through the more formal rulemaking process. And that seemed to be enough to get everyone on the same page and agree to move forward with eventually creating some sound standards for these things that a lot of people claim they can hear when they're up near their homes. Yeah, do you think this satisfied the folks in the yellow vests who were, these folks who were at the state house who were at times, I wouldn't say packing the gallery, but certainly making themselves visible. They were certainly visible. You know, I think it does for now. I think the rulemaking process in which they actually set the sound standards is going to be the new battlefront. And I'm sure they will once again make themselves a very visible presence there and try to influence that process. So hopefully it moves the state forward and how and when and where these energy projects can be built. I think everyone generally agrees that renewable energy is good for the state. There's some questions about what's appropriate and what's not appropriate. So hopefully this can move the conversation forward. Great, so now we're leaving the session and we're getting into election season. Yes, yes, we are, yeah. So the fundraising can start, they have adjourned. Yeah, so in fact there's gonna be an event this Friday, correct? Yeah. Tell us a little bit about what's coming up. What is it? Palooza or something? The shappening. The shappening, yes. House Speaker Shapp Smith after eight years is on his way out. He's weighing a run for Lieutenant Governor. He was in the Governor's race last summer before pulling out in the fall when his wife was unfortunately battling breast cancer. By all accounts, she's doing much better and he is considering not the Governor's race but the Lieutenant Governor's race and he may jump in yet. But first, the Vermont Democratic Party is holding a party and fundraiser for him at the Vermont College of Fine Arts on Friday called the shappening. And it will be a celebration and fundraiser basically for the party. Now, I would imagine there will be nothing said of his pending, perhaps pending, LG campaign since that could raise some issues about in-kind contributions from the party to the campaign if it were to sort of be viewed as one thing. Yeah, we'll have to see how the shappening goes and maybe next week we'll get an announcement from Shapsmith himself about what his plans are. And so if Shapp enters the race, then he will be the third Democrat in a potential primary where people are voting in August, correct? Right, Senator Dave Zuckerman, a progressive and Democrat, is in the race, is Keisha Rahm, a representative from Burlington. And so it could be a three-way primary if he jumps in the race, but he brings with him a lot of sort of institutional power from the Democratic Party and perhaps a number of foot soldiers in the house who would work their districts for him in both a primary and general election against Randy Brock, the Republican candidate. So we have a lot to look forward to in the election season. I'm assuming that campaigns will begin ramping up now that they can focus entirely on this and not the legislative session. So we'll see how that goes. Absolutely, and so we're gonna have a real concrete idea of who's in the race and who's not in the race on May 26th, right? That's the deadline? State races, I think, have to file by the 26th of May. So we should have a good understanding of where legislative seats might be headed and where these statewide seats are going. I don't expect a whole lot of any real surprises for the statewide races at this point. The only pending question right now seems to be if Shaff Smith gets in the race for Lieutenant Governor. But there will be a number of interesting candidates for the House and Senate that we will try to do our best to keep everyone updated on after the filing deadline. Very good, excellent. So Josh, it's been a fun session. Oh yeah. Good work, appreciate it. Thank you. And we thank you for tuning in and watching us discuss the week's progress during the session and we'll be back next year on Capital Beat, a joint project between the Vermont Press Bureau and Orca Media. Thanks again.


Hi everyone, I'm Kylie, the wellbeing educator on campus. Just a few reminders at this time of the semester when things start getting a bit more stressful to take care of yourselves. Make sure you're getting enough sleep each night and make sure you're nourishing your body with lots of good foods on campus. Also start thinking about adding some physical activity into your day. Twenty minutes of anything you're going to do consistently will make a huge difference to your week. Have a look at our website for some more tips on staying well for this semester.