The keynote I gave remotely at ACCU 2011. Over the last 50 years we've seen a lot of computer languages. From procedural languages, to structured languages, to OO languages, stack languages, logic languages, and even graphical languages, and languages based on the game of life. We've seen so many different languages, and different types of languages, that we need to ask ourselves a question: Have we seen them all? Are there any more types of languages that we haven't seen? Or have we completely explored the language space? And if we have, then isn't it time we pruned the menagerie of languages down to a manageable few -- perhaps even one? Other industries have done this? Why not us? Others disciplines have brought their notations down from dozens to one. Electronics, Chemistry, Biology, Mathematics, etc. And the benefits they reaped by doing so were significant! Perhaps it's time for us to follow suit. If we did choose a language, what kind of language would it be? What features would it have? What syntax would it follow? What paradigms would it conform to?
Get ready for something very different. This ain't no screen cast. This ain't no talkin' head lecture. This is an Uncle Bob Video! This is like watching Uncle Bob on stage, but more so. This is high content education that will hold your attention and stimulate your thoughts with its impactful and energetic style. Indeed, this is the remake of the original, brought up to the standards we've learned after two and a half years! So hold on to your hats and prepare yourself for a radically different kind of educational experience. In this video Uncle Bob shows why Clean Code is so important. He answers the question: Does Clean Code Matter? And he answers it emphatically in the affirmative! He explains how bad code leads to the downward spiral of The Productivity Trap. He describes the various ways and forms of Code Rot. And he concludes by answering the question: What is Clean Code? So don't wait. This one is almost a freebee. It's job is to convince you that you, your co-workers, and your managers will want (and need!) to see the rest. And besides, you don't really want to miss the astronomy lectures, do you?
Get ready for something very different. This ain't no screen cast. This ain't no talkin' head lecture. This is an Uncle Bob Video! This is like watching Uncle Bob on stage, but more so. This is high content education that will hold your attention and stimulate your thoughts with its impactful and energetic style. So hold on to your hats and prepare yourself for a radically different kind of educational experience. In this video Uncle Bob shows why Clean Code is so important. He answers the question: Does Clean Code Matter? And he answers it emphatically in the affirmative! He explains how bad code leads to the downward spiral of The Productivity Trap. He describes the various ways and forms of Code Rot. And he concludes by answering the question: What is Clean Code? So don't wait. This one is almost a freebee. It's job is to convince you that you, your co-workers, and your managers will want (and need!) to see the rest. And besides, you don't really want to miss the astronomy lectures, do you?
Episode II -- Names So, you think this is just going to be like the second chapter of the Clean Code book? Think again! This is a completely different take on the topic. Oh the goal is the same, certainly. But there are things covered in this video that were never mentioned in the book. And even those things that are similar are covered in a very different way. So even if you've read Clean Code fifty times over, this episode will give you more to think about. In this 40+ minute episode Uncle Bob will take you from the Earth to the Sun and then into the bowels of the Earth. You'll visit idyllic countrysides, urban back alleys, graffiti laden East London side streets, and even the Wild West as you explore the principles of names in your code. Despite the scenery, Uncle Bob never lets up on driving each point home so they become part of your daily discipline. He begins with the exhortation that names are not just a convenience for the programmer. They are the most powerful tool that programmers have to communicate with each other. Then he dives into a discussion on how to use names to Reveal Your Intent and Avoid Disinformation. From one code example to the next (showing up in the most unlikely places) you'll see Uncle Bob point out examples of bad names and good names. He'll explain why the good names are good, why the bad names are bad, and how to improve them. Uncle Bob will tell you how encoding schemes like Hungarian Notation began, and why you don't want to be using them in the twenty-first century. He'll go on to stress the importance of choosing names that make your code read like well written prose. Finally, Uncle Bob will tell you about The Scope Rule which will guide you in choosing function, class, and variable names of the appropriate length for the scope that contains them. So don't wait. If you want to be a clean coder. If you want to improve your skill and discipline, then hit the button and watch this episode now. Clean Code Episod
How big should a function be? 20 Lines? A screenful? Is there a way to know if your functions are the right size? Object Oriented Design involves the art of breaking applications into classes. But have you found all the classes in the design of your application? Is there a way to know? Functions are supposed to do "One Thing", do it well, and do it only. But what is "One Thing". Is there a way to tell if your functions are obeying that rule? The answer to all these questions is yes! And not just with some fuzzy hand-waving platitudes either. There are fool-proof and unambiguous answers to these questions. In this episode Uncle Bob (UB) shows you, in no uncertain terms, how to tell if your functions are the right size. He'll show you how to be certain that you've found all the classes in your design. He'll show you where they go to hide, and how to dig them out. And he'll show you what "One Thing" really means, and how to make sure your functions are doing one and only one thing. This episode is loaded with code; but it's no screencast! Oh you'll see some screencasts, but not in the ordinary way -- not hardly. UB controls these screencasts -- he controls the audio, the video, the speed, and the magnification. He narrates and summarizes and points out the highlights. You'll see what you need to see, without waiting for the typing. In fact, UB compresses two hours of screencasts into three sessions totaling about twenty minutes. So it's a wild ride. On that ride you'll learn why function size is so important to Object Oriented Design, and also just to plain old good programming. You'll learn the craftsman's way of writing and refactoring functions.
In this episode Uncle Bob enlists the help of the craftsmen at 8th Light Inc to expose how functions should be organized and structured. Topics range from error handling, and the debate over checked exceptions, to functional programming and the discipline of Command-Query separation. He talks about the OO and Structured paradigms, and discusses why the Law of Demeter is so important. He tells you why switch statements should be avoided, and what to do about them when you can't avoid them. In fact, it's really quite startling where this lesson goes. You wouldn't think that the simple topic of function structure would lead you into high level discussions of architecture and team management, but they do. So you'll learn about the importance of independent develop-ability, and the some of the theory behind modular and plugin structure and partitioning. Did you know, for example, that the main program should be a plugin to the rest of the application? What's the trick to avoiding a morass of XML files that feed the insatiable maw of your dependency injector? How can you avoid temporal couplings by "passing a block". What number and types of arguments should a function have? And is Structured Programming really still important nowadays? So set aside 90 minutes and get ready for a while ride through some lectures and code. Function Structure is about to begin!
This episode starts with the form of individual lines of code and ends up describing the form of the partitions at the highest levels of a system. That's a huge range, and it all begins with comments. Comments are lies. OK, that's a pretty controversial statement. But in this episode Uncle Bob attacks much of the old conventional wisdom about comments, formatting, coding standards, white space, indenting, switch statements, classes, data structures, and even system design and the separation of applications, databases, and views. How many comments should you write? When should you write them? Should you enforce comments with tools like checkstyle? You can bet that UB has a lot to say on these topics. How big should a source file be? How long should a line of code be? How should you use whitespace within your source code. How should you indent? Should you have a coding standard? UB's answers to these questions will surprise you. What is the difference between a class and a data structure? What things do they protect you from, and what risks do they expose you to? How can you use data structures and classes to cover those risks and create solid designs. Did you know that databases don't contain business objects? What do they contain? How should you design the boundary between your application and the database. For that matter how should you design the boundary between your application and the views? Indeed, what about boundaries in general? From the form of individual lines of code, to the form of the boundaries that criss-cross the system, this episode will load your brain with a lot of new ideas to think about. So get ready... FORM is about to begin!
There was just so much Uncle Bob had to say about TDD that he needed two episodes to say it. This is part one. This episode begins an epic debate between the vanguard of craftsmanship and the mirror forces of traditional development. The gauntlet is thrown when Uncle Bob describes the real reason that code rots over time, and how that rot can be prevented and even reversed by a comprehensive suite of tests created through the discipline of Test Driven Development. The mirror forces rise to the challenge and demand answers to the traditional and entrenched objections that have, for years, convinced them that TDD is a discredited and vacuous doctrine. Uncle Bob begs for time to describe what TDD is and how it works before he tackles the objections directly. The mirror forces are restive, but agree. After a brief time-out, during which Uncle Bob describes the origins of the Moon; Uncle Bob dives into the argument for tests. He talks about why code really rots, and what happens when it rots too much. He talks about the failure of big cleanup projects, and how development teams are often dominated by the fear of changing the code. "Code Rots", he says, "because we are afraid to clean it." Then Uncle Bob addresses that fear, and makes the point that if you had a suite of tests that covered every line of code in the system and ran quickly, you would not be afraid to make changes. You would not be afraid to clean the code. Next Uncle Bob dives into the three laws of Test Driven Development -- the central discipline of TDD. He describes each of those laws in turn, and answers the brief objections raised by the impatient mirror forces. Then Uncle Bob describes the benefits of following those three laws; the reduced debug time, the production of reliable low level documentation, the decoupling of the design, and the elimination of the fear of change. Finally, in the face of rising skepticism and impatience from the mirror forces, Uncle Bob finds a messy funct
Part 2 of Episode 6 -- Test Driven Development. This episode begins as the mirror forces of traditional software development lose patience with Uncle Bob's incessant preaching and demand a practical demonstration before allowing the debate to continue. Uncle Bob complies by walking through the famous example of The Bowling Game (You don't want to miss this!). In this example, Uncle Bob uses the three laws and the Red-Green-Refactor cycle to implement the algorithm for scoring games of 10-pin bowling. The demonstration begins with a quick description of the scoring rules. Then Uncle Bob leads us on a quick UML design session. Then TDD commences, and we watch Uncle Bob create the algorithm by applying the three laws of TDD in the Red-Green-Refactor cycle. Finally, the end result is compared to the initial design. Having satisfied, and impressed, the mirror forces with that demonstration, the debate begins in earnest. Point by point the mirror forces raise one objection after another: "TDD is slow" "Managers won't allow it" "Refactoring is rework" "Who tests the tests?" "Tests are fragile" "Tests can prove correctness" "TDD is too dogmatic" "Tests don't have to come first." "What about Legacy Code" "How do you test GUIs" "How do you test databases." "Programmers aren't testers." "TDD is too hard" One by one, Uncle Bob answers those objections. Sometimes the mirror forces agree. Sometimes they are skeptical. But they cannot deny the logic. In the end... Well, you'll just have to see. After the debate ends, Uncle Bob describes why TDD should be considered a minimum requirement for professional behavior. He likens the discipline of TDD to the discipline of double-entry bookkeeping used by accountants. He makes the point that developers should expect QA to find nothing. He concludes with the story of how Doctors learned to wash their hands. The lesson ends with a summary, and a promise for the next episode: "Use cases and High Level Design".
This episode destroys the common myths about software architecture, and reveals what software architecture is really all about. Software architecture is not about databases, web servers, dependency injection, Rails, Hibernate, JSF, Struts, Spring, or any other framework or tool. Architecture is about intent. When you see a web-based accounting system, the architecture of that system should scream accounting at you. The fact that it's a web based system should be unnoticeable. After all, the web is just a delivery mechanism; and we don't want our system architecture polluted with delivery mechanisms, databases, and other low level tools and concerns. In this episode, Uncle Bob re-introduces the concepts first espoused by Ivar Jacobson, in his epic book: "Object-Oriented Software Engineering". Uncle Bob describes what use cases are, and how to make sure they are delivery agnostic. He shows you how to partition the system with use cases as the central organizing principle, and the primary abstraction. He also demonstrates how to isolate the system architecture from the rest of the system. Uncle Bob illustrates how to use Jacobson's three primary architectural classes: Entities, Interactors, and Boundaries. He describes how this triplet helps to decouple the system architecture from the delivery mechanism, leaving the web to dangle off the side of the architecture like an appendix. Uncle Bob goes on to show how Model-View-Controller and Model-View-Presenter are used on the delivery side of the system. Then Uncle Bob hammers the point home with a case-study taken from his classic book: Agile Software Development: Principles, Patterns, and Practices. After an informative briefing from the stakeholder, he performs a use-case analysis, and a high level object-oriented design to create the architectural superstructure on which the rest of the application will be built. Finally, Uncle Bob tells us how to avoid a Big Ball of Mud, and tells us who the architects
In this video Uncle Bob begins his exploration of the S.O.L.I.D. principles, by beginning at the beginning, and laying out their foundations. This is the first of several new episodes that will do deep-dives into the principles one-by-one. We begin with the question: "What is Design?". We make the case, based on Jack Reeves' famous 1992 paper, that the design of a system is best captured by the source code. That all other forms of design documentation, regardless of their usefulness, are preliminary and/or ancillary. If the design of a system is it's source code, then cleaning the source code is cleaning the design. But what are the symptoms of poor design? How can we know when the design of our systems is starting to degrade? To answer that, we take a harder look at the Design Smells of Rigidity, Fragility, Immobility, Viscosity, and Needless Complexity. How can we identify these smells and clean them before they become a significant problem? Next we watch a batch of code rot. We start with a pleasant and clean design and watch as change after change degrades that design into a festering mass. Then we study an alternate design that does not rot when the same changes are applied. We investigate the difference between those two designs and discover the principle that underlies all of Object-Oriented Design. We do a deep dive into the history of OO, and derive a new and unambiguous definition of OO based on Dependency Management. Finally we take a brief look at the S.O.L.I.D. principles which will be the topics of the next several episodes.
In this video Uncle Bob will take you on a deep dive through the Single Responsibility Principle. After a little General Relativity, you'll learn just what a responsibility is, and how it relates to the users of the system and the roles that they play. You'll learn about the primary value of software, and why that value is not what you'd expect. You'll also learn how the proper allocation of responsibilities to modules impacts that value and means increased profits for your business. Uncle Bob will teach you how misplacing responsibilities can lead to design smells like Fragility and Viscosity. He'll show you the importance of separating responsibilities into different functions, classes, and modules. And he'll demonstrate different techniques for achieving that separation. Next, he'll walk you through several different Java functions and ask you to find the single responsibility violations. Then he'll show them to you and recommend ways to separate them. Finally, he'll walk you through the case study of a simple application, from inception to delivery. He'll show you how to find the responsibilities; and, following the principles of architecture from Episode 7, how the system can be designed so that those responsibilities are separated. He'll also show you where to get the code so you can study it later. So get yerselves saddled up and rarin' to go because yall're 'bout to stampede into The Single Reponsibility Principle. Yee Ha!
The Moral Center of Software Architecture. That's how Uncle Bob describes the Open-Closed Principle (OCP). In this episode you'll learn all about Bertrand Meyer's remarkable insight into Object Oriented Design and the motivation behind good Software Architecture. We'll discuss how it's possible for the source code of a system to be open for extension, but closed for modification. Then we'll show you how to construct designs that conform to that principle. Next we'll look at a truly awful design that violates the OCP and we'll show how that violation creates the design smells of Rigidity, Fragility, and Immobility. Then we'll present a truly elegant and beautiful design that conforms to the OCP. This design will startle you with it's essential simplicity; dazzle you with it's suave construction; enamor you with it's incredible flexibility. After seeing it, you'll begin to believe that software can be open for all extension and yet closed for all modification! Then we'll break your heart by showing you why the promise of the OCP is, in fact, a big lie. We'll tear that elegant design to shreds, and we'll show you why all that protection it claimed to offer was an illusion that depended upon prescience and perfect foresight. In the end we'll shatter your hopes and dreams in software design. Then we'll resurrect those hopes and dreams by describing a development process that helps to restore the truth behind the promise of the OCP. We'll show you that you can, in fact, make designs that conform to the OCP, if not in whole, then at least in part. We'll describe the disciplines that will help you to take the greatest advantage of the OCP. So sit yourself down and settle on in, because after we learn about the Quantum Discontinuity, we're going to open the can of worms called the Open Closed Principle.
Oh no! Not the Liskov Substitution Principle! Not that! Please! Anything but squares and rectangles and type and subtypes. Katie, bar the door! Mabel, hide the kids. Somebody run for the Marshall. Tell him: LSP is coming! That's right, in this episode (after a brief diversion through wave/particle duality) Uncle Bob takes on the dreaded Liskov Substitution Principle. He'll tell you all about the history of the theory of types, including Russell's paradox, and Turing's revelations. He'll show how this theory influenced early computer languages like Algol, Fortran, Cobol, and even C++. Then Uncle Bob will introduce you to Barbara Liskov, and the principle of substitutability that she wrote about back in 1988. He'll describe that principle in terms of modern languages like Java and Ruby, and he'll show how it relates to Martin Fowler's code smell of "Refused Bequest". Then he'll dive into the favorite old conundrum of the squares and rectangles, and he'll show that inheritance is not what it appears to be, and certainly not what you have been told it is. He'll teach you about the Principle of Representatives and the implications it has for sub-typing and inheritance. And you Ruby programmers won't get off scott free either! He's got plenty to say to you about subtypes in dynamic languages. Next, Uncle Bob will show you the cost of violating the LSP and will present heuristics and techniques for identifying potential violations, and for correcting existing violations. On the way he'll talk about the dreaded 'if instanceof' statement. He'll show why it is dangerous, and when it is appropriate. Then, true to form, Uncle Bob will present a case study of a subtle LSP failure, and the horrific consequences it causes. You won't want to miss this part. By the time he's done you'll be hunting all through your code trying to find and repair potential LSP violations in order to prevent all the nasty 2AM phone calls you will otherwise receive. So let the horses o
This is Part 2 of Episode 11 Oh no! Not the Liskov Substitution Principle! Not that! Please! Anything but squares and rectangles and type and subtypes. Katie, bar the door! Mabel, hide the kids. Somebody run for the Marshall. Tell him: LSP is coming! That's right, in this episode (after a brief diversion through wave/particle duality) Uncle Bob takes on the dreaded Liskov Substitution Principle. He'll tell you all about the history of the theory of types, including Russell's paradox, and Turing's revelations. He'll show how this theory influenced early computer languages like Algol, Fortran, Cobol, and even C++. Then Uncle Bob will introduce you to Barbara Liskov, and the principle of substitutability that she wrote about back in 1988. He'll describe that principle in terms of modern languages like Java and Ruby, and he'll show how it relates to Martin Fowler's code smell of "Refused Bequest". Then he'll dive into the favorite old conundrum of the squares and rectangles, and he'll show that inheritance is not what it appears to be, and certainly not what you have been told it is. He'll teach you about the Principle of Representatives and the implications it has for sub-typing and inheritance. And you Ruby programmers won't get off scott free either! He's got plenty to say to you about subtypes in dynamic languages. Next, Uncle Bob will show you the cost of violating the LSP and will present heuristics and techniques for identifying potential violations, and for correcting existing violations. On the way he'll talk about the dreaded 'if instanceof' statement. He'll show why it is dangerous, and when it is appropriate. Then, true to form, Uncle Bob will present a case study of a subtle LSP failure, and the horrific consequences it causes. You won't want to miss this part. By the time he's done you'll be hunting all through your code trying to find and repair potential LSP violations in order to prevent all the nasty 2AM phone calls you will otherwise
OK, this one's a little different. No science lesson. The tone is a bit more serious. (a bit more.) It's the conclusion to the series on the SOLID principles. In this episode we look again at the Payroll Example from Episode 7; but this time we do so in the light of the SOLID principles. In this episode we start from use cases, and work through each of the principles to create a design. We break up the use cases by using the SRP. We start to build the architecture using the OCP. We find LSP issues to solve in the complex polymorphism hierarchies. We find the ISP lurking in factories. And, of course, the DIP is everywhere. As we walk through this case study, we examine each principle in depth. We allow the principles to illuminate issues in the design, and then we discuss several ways those issues can be addressed. Bit by bit we piece together the design. Then we close by taking a lesson from Joel Spolsky when he criticized these principles several years back, without really knowing what they were. So sharpen your pencils, you're going to need them, because this is an in-depth review and case study of the SOLID principles.
Do you like coffee? This episode is all about coffee. Or, rather, it's all about making coffee. This episode introduces our series on the SOLID principles of component design. In this episode Uncle Bob will tell you just what components are, and how they came to be. We'll learn how loaders evolved into linkers that evolved into linking loaders. We'll learn how object files evolved from absolute, to relocatable, to linkable, to dynamically linked components. Then we'll do a deep investigation of the Coffee Maker case study. We'll learn the requirements and the API. We'll see how not to design it, and then we'll see a good SOLID component-ized design. We'll see how boundaries are created and crossed with the Dependency Inversion Principle. We'll see how high level modules are identified with the Single Responsibility Principle. And we'll watch yo-yos go up and down as we traverse up and down the layers of abstraction. By the time we're done we'll have laid the foundation for the next episodes on the principles of component design. So, grab a nice hot steaming cup of really strong coffee, sit back, relax, and enjoy the buzz because were about to spend the next hour brewing component principles.
Sticky, Icky, gooey! Cohesion. That's what this one's all about. Component Cohesion. How and why do components cohere? What are the good forces of component cohesion, and what are the bad forces? Which classes belong together in components, and which should be kept apart? Oh, and why do White Dwarf stars go Supernova? In this episode we're going to explore the three principles of component cohesion: The Release Reuse Equivalence principle The Common Closure Principle The Common Reuse Principle We'll learn about the goal of independent deployability, and why that goal causes certain classes to belong together, while other classes don't. We'll also learn about the forces of false cohesion that tempt us to group classes together into ineffective components that aren't independently deployable. We'll see, first hand, the erie connection between the component principles and the SOLID principles. We'll see how components are governed by release procedures, by actors and their responsibilities, and also by how much knowledge they present to their users. And we'll discover that the component structure of a system is a function of it's maturity as well as of it's behavior. We'll see that the component principles have a certain mutual exclusivity that creates a tension in the component structure. So get a rag and some Acetone, because we've got a lot of gooeyness to deal with, as we slurp our way through the topic of component cohesion.
Stop all that giggling and get your minds back out of the gutter. It's Component Coupling people, Component Coupling. In this video our intrepid cast of characters will explore the principles that govern the relationships between components. Those principle are: The Acyclic Dependencies Principle. The Stable Dependencies Principle. The Stable Abstractions Principle. In this lesson we'll learn about the Morning After Syndrome, that hideous disease that affects large teams and causes them to step all over each other. We'll show how a large system can be safely and effectively managed by keeping the dependencies between the components free of cycles. Then we'll take a look at the concept of stability. What makes a component stable, and why should we care? What effect does stability have on the dependencies between components? Then we'll look at abstractness. What makes a component abstract? How does abstractness impact on the couplings between components? Then we tie it all together. What is the relationship between stability and abstractness? How can we use that relationship to free our stable components from rigidity? Finally, we boil it all down into numbers and metrics. We derive a set of simple mathematical expressions that describe the relationships between components, and provide numeric measurements of how well those components conform to some of the SOLID principles. So, don your enchanted armor, get your iron picks and diamond swords ready, and get out of bed, because the sun is about to rise on the world of Component Coupling.
Oh, so you want an example eh? You want something real? You're tired of all the theory and lecture. You got through all those videos about the component principles, and now you want to see how they're actually used. Well, do I have good news for you! Because that's just exactly what this episode is all about. We call it the Component Case Study and it's all about studying cases. We're going to study big cases, small cases, round cases, square cases, suit cases, hat cases -- all kinds of cases. By the time you're done with this video you're going to know cases inside and out. No, that's wrong. It's not about cases. It's about components. It's about component principles. In fact it's a detailed examination of just how those principles are used to solve a real problem. The problem we tackle is the Payroll problem from Episode 14. Remember back in that episode we applied the SOLID principles in order to create an object oriented design that partitioned the problem into classes and relationships? Well now in this episode we're going to take those classes and we're going to apply the component principles to them, creating an architecture of independently deployable components. But it's not just going to be as simple as that. Oh no! First we're going to look at lots of wrong ways to break the problem into components -- ways you might even recognize from past projects. We're also going to spend a considerable amount of time talking about, and using, component families as an organizational concept. So make sure your cases are all packed and ready to go; because we're going to study those cases as we embark upon: The Component Case Study!
OK, so I completely blew it. For a year now I've been promising you this episode on advanced TDD. Tease, tease, tease -- advanced TDD. Blah, blah blah. So then, when I finally started writing the script for the episode, I realized that the script was far too long for one episode, and I wasn't even halfway done with the topics I wanted to cover! So, I backed off and did a topic analysis on what I wanted to talk about, and found I had three or four episodes worth of material. I gathered the first topics together, and set the others aside for later. And then I finished off the script for the first episode. Then, after shooting and editing, we realize that the episode is two hours long! Woah! We need to split it again! So, here it is. Episode 19, part 1. Advanced TDD. In this episode we're going to do a deep dive into the three laws of TDD; with lots of code examples. We'll study the process of TDD in minute detail as we gradually build a simple program to invert names. As we explore the three rules, we'll also start the discussion about The Single Assert Rule; and then we'll set that aside for more exploration in a future episode. So, wash your eyes out and clean your glasses, because this one's all about the code. And get ready for the first half of Episode 19. Part 1. Advanced Test Driven Development.
So you've watched Part 1, right? I mean, you don't want to start with Part 2 because you'll miss all the preliminary discussion on the three laws. So, just checking. Part 2 is where things really start to get interesting. First we look at the topic of incremental algorithmics; the notion that you can derive an algorithm, one step at a time, by posing a failing test, and then making that test pass. As part of this process we'll learn one of the most foundational principles of Test Driven Development. The principle where the magic really comes from. As the tests get more specific, the code gets more generic. And then... and then... Well, then we go and get ourselves stuck; Stuck is a technical term that means: Stuck. In TDD when you are stuck, it means that in order to make the currently failing test pass, you've got to implement the whole program. It means there's no incremental step to take, no simple solution, no easy path. So first we show you how to get stuck -- because there's nothing quite so informative (and fun) as watching Uncle Bob fail. Then, we back up and show you how to get unstuck, and how to avoid getting stuck in the first place. And then we're done. Uh. Well. With Episode 19. But that's just the first of many episodes we're going to do on Advanced TDD. So, keep watch for more.
Woah! Twenty episodes! Wow! That's almost a full 24 hours of video. Who'd have thought that I had 24 hours of stuff to talk about? Who'd have thought that after nearly a full day of talking I'd have so much more to say! Anyway, in celebration of the twentieth episode, we've included a couple of extra features for your enjoyment. We hope you'll like them. We sure had fun making them! This episode is all about Clean Tests. We begin by examining the anatomy of a test: The four A's: Arrange, Act, Assert, and Annihilate. We spend a lot of time talking about the various forms of the Arrange. Next we talk about the problem that setup functions can grow to become unmanageable; and we address that problem by introducing the fascinating topic of hierarchical tests. We show how hierarchical tests are natural in Ruby using Rspec, and how to implement hierarchical tests in C# and Java. Finally, we put the icing on the cake by showing you how to create truly clean and readable tests by using the technique of test composition. So get ready for a dimensionally transcendental experience, as we materialize inside the world of Clean Tests!
- Did you know that tests have a design? - Did you know that the design of tests is critical to the success of the project as a whole? - Did you know that the problem of Fragile Tests is a design problem? - Did you know that the SOLID principles apply to tests as well as to the production code? - Did you know that the code drives the tests just as the tests drive the code? - Did you know that test naming is part of test design? Those are some of the things you are going to learn in this episode of Clean Code. Episode 21: Test Design. And the bottom line is this: Tests are part of the code of your system. They are not a different class of code. They are not a different species of code. They are not somehow inferior or less important. The code in your tests is part of the code of your system! And therefore the code in your tests has to be planned, and designed, and cared for with the same zeal, and effort, and conscience as the production code! The penalty for failing to hold your test code to the same high standard of your production code, is that your tests will rot, and your production code will follow. So, no pressure or anything, but in this episode you're going to learn some of the rules, techniques, and principles of: Test Design.
Have you ever heard of: Fake It Till You Make It? How about: Assert First or Test Triangulation? These are just some of the test writing techniques that we'll cover in this episode -- and cover with lots and lots of code. Then we'll face the ultimate existential question of tests: What's more important, the tests or the production code? Indeed, we'll pose it a problem of two disk drives; one containing the tests and the other containing the production code. One of them has crashed. Which do you hope it is? How much of your refactoring effort should be spent refactoring the tests? Any? And if you do refactor the tests, what is the goal of that refactoring? What does a good clean test look like? Kent Beck often says: "First make it work. Then make it right. Then make is fast and small." Ron Jefferies' rules of Simple Design tell us that the code should: Pass all the tests. Have no duplication Express everything the author wants expressed. Have a minimum of classes and methods What do these rules have to do with tests? Should they be followed when writing tests? Or is there a different set of rules for tests? The answer may surprise you. Finally, we'll talk about the term: Test First, and find out what it really means. So get ready to read lots of code, to think lots of thoughts, and to face the ultimate truth of test driven development.
EGAD! Another two-part episode! I just can't seem to get this advanced TDD topic under control! So, this is part 1. Remember to get part 2! OBAFGKMLT Welcome to Clean Code Episode 23 - Mocking; part of our sub-series on advanced Test Driven Development. In this episode we're going to learn about Test Doubles and Mocking. We begin with a little puppet show. You'll recognize the characters. You'll also recognize the situation; because, in all likelihood, you've been there - done that. That situation will lead us to a software architecture replete with dependency-inverted boundaries. As the players in our drama discuss how to test the features in that architecture, we'll gradually make the case for using mocks. Then we'll show you those mocks in a sequence of screencasts that begin with basic stubs and moving on to more involved spies. There's a lot of code to look at; and of course you can download it all from the extras link. Then we get all academic and study the classification of Test Doubles. We talk, in depth, about dummies, stubs, spies, mocks, and fakes. And there is plenty of code describing each. All that takes an hour. And at the end of that hour, part 1 comes to an end. But don't forget to watch part 2, because things get pretty interesting over there. In part 2 we're going to learn about the never ending struggle between Behavior and State; and the remarkable stress this dichotomy puts on our mocking strategies. This will lead us to: The Uncertainty Principle of TDD and the never ending battle between the Mockists and the Statists. Then we'll get all pragmatic and start examining some of the most useful mocking patterns such as: Self-Shunt, and Test-Specific Subclass, and my favorite: Humble Object. We'll show you, with lots of code, how and when these patterns should be applied. Indeed, we'll use the Humble Object pattern to show you how to test GUIs. We get a little Swing UI up and running and then show you how to separate the
Yikes! Another two-parter. These topics just keep getting bigger and bigger. OK, so what the devil is the Transformation Priority Premise? Well, it's an idea that's kind of at the front lines of Test Driven Development. The Bleeding Edge, so to speak. The notion is pretty simple. You know what refactorings are, right? I mean they're small modifications to source code that change the structure of that code without changing the behavior. Well, a transformation is just the opposite. It's a small change to software that changes the behavior, without changing the structure. Would it surprise you to learn that the number of transformations is relatively small -- perhaps only a dozen? Would it also surprise you to learn that these transformations fit neatly into the red-green-refactor loop of TDD? Finally, would you be surprised if I told you that some transformations are "better" than others? In this episode we'll identify an even dozen of those transformations. First we'll walk through a familiar Kata (the Prime Factors) and show how a few transformations are used. Then we'll walk through each transformation in turn, and describe them in detail. And that'll take the hour; and will bring part 1 to a close. In Part 2 things get really exciting. Because in Part 2 we explore the notion that these transformations have an ordering, a priority, that helps developers create better algorithms better code, and better design. But that's part 2. No fair peeking.
OK, so this is Part 2; and this is where things get really exciting. I'm sure you've seen me do the Bowling Game, the Prime Factors, and the Word Wrap katas. You know how those algorithms just seem to kind of appear, as though the code was writing itself? We'll we're going to see that again. But this time we're going to see it in the context of applying transformations using a certain priority. In fact, we'll do it twice, with two different priorities. And then we'll examine the different. The difference will be (how do I say this without giving too much away?) -- interesting. Very interesting. Finally, we'll state the premise. We'll also make the point that it is no more than that. It's not a law, not a principle, not a theory, not even a conclusion. It's just a premise. But if it's even partially correct, it's a premise that could have a significant impact on our profession. Or not. Anyway, enjoy the episodes.
And so we begin our exploration into design patterns. We begin by talking about the overall concept of design patterns. What are they, and what are they good for? Next we do a quick overview of the GOF book; and we'll find out why it is one of the most important books to be written within the last three decades. Then we put our heads down and focus tightly on the Command pattern. We learn that the command pattern is a way to decouple what is done, from who does it. Next we find that it also helps us decouple what is done from when it is done. Next we look at Undo and Redo, and how the Command pattern makes these features almost trivial to implement. Finally we look at the actor model; a way to support hundreds or even thousands of threads in a memory constrained environment. So hold on to your GOF because Design Patterns are about to begin.
So. Now it's time to talk about Factories. Factories. Lots and lots of Factory patterns. And no XML. In this episode we'll introduce three patterns in the family of factories. Factories! Lots .... And no XML. First, we'll talk about Abstract Factory. We'll show you why and when you'll want to use it, and what interesting little traps to watch out for. And that will start us on a lovely discussion about independent deployability, component design, jar files, type safety, type wars, smalltalk, Java, Eclipse, and No XML! Then we'll talk even more about the Factory Method and Prototype Patterns, and we'll discuss the problem of initialization. And we'll talk more about type safety, and language wars, and C vs. Pascal, and C++ vs. C, and Java vs. C++, and Smalltalk and Ruby, and NO NO NO XML!! Because we don't want to talk about XML. You heard me, right. NO XML! I don't want to hear about XML. I mean, for goodness sake, what were those guys thinking? XML was not a language that was designed for people to write! It was just a convenient syntax for a binary representation. You know, like X400, and X209, and ... What the bleeping bleep were those XSLT guys thinking. Or those ANT guys. And don't even get me started about Maven. Sheesh, angle brackets everywhere and I mean who the... It just makes me nuts that anybody would try to use XML for anything other than just looking at a data stream. I mean writing XML? WRITING XML???? That's just nuts, nuts, nuts. It's nuts I tell you. It's crazy kookie, wiered out nuts in the worm hole, and I don't know what to tell you these angle brackets are everywhere like little paperclips, like little spider legs, crawling, crawling up my spine and down my legs, and I just can't tolerate them all over me anymore and .....
At long last, the episode you've been waiting for. The episode on Strategy and Protocol. No. Protocol and Template Method. No. Uh. Strategy and Template Method. Yeah, that's it. S&TM! In this episode we are going to tear into the unimaginably powerful, wildly complicated, and ultimately impenetrable Strategy pattern! Applause!!! In this episode the secrets will be revealed. The mysteries will be solved. The arcanities will be explained. The unknowable will be made known. You, yes you!, will at last understand how to employ the Strategy pattern, and it's brother the Template Method pattern. We'll talk about the costs, the benefits, the uses, and the abuses of these patterns. It'll be cool. It'll be really cool. It'll be revolutionarily coooool! So come on, what are you waiting for? It's time to dive, head first into the maw of the beast and uncover the ultimate truths of: **Strategy and Template Method**
Come all without. Come all within. You've not seen nothing like the mighty FSM. This episode is all about Finite State Machines. What they are. Why and when to use them. How to represent them. And how to implement them. Including implementing them with The State Pattern. Yes, this is part of our series on Design Patterns. It's also the first in at least three parts that will lead us from the State pattern to the Visitor pattern. It's going to be an interesting journey. We begin it here by talking about state machines and how remarkably useful they are, and how frustrating they can be to implement. By the end of this episode we'll have decided that the solution to that frustration is to write a compiler that generates the code from a simple syntax. The next few episodes will explore how to write that compiler; and how to use Finite State Machines to write that compiler. These next few episodes are going to be fun, challenging, and important. You aren't going to want to miss them.
OK boys and girls, things are really starting to heat up. In this episode we start writing a compiler! Remember,that's what we said we were going to do. We said we'd write a compiler that generates finite state machines. Well, that's what were doing. And, boy, is it a hoot. We begin by exploring the syntax of our state machine language. That syntax begins as a simple state transition table, and then we add a few cute bells and whistles, like super states, entry, and exit actions, that make writing state machines a bit more convenient. Next we formalize our syntax by expressing it in Backus-Naur Form (BNF). Then we write a lexical analyzer to identify the terminal tokens of our syntax. Then we write a parser that identifies the grammar of those terminal tokens. And, ironically, that parser is a finite state machine! Then we use the Builder Pattern to write a builder that constructs the internal representation of our syntax. And if you don't think that's enough for one episode, you're crazy. So, put your propeller caps on and take a big swig of brain juice, because we're about to plow headlong into the heady topic of Writing the State Machine Compiler!
Where is Uncle Bob? He invited us over for dinner and we've been waiting and waiting. Where could he be? It's unlike him to be this late? Wait! What's that sound? Great Heavens! Who is that wretched creature at the door, guzzling our wine like a man bereft of his senses. Prepare yourself for an interesting journey. A journey through the land of Code Generation and The Visitor Pattern. In this episode we conclude the mini-series on the State Machine Compiler. In the last episode we had just finished the parser. In this episode we'll see the Semantic Analyzer, the Optimizer, the Generator, the Abstract Syntax Tree, and the code generating Visitors. And that means we've got a lot of code to look at. While we are looking it over, we'll take a short diversion into the rationale, and variations of the Visitor Pattern. And we'll also do a quick review of the Composite Pattern. We'll also see how the discipline of Test Driven Development differs in certain larger projects, from the small Katas and examples that we've seen in the past. So clear your head, and free your mind. Red pill or blue? It's up to you.
OK, get ready for some fun. In this episode we're going to dive deep into the Observer pattern. The first thing we'll do is derive the pattern from first principles. We'll begin with a simple real-time clock application and, step by step, apply one design principle after another until the Observer pattern emerges. Well, actually, what emerges is a structure that our current most popular languages can't implement, because it requires multiple inheritance. So we'll explore the workarounds to that, and then we'll rant about why Java and C# don't have this useful feature. The Observer pattern comes in two forms. The "Push" model, and the "Pull" model. We'll describe them both and discuss when and where each is appropriate. Then we'll turn to the larger pattern that the Observer fits into: Model View Controller. We'll look at the history of MVC, and the unfortunate corruption of the pattern by current web frameworks. Finally, we'll invoke the Humble Object pattern for testing GUIs, and we'll derive the Model View Presenter pattern from MVC.
OK, so now we're really starting the make progress through the design patterns. In this episode we'll study five of the most useful. First we'll discuss Singleton and Monostate; two patterns that help you enforce that only a single instance of a class is created. The real challenge with these patterns is how you initialize the static variables that are involved. So we'll walk through the whole nine yards of initialization issues, including threading issues, locking, double-checked locking, etc. You're going to love Monostate. It's a really cool pattern with lots of very interesting uses. Then we'll talk about nothing. Or rather, objects that do nothing -- or rather objects that get away with doing nothing by doing nothing in just the right way. The pattern is called: Null Object. Then, it's on to the Proxy pattern. This is the pattern used by most interprocess communication tools, and database isolation tools. Proxy is a pattern that is used when two objects need to communicate across a boundary, and should not know about that boundary. Lastly, we'll discuss the Decorator pattern. Decorator is a member of the Visitor family of patterns. It is another way to add new behaviors to existing class hierarchies without modifying those hierarchies. And after that we'll take a long deep breath to get read for the next episode -- and even more patterns.
This is the Patterns Roundup -- the Penultimate episode in our Design Pattern's series. In this episode you'll learn about five more patterns. Facade, Mediator, Memento, Flyweight, and Extension Object. The Facade and Mediator patterns are used when you have a group of objects that you want to impose a policy upon. Facade imposes that policy overtly from above. Mediator imposes it covertly from below. Memento is used when you want to capture the state of of an object inside an opaque token that can be passed around the system; and that can later be used to reconstitute the state of the captured object. Flyweight is used when you have a group of objects that share a large amount of common state. That state is moved into a separate object and shared amongst all the objects. Extension Object is yet another member of the Visitor family of patterns that allow us to add new behavior to existing hierarchies without changing those hierarchies.
This is the Pattern Apocalypse! The final episode about design patterns. And it's a doosy! In this episode we're going to talk about five patterns: Bridge Chain of Responsibility Interpreter Iterator Adapter You're going to love the discussion about the Bridge pattern. In it, I show you how to break down an subtype hierarchy with multiple degrees of freedom into a chain of several subtype hierarchies capturing one degree of freedom each. In the Chain of Responsibility discussion we extend those hierarchies so that clients have no idea what server is serving them. Then we explore Greenspun's 10th law by looking at the Interpreter pattern. And we learn that with great power comes great responsibility; and that most efforts to reduce programming workload by shifting it to the business simply cause that workload to bounce back to the programmers. You're going to find the Iterator discussion particularly interesting. It's not what you think it is. This discussion will teach you how to turn loops inside out so that the loops are at the bottom, being driven by the algorithm, instead of at the top and driving the algorithm. And then, at long last, the humble Adapter pattern. I'll go through a little history about comp.object discussions, and table lamps, and interface naming. And then we'll explore the two primary forms of the Adapter. So, if you're ready, it's time to dive in to the final set of Design Patterns. Fire up the Pattern Apocalypse!
Programming is one thing. Writing programs that meet the needs of the business is another. How do the business people and the programmers communicate? Answer: badly. In this episode we're going to introduce the concept of Acceptance Testing and Behavior Driven Development (BDD) as a means to enhance that communication. First we'll look at the problem itself; the problem of communication between business people and technical people. Then we'll discuss some of the more successful solutions to this problem, including the tables developed by David Parnas; and the Fit Framework developed by Ward Cunningham. In fact, we'll have a surprise visit from Ward, and hear some of that history from the horse's mouth. Then we'll look at FitNesse, and some of the ways we've used acceptance testing and BDD to specify it. Then we'll get into the guts of BDD and walk through some examples. Finally, we'll talk about the Acceptance Test Rule. This is the rule that tells us the best form to present Acceptance tests in; and whether BDD is appropriate for your team. And that will end part 1 of our series on Acceptance Testing. Have fun. This one's a hoot. You'll meet a new character in here -- one you'll recognize!
Have you ever wanted to be a business analyst? Well here's your opportunity to watch a new business analyst learn the ropes. She's new. She's inexperienced. But she'll have some experienced help getting started. In the end, she'll do fine. In this episode we're going to watch a project get started. From the initial pitch and the mandate from executives, to the conversation between business analysts, programmers, and QA. And we'll learn the dynamics of that conversation. We'll learn that the qualifications for being a good business analysts, and being a good QA technician, are similar in many ways; and that they require equal measures of technology and business background. So, watch carefully as the first acceptance tests are written. Notice how the business analyst makes assumptions about those tests that are corrected by the QA technician and the programmers. Watch as the design of the initial tests take form. And notice how the business analyst learns that the design of those tests is critically important to the success of the project.
Get ready for a deep dive into the acceptance tests and implementation of the Hunt the Wumpus game. In this episode we're going to look at the details of all the FitNesse tests, and the Java code that makes the game work. We'll also introduce a new contest that you can compete in. The prize is An Autographed Clean Code Coffee Mug. WHOOOO HOOO! This episode is full of interesting architectural insights and design decisions including things like separating UI from tests, and partitioning high level policy from low level policy. You'll also see several design patterns and test patterns from previous episodes employed in the implementation. Finally, once we've looked over all the tests and code, we'll discuss the collaboration that is required between business, QA, and development in order to create a suite of acceptance tests that is compatible with the architecture of the application.
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.
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.
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.
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.
Welcome to our series on Functional Programming! Are you ready for some fun? So, yeah, I'm sure you've heard all the fuss about functional programming recently. People are talking and arguing about combinators and monads and monoids and all kinds of other words that sound like they came out of some mathematical laboratory. Don't worry, that's not the direction we're going. Oh, we might peek into the math lab from time to time, but this series is about doing, not about pontificating. (Well, usually, anyway.) In this episode we're going to introduce the basics of FP. We'll talk about what it is, where it came from, how it relates to regular programming, and we'll even show you some code. The code will be in Clojure. That's the language we'll be using for the most part, though we'll likely look at some F# from time to time. So, get ready for a some loops and whirls, because this episode is likely to turn your brain a little sideways.
Do you remember Master Mind, that clever board game from the '80s, with the colored pegs? We implemented a version of it back in Episode 9. Well, in this episode we're implementing it again, but in Clojure. In this episode we're going to walk through the code for this program, one commit at a time. You'll see how I used TDD to develop it. You'll see the functional design. You'll be amazed that there are no assignment statements. You'll be astounded at the data-flow style. And, in the end, you'll know the best strategy for winning Master Mind and will be able to amaze your friends. So hop on board and let's get this train moving, because we're about to immerse ourselves in functional programming, Clojure, and Master Mind. The code in this video can be found here. Make sure you walk through all the commits in sequence. There is much to learn by watching the progress of development.
Spacewar! How cool is this? Did you ever think that you would be combing through the innards of a real-time, interactive video game written in Clojure? Well, you are now! This game is thousands of lines of Clojure code. It has Klingons, Romulans, Starbases, and The Enterprise. You must save the Federation. This episode and the two that follow will lead you through the design and implementation of a functional and interactive GUI program. It is 100% functional: no cheating, no mutated variables, and not even any Transactional Memory; just plain old functional programming. You should probably follow along and grab the code. If you want to play the game, you can find the ClojureScript version in your web browser here.
OK, so now things are going to get really tech-y and geeky. We're going to talk about how all the GUI widgets work, how they are arranged in a hierarchy, and how they communicate events and respond to commands—all without mutating any state. The data structures we'll use for this are going to quickly get very complicated. In order to avoid losing control of them, in a dynamically-typed language like Clojure, we're going to investigate the use of Clojure's type specification library clojure.spec. Oh boy, this functional programming stuff is fun! And so is playing Spacewar! Have you played it yet?
So, now it's time to get into the real guts of the Spacewar game. The game logic. There are quite a few fun and interesting topics we're going to cover. These are a few of the questions I want to address: 1- There are 8,000 lines of code and 777 unit tests. What kind of coverage does that represent? What was the testing strategy for GUI vs. Game Logic? 2- How does Clojure/spec help us keep our data types under control in a dynamically typed language? Are dynamically typed functional languages inherently weaker than statically typed functional languages? Or are there advantages to dynamic typing? 3- How do you manage to update complex state when you aren't allowed to change the state of any variables? Does this represent extra work? 4- Lazy evaluation is a powerful technique, but what kind of trouble can it get you into? 5- Where does this program go from here? Prepare yourself for a really interesting deep technical dive as we walk through Spacewar -- Game Logic.
Fifty-Eight. 58 is 2*29 and is the sum of the first seven prime numbers: 2+3+5+7+11+13+17. 58 is the year that Sputnik was launched. "58 is like the luckiest number ever." according to Patrick on the Sponge Bob show. And...Episode 58 is where we talk about the SOLID principles in Functional Programs. YAY! In the last episode, Episode 57 (which is 3*19 and the atomic number of Lanthanum (not to be confused with gold-pressed Latinum)) I told you we were done with Starwars. I lied. Well, no, I didn't exactly lie. I was wrong, but I didn't know it at the time. You see, at the time I knew I wanted to do an episode on the SOLID principles in functional programming. I just didn't know I was going to be using Starwars as the example. But then, as I started writing the episode, it became clear to me that there were loads and loads of SOLID principle conformance and violation in Starwars. Anyway, Starwars it is. One more time. And this time we're going to look at it from the point of view of: SRP - The Single Responsibility Principle, OCP - The Open-Closed Principle, LSP - The Liskov Substitution Principle, ISP - The Interface Segregation Principle, and DIP - The Dependency Inversion Principle.
OK, ok. So this is the episode you've been waiting for. Enough of the silly game programs like Master Mind. Enough of the silly GUI Star Trek games. Now it's time for real enterprise software. A WEBSITE! Yeah, that's the ticket! Right. So, in this episode, Uncle Bob writes a fully functional website in Clojure, using pure functional programming. Oh, yes he does! But first, he rants about the web in general—because what would one of these episodes be without a good rant? Then, he goes into the history of the web, and hypertext, and all the stuff that we think of as modern enterprise software. Uh huh. Then it's on to the Clojure frameworks used in the example: Ring, httpKit, and compojure. Then we look at the code for the website; more importantly, we look at the architecture of the website. And then, finally, once we've peered at the glory of a functional website, the truth will come to us at last, when all are one and one is all: that all websites are functional. (Cue final guitar lead)
Monoids and Monads and Bears, Oh My! And Functors too. Get ready for a gentle stroll down Category Theory lane. Don't freak out. We're not going to get into any heavy mathematics or anything. We're just going to skim the surface of category theory. We'll dip our toe into the waters, just enough to explain one of the most powerful concepts in programming: The concept of Composition. We'll begin by describing what composition is, and the history of composition in software -- starting with Turing and ending up with objects, and lambdas, and streams. Then we'll dig just below the crust of category theory in order to expose the simplest of the concepts: Categories and Monoids. We'll show how these two concepts relate to Map and Reduce. Then we'll dig a tiny bit further into the concepts of Functors, Categories of Categories, and -- of course -- Monads! And that will be enough. Oh yes, that will be enough. These concepts may seem a bit academic; but I think you'll find them valuable as a way to think about how the elements of software systems are composed.
In ages long past (2006), two great giants of software battled over the power of Test Driven Development (TDD) vs. the power of The Hammock (HDD). Ron Jeffries, a programmer who wrote his first code under the mountain at Strategic Air Command in 1958, and was one of the founders of the Agile movement strived to show that programs and algorithms can be derived through consistent practice of TDD. Peter Norvig, one time head of the Computational Sciences Division at Nasa Ames Research Center, and currently the director of research at Google fought to show that it was the deep up-front thinking from time spent within the Hammock that creates the better design. The battle ground they chose was Sudoku; the number puzzle that became a short-lived fad in the early 2000s. Ron attempted to incrementally build a Sudoku solver one test case at a time following the practice of TDD. Peter climbed into the Hammock and built his solution using deep thinking and analysis. Which of the two prevailed? What did they prove? Is TDD the answer? Or should programmers spend more time in the Hammock? In this episode, we will replay that battle and we will create a Sudoku solver using functional programming in Clojure. We will use TDD. We will spend time in the Hammock. And we will answer the age-old questions that those two giants fought over. In the end, as we conclude our series on functional programming, we will at last know whether it is TDD or the Hammock that best drives the designs of algorithms.
This episode is the capstone of our Functional Programming series. In it we explore Clojure, the language that we've been using throughout the series. We'll start with a history of LISP. Where did it come from? Who invented it, and why? Then we'll talk about one of my favorite books. The Structure and Interpretation of Computer Programs. This is the book that first taught me LISP and Functional Programming. It's a classic, and it's one you should read. Then it's on to Clojure. This is not a tutorial. I'm not going to teach you all the ins and outs of the language. My goal is to give you just enough familiarity to make you curious. Clojure is Lisp. Clojure is Functional. Clojure rides on the JVM. Clojure supports concurrency. Next we'll spend a moment explaining how the data structures in Clojure can be simultaneously efficient and immutable. That's quite a trick, and you'll enjoy hearing about how it's done. Then we'll talk about lazy evaluation, and some of the costs and benefits of the technique. It's powerful, there's no doubt. But if you don't know what's going on behind the scenes, you can get into trouble that's hard to debug. Finally we'll discuss Macros and Homoiconicity (if that's a word.) Oh the power! THE POWER! This may be the most powerful aspect of LISP; and in Clojure it is especially powerful. It's so powerful, in fact, that you should hardly ever use it. And with that, we'll be done with the Functional Programming series.
Welcome to our series on Architecture. In this series we are going to cover many topics. We’ll start at the beginning with a review of the paradigms and principles of low level software design. We’ll commence from there to a review of components and the principles that define them. And from that vantage point we will graduate to Architecture itself and explore the art of drawing lines and techniques for enforcing boundaries. But that’s not what we are doing in this first episode. In this episode we’re going to answer the question that motivates this next set of episodes. “What is Architecture?”
At the very lowest level of software architecture is code, and the rules of clean code. At the next level are the paradigms of programming, and that's what we'll be focussing on in this episode. The three paradigms, Structured Programming, Object Oriented Programming, and Functional Programming were all discovered in the decade between 1957 and 1968. In this episode we'll discuss the history of those paradigms, and then we'll dig down into the architectural significance of each in turn. Finally, we'll synthesize them into an architectural whole with the following conclusion: Well architected software systems are composed of recursive applications of sequence, selection, and iteration, hung on a framework of inverted dependencies and plumbed through and through with flows of immutable data.
You all know the SOLID principles by now. (If you don't, check out our series on the topic) How do those principles relate to architecture? That's the question that this episode tackles. We walk through a quick review of the SOLID and Component principles, and then discuss how each applies at the higher level of architecture. At the end we bring it together into a grand synthesis.
So now our jaunt through the topic of software architecture is starting to heat up. This is the episode where we get nitty-gritty, down and dirty. We talk about drawing lines. We’ll begin by discussing what architecture is -- really. Then we’ll tackle the concept of independence, and what it means to be independently deployable, and independently developable. Next we’ll discuss the anatomy and physiology of architectural boundaries, and we’ll hear some sad stories of boundaries that were mis-drawn. We’ll conclude, at the climax, with a discussion of policy and level, which will lay the stage for Episode 67 -- Clean Architecture. So, ready or not, here we come with Episode 66: The Art of Drawing Lines.
In this, the final episode on Architecture, we begin by discussing the structure of business rules and business data. Then we talk about how architectures should scream those business rules to programmers. Next we walk though a prototype four layer architecture that I like to call The Clean Architecture. Lastly we spend some time talking about all the low level things that don't neatly fit into any architecture. Things like main, configuration, tests, and low level drivers and utilities. And finally, we talk about how to get off the planet. Have fun, everybody!
This is the episode you’ve been waiting for. This is the episode where we finally address the problem that everyone has, and that everyone want’s to know how to solve. This is the episode where we address: Legacy Code. But don’t get too excited. Don’t anticipate any pixie dust or magic beans. Legacy Code is a hard problem, and there are no easy solutions. There are, however, strategies. Perhaps more important than strategies, there are also attitudes. Those are the kinds of things we’re going to be talking about in this episode.
Working on the web server leads to periods of befuddlement followed by periods of productivity. This episode might be a little painful to watch as Micah and I stumble around trying to make this multi-threaded web-server code work. You'll watch us miss obvious things that you see right away. You might even be moved to leap up from your seat and shout at the screen. Still, in the end, we solve the threading problems and make a lot of progress on our little web server. After three tomatoes, we can see our way clear to the end. Working on multi-threaded code is always a challenge. TDD helps a lot with correctness; but imposes it's own complications too. If you've always wondered how to do TDD in a multithreaded environment, you can watch us do it here.
We solved all the race conditions in the last episode; so in this episode things go much more smoothly. There are a few tests left in order to finish the web server. We write them. And then we find that they weren't quite testing what we thought they were testing. We quickly finish getting our little web server running, and then start using it to send simple "Hello, World" messages to the browser. This forces us to investigate the high level structure of an HTTP Response; and make sure that our little web server delivers that structure. Once we can reliably communicate with the our browser, we begin working on delivering the Front Page to the browser. Along the way we discover that tests sometimes don't test what you think they do; and that sometimes the best tests are visual.
Uh Oh. We just got a call from the customer. They want a demo -- in an hour! Are we ready? Do we have enough to show? Can we cobble something meaningful together in the nick of time? How do you deal with pressure? How should you behave when time is short, and there are obstacles ahead? In this video, we solve a number of technical issues and prepare for a live demo with the customer. You'll watch us confront unexpected roadblocks, and confusions. You'll see how we respond. You'll recognize the emotions and the temptations. You'll watch us stumble through the minefield. All the while solving the problem of getting real data on the screen in our minimal web server environment.
Tunnel Vision. We all get it. We get so focussed on what we are doing that we lose the bigger picture. We get so frustrated with the time it takes to arrange all the fiddly little details that we begin to take shortcuts. This happens a bit in this episode. It's not a disaster. We recover quickly. But still, you can see it happen. Another interesting occurrence in this episode is the identification of a bug from the subtlest of symptoms. It's actually quite remarkable that we saw it. And then there's the function we thought was a constructor; but wasn't. And then there was the unexplained malfunction that we fixed with a magic word. Yes, this one is fun. It's a bit embarrassing; but it's fun.
What does C57-D mean to you? What does it have in common with The Naked Gun? In this episode we struggle for almost two tomatoes with how to manage two very similar data structures. Should they inherit? Should one use the other? Should there be a utility class? Then we start to reorganize the code and move it into packages. And we debate whether the package principles should be applied or not. We also struggle with the fact that we have not properly partitioned the use cases and presentations. And then there's that weird bug... Batman vs. Darth Vader?
So this one is interesting. In the process of fleshing out the CodeCast details page, we realize that we need to parse incoming URLs and build a router that selects the appropriate controllers. True to form, we simply write this ourselves rather than depending upon a framework. Along the way we re-encounter the strange race condition that sometimes causes our tests to hang. We work around this problem, but grow ever more concerned about it. By the end of the episode we have the architectural framework for many of the elements of a web serving system. And we still aren't using a framework.
The the help of Corey Boyle's son (and Corey to some extent) we managed to track down and kill that nasty threading bug. Actually it was a bug in our tests, not in the production code. Indeed, production code would never have exhibited the problem because production code would have been synchronized by sending messages between the sockets. The problem we were having was that the tests bypassed the normal conversations. The Clean Architecture begins to appear. After fixing the bug, we started to break up the silly main program that was putting up the front page. We moved part of it to a CodecastSummariesController, and more to a CodecastSummariesPresenter, and a CodecastSummariesView. We were driven to do this by the need to write a unit test for for the Controller. You'll see this in the video. Every time we tried to add something to the test, we decided to refactor the code a bit more to make it more testable. You might infer that this was caused by a lapse in our TDD discipline. That's not quite true. It was really caused by taking test code and turning it into production code; and then partitioning that code into the desired architecture. Anyway, If you've been wondering where the Clean Architecture was in the last 10 episodes; you'll begin to see it appear here. The transition isn't complete. We've got more to do in the next episode. But it's coming
Everything started fine. We had a nice design discussion on the whiteboard about pulling the taffy threads of our application apart. We even got IntelliJ to show us the UML of the design as it existed, so we could compare it to the ideal. But then, in the transition from UML to code, something happened. I couldn't adjust the speed of my brain properly. My brain was going too fast for the code. And so I started making silly dumb mistakes. We made some progress in tomato 1, but not as much as we should have because we kept having to backtrack due to my brain overruns. So we slowed way down in tomato 2 to try to resync my brain with the proper rate of code. And this worked pretty well. By tomato 3 everything was back to normal. We made some very interesting decisions in this episode. We established a target architecture. We determined the difference between our current design and that target. And we started along a pathway to get from one to the other. -- And we got our brains going at the right speed. And, perhaps most importantly, we engaged The Discipline of D. E (Do Easy).
As we pursue the architectural refactoring of the application, I make a silly mistake in the diagram on the board. And for two and a half tomatoes we don't spot it. Yikes! This doesn't invalidate the work we do. And much of it is good. But it does create a kind of "friction" that we both feel and can't quite explain. This is a reality show. This kind of thing happens in real life. It's frustrating. It's embarrassing. But it's real. And it's educational. And, of course, there's lot of other things to learn in spite of the flub. We talk about mocking tools. We talk about dynamic vs static languages. We talk about refactoring strategies. We talk about big design vs TDD. And, in the end, we have a lot of fun. Because, after all, programming is the second most fun thing in the world!
In this, the penultimate episode of the Java Case Study, we manage to complete one slice through the architecture! Yay! With the right diagram on the board, and the right names in our minds, the pieces start to slip together just like they are supposed to. Oh, there are a few little problems here and there, like forgetting that CodeCastSummaries is a list -- twice. But overall, things flow pretty well. I love it when a plan comes together.
Yes, this is the end of the Java Case Study series. I know, I know. Heartbreaking! But all good things must come to and end. In this final episode we: Clean up the remaining cruft left over from the architectural change. Get all the unit and acceptance tests passing for the first use case. Make sure the first use case appears on the screen properly. All that takes two tomatoes. Then, in the final tomato, we review the whole series. From it's humble beginnings to it's even humbler end. We discuss the 18 months (and 18 hours) that we put into this project, and then project how this project might have continued.
