This video introduces our series on software professionalism. Let's imagine that we all live and work in a giant O'Neil habitat, plying the orbits between Earth and the Asteroid belt; gathering solar energy and mining the asteroids for volatiles, minerals, and metals. Such a vessel requires a lot of software. The software teams on board are led by "The General". In our imaginary world safety is paramount. Software problems could endanger everyone aboard. And so the General has established a code of standards, ethics, and disciplines that all programmers on board must profess. It is their adherence to that code that defines them as professionals. This series will investigate those standards, disciplines, and that code of ethics. We'll use it to compare and contrast with the kinds of professional standards we might need here on Earth. In this series we'll talk about the issues that affect your ability to write software. We'll talk about tests, estimates, and schedules. We'll talk about how to say "No", and when to say "Yes". We'll discuss ways of dealing with pressure and the unreasonable demands of users. We'll also talk about softer issues, like how you write code after a big fight with your spouse. How you focus your mind in the midst of a battery of distractions. How to pace yourself for a long project. We'll talk about honing your skills, managing your time, collaborating with others, and mentoring new programmers. Overall, we'll talk about what it means to be a professional. We'll discuss our ethical standards, and the disciplines that put actions to those standards. We'll talk about the lines we won't cross, and the promises we make to ourselves, to our employers, to our team mates, and to our craft. Welcome aboard The Clean Coder!

The code that I produce will always be my best work. I will not knowingly allow code that is defective either in behavior or structure to accumulate. What does this mean; and how are professional developers supposed to keep this promise in the presence of schedule pressure and deadlines? As programmers, what is our role and responsibility in keeping the software systems we create safe, stable, and worthy? Defects in behavior are visible and obvious to our users. Defects in structure are hidden from our users. Of the two, which is the most important? How should programmers prioritize them? What bad things happen when we get this priority wrong? In this episode of Clean Code Uncle Bob addresses these questions and discusses the moral and ethical elements of managing defects as a software professional.

I know, I know. 102 minutes! Yikes! But, boy-oh-boy did I have a lot of fun making this one. I mean, I really got my geek on to make this episode. After all, this episode it about Dijkstra, Edsger Wibe Dijkstra! One of the very first programmers in the world; and the father of Structured Programming. This episode is all about proof. It begins with the third promise from The Programmer's Oath: I will produce, with each release, a quick, sure, and repeatable proof that every element of the code works as it should. Then it explores what Dijkstra thought those proofs might be, and how those thoughts led him to Structured Programming and the elimination of the goto statement. We'll discuss how Dijkstra's ideas about program structure led, in the long run, to Test Driven Development. We'll also discuss how his ideas about proofs eventually failed; and the scientific concepts that replaced them. And get ready to see a lot of code -- some of it old, and some of it new, some of it borrowed, and some of it (well, yes, there is a sad story in here) blue. Also get ready for some math, and some logic, and a fair bit of the history of our profession. So, without further ado, let's get started on: PROOF.

Now of course you realize that an episode entitled Small Releases would be all about source code control systems -- right? Not just about source code control, but about the history of source code control. Makes perfect sense, right? Well, that's what you've got in store in this episode. This episode is all about the fourth promise in The Programmer's Oath I will make frequent, small, releases so that I do not impede the progress of others. Over the next hour, you're going to learn about the tortuous path we programmers took in order to shorten our cycles from days and hours, down to minutes and seconds. You'll learn why that shortening is so important; and you'll learn just what needs to be shortened. (Hint: It's more than you think.) So buckle up. Because after we talk a bit about Gravity Waves, we're going to uncover the history, and the future, of short cycles.

42! Don't Panic. Grab your towel and settle in; because this episode is a two parter. You knew it had to be this way, didn't you. I mean: 42! Life, The Universe, and Everything. That's the question we are answering in this two part episode. I've given this a lot of Deep Thought and this episode is the answer. Really. I mean it. And I'm not going to fall back on the question of the question. No mice. No dolphins. No sperm whales and flower pots. No cat lullabies. Nope. This time it is right. This time it will work; and no one will have to get nailed to anything. And no Vogons will wreck it all. The answer: The answer will be given in the first few moments of the video. I promise. And it is the answer. Once you hear it, you'll know it. The rest of the two part episode will be about how to apply that answer to software. And to do that we're going to look at a lot of code; and a lot of coding and testing techniques. The focus of all that code will be Ward Cunningham's FIT framework. Part 1 Segment 1. The Answer. Short, sweet, but right. Segment 2. The phases of matter. Our obligatory science lecture discussing why matter (water in particular) exists in three different phases: Solid, Liquid, and Gas. Segment 3. Code Coverage. Do you now how much of your project is covered by tests? Do you know how much should be covered by tests? Segment 4. Covering Action Fixture. A deep dive in which we cover some untested parts of Ward Cunningham's FIT framework with tests.

42! Don't Panic. Grab your towel and settle in; because this episode is a two parter. You knew it had to be this way, didn't you. I mean: 42! Life, The Universe, and Everything. That's the question we are answering in this two part episode. I've given this a lot of Deep Thought and this episode is the answer. Really. I mean it. And I'm not going to fall back on the question of the question. No mice. No dolphins. No sperm whales and flower pots. No cat lullabies. Nope. This time it is right. This time it will work; and no one will have to get nailed to anything. And no Vogons will wreck it all. The answer: The answer will be given in the first few moments of the video. I promise. And it is the answer. Once you hear it, you'll know it. The rest of the two part episode will be about how to apply that answer to software. And to do that we're going to look at a lot of code; and a lot of coding and testing techniques. The focus of all that code will be Ward Cunningham's FIT framework. Part 2 Segment 5. Mutation Testing How do you know that the covering tests actually test anything? Here we use the PiTest tool to find parts of the code that are "covered" but aren't actually tested. Segment 6. Cleaning. Now that it's covered, and we know the coverage means something, let's clean it up. Segment 7. Semantic Stability. For software, this is the answer: Tests that truly stabilize the semantic behavior of the system. Segment 8. Conclusion. Tying things up in a pretty bow.

What makes you productive? The music in your headphones? The size of your screen? The integrity of your test suite? What makes you unproductive? Meetings? Time management? Emotional Distress? In this episode, we deal with productivity. What makes you truly productive. What truly impedes your productivity. How can you be more productive and help others to improve their productivity as well. You will likely be surprised at my advice and conclusions; but they are based on my nearly 50 years as a programmer. If there's one thing I know, it's the things that impede my productivity. Do you want to go fast -- I mean really, really fast? Then pay close attention. Because the things that make you go fast, and the things that slow you down, are not what you think they are.

Estimates. Oh no, not Estimates! Yes, it's estimates. We're going to talk about estimates. We're going to talk about what estimates really are, and how to create them. We're going to talk about the fact that estimates need to be honest, accurate, and precise. And we're going to define those terms. We'll learn how to properly find, and specify, an accurate estimate. We'll also spend a lot of time understanding what it means for an estimate to be precise. And we will stress, over and over, that the most essential quality of an estimate is honesty. During parts of this lesson we'll get really techie and mathy. We'll study the statistical tools from PERT that can be applied to estimates. I'll walk you through the math. I believe you'll find it both fascinating and useful. But in the end, whether you use the math or not, whether you follow the techniques and procedures I recommend or not, the real lesson of this episode is about honesty. And how to present, with appropriate accuracy and precision, the most honest of all estimates: "I don't know."

Why do we need an oath? Why do we even need a profession? Why can't we just go on being happy-go-lucky programmers for the rest of our days? In this episode we will walk through the history of our profession. From its humble beginnings in the late 1940s, until today. We'll track the growth of our industry; and its relationship to society at large. We'll watch as society's view of programmers grew from shadowy figures behind the scenes, to naive socially inept geeks, to modern day heroes -- and villains. We'll discuss the role we currently play in society; and the unwitting trust that society puts in us. We'll talk about our own ethics, and our own standards, and the risk of continuing on our current path without establishing and enforcing those values. Take care. This episode is not for the faint of heart. There are some tough questions asked here; questions that we shall need answers to in the not too distant future.

By now, everyone has heard of Agile. But how did this movement begin? What motivated it? And what were software developers doing before Agile? In this episode we're going to walk down memory lane. We'll go back to the late nineteenth century to see the beginnings of the two major management philosophies that continue to influence us today. You'll witness the initial success of incrementalism in the early days of software. You'll see how the Agile mindset got an early foothold, only to lose it in the '70s. You'll watch as the forces of command and control asserted dominance over the whole industry. You'll hear the tales of woe and horror. You'll weep and moan with the victims And then you'll witness the resurgence of incrementalism in the '90s. We'll trace it all the way from the patterns movement to the Agile movement. And you'll see how, eventually, Agile became the undisputed victor. We'll conclude by describing that historic meeting in Snowbird in 2001; where 17 people forged the now famous Agile Manifesto.

How does agile go wrong? I know, I know, it's not supposed to go wrong is it? I mean, Agile is perfect right? Alas, nothing is perfect in this world; and that even included Agile. So what can go wrong with Agile Software Development? We'll talk about five things: 1: Flaccid Agile: Trying to do agile without technical disciplines. 2: The Invasion of the Project Managers: How Agile got co-opted by well meaning folks; and how that split the Agile community in two. 3: AgileFall: The ever present temptation to do waterfall and say you are doing Agile. 4: Agile Schmagile: The trap of thinking that Agile is nothing but a mindset. 5: Agile in the Large: What? That's a problem? Oh oh. So charge your phasers and raise your shields because this episode is all about how to do agile wrong.

This episode is all about planning a software project. Why do we plan? We plan so we can manage. What do we manage? We manage the deviations from the plan. As Eisenhower said, the plan is eventually useless -- the predicted results are not realized. And yet, having a plan, and predicting results is indispensable. It is this fascinating oxymoron of planning and execution that this episode describes and explains. And the solution to the oxymoron? Tom Demarco said it best: You can't control what you can't measure. -- Tom Demarco, Controlling Software Projects In this episode you will learn about measurement and control; and one of our first topics will be the Iron Cross of project management. The iron cross describes the "physical law" that constrains all management efforts. It also supplies the control knobs that managers use to drive the project to the best possible outcome. You will learn that proper management requires data; and that agile is all about producing that data. You will learn how short iterations, bad estimates, and rapid disappointing feedback conspire to help lead a project to a good outcome (if not the predicted outcome). You will learn that the aim of agile development is to destroy hope and provide a cold dose of reality to managers and developers -- because good management is impossible without facing reality. You will learn that iterations (sprints) cannot fail -- because the purpose of iterations is to supply data; not to finish stories. You will learn about Yesterday's weather, the notion that the best predictor of what the team can do is what the team has already done. And, most importantly, you will learn the immense self-discipline that is required, by all parties, when planning and executing a software project. And this is just part one. Wait till you see part two! That's where the rubber really meets the road. Oh, yeah, and in this episode we'll also solve the world's energy problems.

In this episode we are going to dive deeper, deeper, and deeper into the way agile teams plan projects and iterations. You'll see, in action, the project kickoff meeting. You'll watch as Priscilla, the product owner, reviews the user stories for the team. You'll be amazed at the skill and insight of Marty, the project manager, as he deftly guides the agenda. You'll hear Paula, the quality engineer, ensuring that stories are Independent, Negotiable, Valuable, Estimable, and Small. You'll be amazed as Ruby, Danny, and Jerry take the stories apart, estimate them, and negotiate schedule. You'll see it all. You'll see Iteration Zero. You'll see the estimation meeting, the backlog grooming meeting, and the iteration planning meeting. You'll see a standup, design, architecture, pairing. There's just no end to what you will see in this episode. We'll talk about velocity, and how to recognize and diagnose pathologies. We'll talk about scope management, and story points, and iteration length, and... Well... We'll talk about a lot. So, get ready for this one. Get ready for all the nitty gritty details of The Planning Game (Part 2).

The innermost grouping of practices within Ron Jeffries' Agile Circle of Life, are the programming practices. Test Driven Development Refactoring Simple Design Pair Programming We've already spent a lot of time, in previous episodes, talking about the first two of these practices; so in this episode we'll simply review them, and spend more of our time talking about how they fit into the overall Agile discipline. This is important because being an effective agile team depends, critically, on these practices. Being Agile, depends upon being simple. But being simple depends upon being clean. But being clean depends upon being free and able to do the cleaning. If you are afraid to clean, you won't clean, you can't be simple, and you will fail being agile. It's really as simple as that. So we'll talk about simplicity. We'll epand on Kent Beck's four qualities of simple design: Pass all tests Reveal Intent No Duplication Fewest Elements We'll also spend a bit of time talking about YAGNI: You Aren't Going to Need It. In the end, we'll make the point that being simple is very hard and requires a lot of work. Finally, we'll spend a bit of time talking about pair programming. We'll dispel the myths about this controversial practice, and show why any agile team must, out of sheer necessity, practice it properly.

Have you ever wondered what the Metaphor practice of Agile Development is? This is the episode where I'll tell you. We'll also talk about my deep dark past, my first job, my first car, my first donuts in that car, and -- well -- lots, lots more. This is the episode where we examine the middle circle of the Agile Circle of Life: The Team Practices: -Continuous Integration, -Sustainable Pace, -Collective Ownership, and -Metaphor. We'll also spend a bit of time talking about the role of the coach or (um) Scrum Master; and how that role has changed (degraded) over time.

Why do we do Agile development? What are the underlying motives? In this, the final episode of our series on Agile, we will discuss the reasonable expectations of our managers and users. For it is those expectations that are the true motivation for Agile Software Development. And what are those expectations? As you hear them, you'll find that you'll hear them with two different ears. The ear of the customers and users will hear something perfectly reasonable. The ear of the programmer will hear something insane and impossible. Or at least that's the way it will seem. It is Agile Software Development that resolves those issues and allows the reasonable expectations of users and managers to be reasonably achieved by programmers. So, listen carefully. Hear the reasonable expectations. Ignore the reaction of the programmer's mind. And learn how Agile practices make those expectations achievable.