Clean Code: The Clean Coder
44. Estimates
By Robert C. Martin, 59m

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."

43. Productivity
By Robert C. Martin, 1h 7m

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.

42.2. Life, The Universe, and Everything
By Robert C. Martin, 47m

42!

Don't Panic.

This is part 2 of 2.

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

  1. Segment 1. The Answer.

    Short, sweet, but right.

  2. 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.

  3. 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?

  4. Segment 4. Covering Action Fixture.

    A deep dive in which we cover some untested parts of Ward Cunningham's FIT framework with tests.

Part 2

  1. 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.

  2. Segment 6. Cleaning.

    Now that it's covered, and we know the coverage means something, let's clean it up.

  3. Segment 7. Semantic Stability.

    For software, this is the answer: Tests that truly stabilize the semantic behavior of the system.

  4. Segment 8. Conclusion.

    Tying things up in a pretty bow.

42.1. Life, The Universe, and Everything
By Robert C. Martin, 58m

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

  1. Segment 1. The Answer.

    Short, sweet, but right.

  2. 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.

  3. 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?

  4. Segment 4. Covering Action Fixture.

    A deep dive in which we cover some untested parts of Ward Cunningham's FIT framework with tests.

Part 2

  1. 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.

  2. Segment 6. Cleaning.

    Now that it's covered, and we know the coverage means something, let's clean it up.

  3. Segment 7. Semantic Stability.

    For software, this is the answer: Tests that truly stabilize the semantic behavior of the system.

  4. Segment 8. Conclusion.

    Tying things up in a pretty bow.

41. Small Releases
By Robert C. Martin, 57m

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.

40. Proof
By Robert C. Martin, 1h 42m

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.

39. Defects
By Robert C. Martin, 48m

The second promise of The Programmer's Oath is:

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.

38. The Clean Coder
By Robert C. Martin, 46m

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!

Clean Code: Behavior Driven Development
37. Elaborating the Requirements
By Robert C. Martin, 1h 33m

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.

36. Behavior Driven Development Design
By Robert C. Martin, 48m

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.

35. Behavior Driven Development
By Robert C. Martin, 1h 9m

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!

Clean Code: Design Patterns
34. Pattern Apocalypse
By Robert C. Martin, 1h 22m

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:

  1. Bridge
  2. Chain of Responsibility
  3. Interpreter
  4. Iterator
  5. 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!

33. Pattern Roundup
By Robert C. Martin, 1h 5m

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.

If the first 90 seconds of the video seems low resolution, don't worry, It gets better. We're working on fixing that how.

32. Pile O'Patterns
By Robert C. Martin, 1h 8m

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.

31. The Observer Pattern
By Robert C. Martin, 1h 5m

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.

30. SMC Generator
By Robert C. Martin, 1h 34m

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.

29. SMC Parser
By Robert C. Martin, 1h 16m

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!

The source code for the State Machine Compiler is included in the "extras"; and can also be found at: https://github.com/unclebob/CC_SMC

28. Finite State Machines and The State Pattern
By Robert C. Martin, 1h 13m

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.

27. Strategy & Template Method Patterns
By Robert C. Martin, 50m

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**

26. Factories
By Robert C. Martin, 1h 5m

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 .....

25. Design Patterns
By Uncle Bob, 56m

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.

Clean Code: Advanced TDD
24.2. Transformation Priority Premise
By Uncle Bob., 50m

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.

24.1. Transformation Priority Premise
By Uncle Bob., 51m

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.

23.2. Mocking
By Uncle Bob, 45m

OK, so now you know what OBAFGKMLT means...

This is part 2 of Episode 23 - Mocking. In the previous episode you learned all about the motivation for, and structure of, test doubles.

Now, 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 code so that the testable bits are all isolated from the GUI bits.

And then, to top it all off, we'll talk about Mocking Frameworks. We'll discuss what they are good for, when you might want to use one, and why I don't use them very much.

And that, at long last, will bring us to the close of Episode 23.

23.1. Mocking
By Uncle Bob, 1h 2m

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 code so that the testable bits are all isolated from the GUI bits.

And then, to top it all off, we'll talk about Mocking Frameworks. We'll discuss what they are good for, when you might want to use one, and why I don't use them very much.

And that, at long last, will bring us to the close of Episode 23.

22. Test Process
By Uncle Bob, 1h 23m

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:

  1. Pass all the tests.
  2. Have no duplication
  3. Express everything the author wants expressed.
  4. 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.

21. Test Design
By Uncle Bob, 56m
  • 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.

20. Clean Tests
By Uncle Bob, 1h 24m

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!

19.2. Advanced TDD
By Uncle Bob, 55m

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.

19.1. Advanced TDD
By Uncle Bob, 1h 1m

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.

Clean Code: Component Design
18. Component Case Study
By Uncle Bob, 58m

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!


The diagrams for this episode can be downloaded here.

17. Component Coupling
By Uncle Bob, 1h

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.

16. Component Cohesion
By Uncle Bob, 55m

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.

15. SOLID Components
By Uncle Bob, 58m

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.

Clean Code: SOLID Principles
14. Solid Case Study
By Uncle Bob, 43m

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.

13. The Dependency Inversion Principle
By Uncle Bob, 58m

And now, at last, it's time for the Dependency Inversion Principle -- the final principle in the SOLID suite.

Go back in time with Uncle Bob to 1979, when he was just a noobie software developer with only 6 years experience. Walk with him through the tale of telephone test equipment using 8085 microprocessors with 32K of RAM and 32K of ROM. See how he first discovered the magic and power of inverting source code dependencies in order to turn those ROM chips into independently deployable components.

Then hop into the time machine to the early '90s when Uncle Bob was becoming an accomplished C++ programmer. See how he, and his team, struggle, and at first fail, to create a huge reusable framework. Watch as he discovers the key to reuse, and to building frameworks that many applications can reuse.

In this episode we'll learn what dependencies are. We'll study the difference between source code dependencies, and runtime dependencies. We'll learn why that difference is important, and we'll learn how to invert certain key source code dependencies so that they oppose their corresponding runtime dependencies.

Then we'll spend some time looking at two case studies. First we'll look at IO drivers, and how they use dependency inversion to create device independence. Then we'll look at the good old furnace example, and see how dependency inversion allows us to separate high level policy from low level detail in order to create a plug-in architecture.

So get ready for a wild ride through time and technology and we DIP in to the Dependency Inversion Principle.

12. The Interface Segregation Principle
By Uncle Bob, 1h 5m

There may be no I in TEAM, but there sure is an I in SOLID, and that's what this episode is all about: The Interface Segregation Principle.

I remember, long ago, a nemesis of mine on comp.object used to accuse me of being a racist because I used the word "segregation" in this principle. He also took note that I called a particular design pattern "TaskMaster". Ah, Elliott, I sometimes miss your thorn in my flesh.

In this episode we're going to talk about the problem of too much knowledge. We'll show the strange backwards dependency that happens when classes know too much; and the problem that backwards dependency causes.

I'll tell you the story about how the Interface Segregation Principle came into being. It's a story about a company that had a big build-time problem. I'll show you the bizarre solution we discovered to fix that problem; and tell you why soot was so important to that discovery.

We'll talk about fat classes -- classes that have too many methods, and too many dependents. We'll discuss the problems they cause, and how to resolve those problems.

We'll watch a young novice under the tutelage of her master as she struggles through the ATM case study and investigates why too much knowledge harms system structure.

Then we'll investigate the physical structure of interface segregation, and once again assert the importance of the boundary between the application and main.

Finally, we'll talk about the principle behind the principle, and why this principle which on the surface of it seems to be about static typing, is actually not about static typing at all.

So pack the kids in the car, strap the bikes on the roof rack, and cram the tent in the trunk, because we're about to drive into the rugged territory of the Interface Segregation Principle.

11.2. The Liskov Substitution Principle
By Uncle Bob, 32m

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 receive.

So let the horses out of the corral, batten down the hatches, and run for the storm cellar, because LSP has arrived!

11.1. The Liskov Substitution Principle
By Uncle Bob, 55m

Make sure to watch Part 2 after watching this episode!

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 out of the corral, batten down the hatches, and run for the storm cellar, because LSP has arrived!

And remember to get Part 2 when you are done with Part 1!

10. The Open-Closed Principle
By Uncle Bob, 1h 2m

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.

9. The Single Responsibility Principle
By Uncle Bob, 1h 9m

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!

8. Foundations of the SOLID principles
By Uncle Bob, 53m

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.

Clean Code: Fundamentals
7. Architecture, Use Cases, and High Level Design
By Uncle Bob, 1h 22m

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 really are.

So raise your seat backs, and put your tray tables in the upright and locked position, because this episode of Clean Code is about to take off, and we are expecting turbulence as we pass through the preconceived notions of Architecture, Use Cases, and High Level Design.

6.2. TDD
By Uncle Bob, 1h 15m

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".

6.1. TDD
By Uncle Bob, 1h 1m

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 function in an open source project that is covered by tests, and proceeds to clean it fearlessly. The results are impressive, and the mirror forces hold back their ire to await the promised debate.

Here endeth the lesson; or at least part one.

5. Form
By Uncle Bob, 1h 15m

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!

4. Function Structure
By Uncle Bob, 1h 34m

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!

3. Functions
By Uncle Bob, 59m

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.

2. Names++
By Uncle Bob, 44m

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 Episode II -- Names, is about to begin...

1. Clean Code (Remake!)
By Uncle Bob, 54m

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?

Clean Code
0. The Last Programming Language
By Uncle Bob, 59m

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?

Java Case Study
15. The End
By Robert C. Martin & Micah D. Martin, 1h 6m

**THE END.**

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.


Don't despair. More case studies are to follow.

Cool ones too!

But this one is done.

14. A Slice of the Architecture
By Robert C. Martin & Micah D. Martin, 1h 20m

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.

13. Flub-a-Dub
By Robert C. Martin & Micah D. Martin, 1h 35m

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.

  1. We talk about mocking tools.
  2. We talk about dynamic vs static languages.
  3. We talk about refactoring strategies.
  4. 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!

12. Do Easily
By Robert C. Martin & Micah D. Martin, 1h 33m

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).

11. Squashing the Bug
By Robert C. Martin & Micah D. Martin, 1h 20m

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.

10. The Persistent Bug
By Robert C. Martin & Micah D. Martin, 1h 23m

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.

9. Lost In Space
By Robert C. Martin and Micah D. Martin, 1h 10m

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?

8. Into the Tunnel
By Robert C. Martin and Micah D. Martin, 1h 11m

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.

7. The Customer Is Coming
By Robert C. Martin and Micah D. Martin, 1h 13m

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.

6. Where Are We Testing?
By Robert C. Martin & Micah D. Martin, 1h 14m

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.

5. A Series of Twisty Little Threads
By Robert C. Martin & Micah D. Martin, 1h 24m

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.

4. We Write a Web Server
By Robert C. Martin & Micah D. Martin, 1h 6m

Knock knock.

Who's there?

No, not yet. Let's do this later in the episode.

No, not yet. Let's do this later in the episode who?

No. Stop. ... Oh rats.

In this episode we change directions entirely; and we announce a contest!

The episode begins by reviewing a big refactoring that Uncle Bob did off line. It's pretty cool, and you aren't going to want to miss it.

Then we announce the contest that you can participate in (See Below).

Then we take the whole project in a brand new direction. We begin to write our own simple web server. We got frustrated looking at all the other web servers out there, and decided it would be a better use of our time to write our own.

Have you ever written a web server? Its simple; and it's fun! Watch how we do it here; and listen to the rationale we present.

And then enter our contest...

Contest

We ask you to submit a video showing how you would have executed the refactoring that Uncle Bob did. Show it step by step, and keep all tests passing for each step.

The github repository for the Java Case Study is: https://github.com/cleancoders/CleanCodeCaseStudy

Begin at commit: D33B4, and end at a state similar to commit: 72724.

Put your video into a dropbox or something similar, and send a link to Contest@cleancoders.com.

Micah and Uncle Bob will review the videos and select their favorites to be shown as part of an upcoming episode. We reserve the right to edit any videos we present.

3. Sorting Our Issues
By Robert C. Martin & Micah D. Martin, 1h 15m

Boy! All we had to do in this episode is sort one field and add another. And yet we stumbled and fussed all over the place. We even got derailed once by using the Java-6 documents instead of the Java-7 documents. Sheesh!

Watch Uncle Bob in the first half of the episode. He doesn't want to touch the keyboard! What's up with that? He just sits there and grunts imperiously while Micah does all the work.

With all the load on Micah, he starts to get tired too. By the end of the first tomato they're both so knackered that they can't remember how to make the sort function work.

What a difference a break makes. The energy comes back in the second tomato and is running high in the third. I guess all programmers go through periods where they just don't feel up to coding.

There are some interesting technical surprises in this episode. For example, there a classic case for inheritance that we eventually bail out of and use an enum instead. And we find some interesting issues with SimpleDateFormat.

We also dig a bit deeper into the FitNesse fixtures such as Decision Tables, Query Tables, and Ordered Query Tables.

By the end of the episode, you'll see that the code is starting to get pretty messy -- despite the refactoring we've done along the way. And that set's the stage for Episode 4 -- But then I don't want to give too much away.

You can get the source code from github. This episode begins at commit: be8d09 and ends at: 4b885f

2.2. Let the Testing Begin
By Robert C. Martin & Micah D. Martin, 1h 5m

Welcome to the Clean Coders Java Case Study. This is Episode 2, part 2. Make sure you watch part 1 first. This episode picks up right where part 1 left off.

So Micah and I worked for a couple of hours getting our first acceptance tests close to passing. We wrote lots of unit tests, and made a load of progress.

We also encountered several interesting problems. Chief among them was to create a mock database (The Gateway) that behaves enough like a real database to make our tests meaningful.

There's more work to be done on that; and you'll see more on that in Episode 4. But for the moment we managed to figure out how we would deal with unique identifiers for all the data being stored and fetched through the Gateway.

We split this episode into two parts, each about an hour long. There's a lot of stuff going on in each one, so take your time and watch carefully. You'll be the third member of our pair.

Notice, how the pairing is working. Watch how we toss ideas back and forth, and help each other when we get stuck or tired. The dynamics are fascinating.

We reviewed this episode later and found a number of interesting discussion points; so Micah and I recorded some commentary and interspersed it along with the video. It's quite amazing how this little batch of code could raise so many design and architecture issues.

If you want to follow along with the code, you can get it from github here: https://github.com/cleancoders/CleanCodeCaseStudy This episode is in the "E2 Complete" commit from May 13, 2014.

Have fun!

2.1. Let the Testing Begin
By Robert C. Martin & Micah D. Martin, 1h 10m

Welcome to the Clean Coders Java Case Study. This is Episode 2, part 1.

So Micah and I worked for a couple of hours getting our first acceptance tests close to passing. We wrote lots of unit tests, and made a load of progress.

We also encountered several interesting problems. Chief among them was to create a mock database (The Gateway) that behaves enough like a real database to make our tests meaningful.

There's more work to be done on that; and you'll see more on that in Episode 4. But for the moment we managed to figure out how we would deal with unique identifiers for all the data being stored and fetched through the Gateway.

We split this episode into two parts, each about an hour long. There's a lot of stuff going on in each one, so take your time and watch carefully. You'll be the third member of our pair.

Notice, how the pairing is working. Watch how we toss ideas back and forth, and help each other when we get stuck or tired. The dynamics are fascinating.

We reviewed this episode later and found a number of interesting discussion points; so Micah and I recorded some commentary and interspersed it along with the video. It's quite amazing how this little batch of code could raise so many design and architecture issues.

If you want to follow along with the code, you can get it from github here: https://github.com/cleancoders/CleanCodeCaseStudy This episode is in the "E2 Complete" commit from May 13, 2014.

Have fun!

1. Getting Nothing Done
By Uncle Bob and Micah, 1h 6m

Welcome to the Clean Coders Java Case Study. This is Episode 1.

Over the next weeks and months, Micah and Uncle Bob will re-implement the cleancoders.com website in Java before your very eyes. You'll see them applying all the principles, patterns, and practices that you've been learning in the Clean Code series. But instead of learning about those principles, patterns, and practices, you'll see how they use them in real life.

The first episode is entitled Getting Nothing Done because in this episode they use the first acceptance tests in FitNesse to set up the infrastructure and facilities they need to start getting real stories implemented. They do finish one story; but it's the story of the null case.

So get ready for some fun and education and you watch these two seasoned professionals work together to create a web system in Java.

If you want to follow along with the code, you can get it from github here:

https://github.com/cleancoders/CleanCodeCaseStudy

Build an App
4. Eliminating Duplication
By Corey Haines, 50m

"Duplication is the root of all evil!" is a phrase we certainly hear a lot in software development. This is a bit harsh and over-the-top, of course, but it definitely is something we want to keep watch on. Eliminating duplication when we find it, early on in our lifecycle, is a good technique to master. It makes our software more accepting to change in the future, especially change we aren't able to anticipate.

Through our previous episodes, we allowed a bit of duplication to spread regarding the states that a coderetreat can be in. If we let this go on for much longer, it will become much more difficult later to change them. It is time to put our foot down and remove this duplication. When working on a new system, timing is the key and we won't wait any long to address this cleanup task.

In this episode, we'll take a break from adding new features and focus our attention at the concept of duplication, specifically the duplication of knowledge around the statuses of the coderetreats. We'll discuss the different types, and then investigate two different methods for eliminating it by isolating the knowledge it represents: an outside-in, wishful-thinking approach; and, an inside-out, pull-down approach. By the end of the episode, we'll have a central location in our system that contains this information.

And, of course, there is a lot of coding. The results of this episode's coding is in the git repo up on github.

Once you purchase the episode, send an email to Corey and get an invite to the "Discuss BAWCH" mailing list.

If you've missed any of the first 3 episodes, check them out here:

3. 2nd Feature
By Corey Haines, 1h 1m

Purchase this episode, send your purchase code to Corey and get an invite to the exclusive "Discussing BAWCH" mailing list.


Now that we've finished our first feature, where do we go from here? In episode 3 of "Build an App with Corey Haines" we'll not only talk about how our Feature Support Diagram can help us choose the next feature, but we'll dive right in and start it. This episode is all about the code, so we won't be satisfied with just starting it, we'll take it to the finish!

While building this new feature, "Updating the status of a coderetreat", we'll use a strict outside-in approach to our coding. Starting at the view layer and moving inward with a hearty dose of programming by wishful thinking, we'll see more and more of our design coalesce around our domain concepts. Our last episode introduced the concept of a presenter, distancing our business domain away from the Rails framework. In this episode, we'll benefit again from this philosophy, except on the updating side, creating a simple coordinator object.

In Episode 1 and Episode 2, we noticed some awkwardness around some names we chose. At the time, we postponed fixing them until we had more knowledge about our domain. In this episode, we'll see awkward names again, but this time we won't stand for it! After implementing the feature, we'll take time to clean up our design by extracting a new resource. We'll discuss the strategy of making structural changes incrementally, keeping our system working at each step. This is a coding series, so we won't just discuss it, we'll put hands to keyboard and make the changes!

And, of course, there is plenty of ongoing discussion about outside-in development, programming by wishful thinking and how our tests can influence our design. Check it out!

After you purchase this episode, send your purchase code to Corey and get an invite to the exclusive "Discussing BAWCH" mailing list.

Missed an episode? Get them here. - Episode 1 - where do we start? - Episode 2 - our first feature

2. Finishing Our First Feature
By Corey Haines, 56m

Purchase this episode, send your purchase code to Corey and get an invite to the exclusive "Discussing BAWCH" mailing list.


In our last episode (check it out here), we got the basic skeleton of our first feature done with some dummy data. In this episode, we'll finish our feature "Viewing Running Coderetreats" by pushing our dummy data down into our stack. In the end, our dummy data will disappear, and we'll be left with a complete full-stack implementation, from browser to database. As we finish, we'll see how the use of "Programming by wishful thinking" in the last episode set us up nicely to see exactly what our next steps are.

Along the way, we'll begin our conversation about testing. Of course, testing techniques and strategies will be a point of discussion through the whole series, and this episode begins our dive into a better of understanding of the topic. We'll discuss a definition of the difference between test-first and test-driven development, and how these differences affect our strategy.

Fast tests are a big point of discussion these days, so we'll look at a couple initial ways to achieve them in Rails. Just as importantly, we'll spend time talking about the WHY behind fast tests and try to clear up some common misconceptions about the goals.

After you purchase this episode, send your purchase code to Corey and get an invite to the exclusive "Discussing BAWCH" mailing list.

Missed the first episode? Get it here: - Episode 1 - where do we start?

1. Where Do We Start?
By Corey Haines, 43m

Purchase this episode, send your purchase code to Corey and get an invite to the exclusive "Discussing BAWCH" mailing list.


So, you've figured out what features you NEED to build. But now you have the problem of deciding which one to do first. And once you've decided, how do you go about building it? You could, of course, start with an easy one, like user management. But what value would that add? Or, perhaps you'll start with one that suits your mood. But does that add value? Maybe start building a data model diagram? Aaargh! How to decide?

In our first episode of "Build An App With Corey Haines" (lovingly referred to as BAWCH), we'll discuss just this question: where do we start. We'll talk about the fuzzy idea of "business value" and introduce a technique called Feature Support Diagrams. When finished, FSD diagrams literally have arrows pointing to the feature where you should start. And once we've chosen, we'll begin building. We'll look at creating our first two scenarios using Cucumber, then making them pass using a "Programming by Wishful Thinking" outside-in style of development.

Along the way, we'll discuss a lot of the little decisions around starting, all the while moving forward towards our first usable feature.

After you purchase this episode, send your purchase code to Corey and get an invite to the exclusive "Discussing BAWCH" mailing list.

Technical Debt
2. Tracking and Managing
By Michael "Doc" Norton, 48m

In this second episode on Technical Debt, we take a look at how we identify and track debt. We start with Prudent Technical Debt, which is relatively easy to manage. We talk about ways to make sure Prudent Technical Debt gets included in planning and how to tie it to business value.

We'll then look at Reckless Technical Debt. Here, we consider how Deliberate Reckless Technical Debt can become Inadvertent Reckless Technical Debt as a team changes their beliefs without changing their behaviors.

Identifying and tracking Reckless Technical Debt can be a challenge. To help us figure out ways to identify Reckless Technical Debt in our code, we take a look at the SOLID Principles and The 4 Rules of Simple Design. We use these concepts to help us identify any useful static analysis metrics. Finally, we'll briefly discuss the proper outlook for use of metrics.

At the end of this episode, you should have a better sense of why Prudent Technical Debt is far less risky than Reckless Technical Debt and have a few tools for thinking about and tracking your Technical Debt.

1. Technical Debt
By Michael "Doc" Norton, 35m

Technical Debt - that phrase might not mean what you think it means. It most certainly didn't originally mean what it commonly means today.

In this series, we discuss technical debt in depth; what is it, why do we use the debt metaphor, how do we track it, and what should we do about it and when?

We'll talk about the origins of the metaphor and how the metaphor changed over time. We'll take a look at ways of identifying technical debt from AB & Multivariate testing to Complexity, Coverage, Duplication, and Coupling. We'll discuss when to pay down a debt and when to leave it well enough alone by combining our quality metrics along with information on churn and utilization. And we'll discuss techniques that can help when we decide to pay down the debt such as code profiling and the mikado method.

In this first episode on Technical Debt, we take an in-depth look at the history of the metaphor. We'll see how the original definition presumed clean code and how, over time, the metaphor came to be synonymous with messy code.

We'll learn about the Technical Debt Quadrant and look at how it helps us better understand Technical Debt and provides us some beneficial distinctions between types of Technical Debt.

In this episode, we also discuss alternatives to the metaphor and explore what it might look like if other industries had adopted similar metaphors.

All of this leads to a better understanding of the phrase "Technical Debt" and sets the stage for our future conversations.

Programming 101
1. Programming 101
By Uncle Bob, 1h 33m

Free Episode

(Note to programmers. Please review this episode, and send comments to unclebob@cleancoders.com with the subject line P101_E1)

Welcome to Programming 101. This is a video series for those of you who are wondering whether you want to learn how to program computers. This series will teach you that skill.

But this series will do something else. This series will convince you, early on, whether or not programming computers is something you want to do. By the time you are done with this first episode, you will know.

In this episode we cover a lot of ground. We introduce the structure of computers, touch on the basics of logic, add a smidgen of binary math, and just a skosh of the Java programming language. But more importantly, we use that knowledge to solve a typical programming problem. A normal, every day, common, problem: Turning on the lights. That's right, we solve the problem of light switches.

You won't believe just how difficult this problem is to solve, how complicated it is, how many human factors are involved, and how much insight it will give you to the world of programming.

Make no mistake. When you are done with this episode, you'll know almost nothing about programming -- compared to what you still have to learn. But you will have learned one extremely important thing: Programming computers is hard.

Not just hard, but challenging, complicated, subtle, and that you have a lot more to learn.

Some of you will have learned one other very important thing: Programming is fun. You like it, and you want to keep doing it. You can't wait for episode 2.


We want your feedback.

Please send your comments about this episode to unclebob@cleancoders.com, with the subject line: P101-E1. I'd love to hear what you have to say.

Mobile App Case Study
7. Architecture
By Robert C. Martin and Justin Martin, 58m

Wondering what the Mobile App Case Study series is all about?
Watch this free 3-minute intro video and find out!


Straightening out the MESS

Where Justin and I retire to our Summer retreat, and refactor the application to conform to a nice, clean, architecture.

Our goal is to separate the games rules, the data, and the GUI into separate components that have a plugin structure. We want the GUI and the Data modules to plug-in to the Game rules.

This takes three tomatoes of dependency breaking and reforming; while keeping the tests passing.

And in the end, we've created the seed crystal around which this application can continue to safely grow.


The github repository for this series is: https://github.com/unclebob/MACS_GOMOKU

6. Resolution
By Robert C. Martin and Justin Martin, 1h 18m

Wondering what the Mobile App Case Study series is all about?
Watch this free 3-minute intro video and find out!


Were Done!

Yep. We got the whole thing working.

Well, almost. I mean -- good enough for this video series.


The episode began with a big up front design for detecting wins. And then we abandoned that and adopted an incremental approach that got us 2/3 of the way there. The rest is in sight.

We also played around with the dependencies a bit, debating what modules should depend on which other modules.

And then...

OH OH!

...we looked at the overall structure of the system. We drew the diagram on the board. And we discovered that after 6 hours of work, 18 tomatoes, we had built a dependency rat's nest.

We can't leave it like this!

And so, we have one more episode to do. We need to fix the architecture.


The github repository for this series is: https://github.com/unclebob/MACS_GOMOKU

5. Policy & Presentation
By Robert C. Martin and Justin Martin, 1h 16m

Wondering what the Mobile App Case Study series is all about?
Watch this free 3-minute intro video and find out!


The Architecture intrudes.

In this episode we start to see the architecture rearing up and asserting itself.

This begins with a discussion about the turn-taking policy. Where does that belong? And what direction should the dependencies point.

This leads to the adoption of the Model-View-Presenter pattern, to decouple the testable, from the untestable portions of the GUI.

Various dependency management techniques are tried; including one using lambdas that ends up burning our brains at the end of the episode.

Oh, yeah, and we get caught by that refactoring we did last episode, when we removed all the keyword arguments.

Anyway -- The Architecture has Begun.


The github repository for this series is: https://github.com/unclebob/MACS_GOMOKU

4. Seriously, We Lost It!
By Robert C. Martin and Justin Martin, 56m

Wondering what the Mobile App Case Study series is all about?
Watch this free 3-minute intro video and find out!


A spasm of Refactoring.

A spasm of refactoring in which we lost the video of the first tomato -- thankfully!

Yes, it's true. We lost the first tomato. Well, we didn't lose it. We just forgot to hit the record button.

But don't worry. We summarized it for you.

We also SPED UP THE TESTS!

Well, we think we did anyway. It's kind of hard to tell. You'll see. But Justin does a nice job showing you how to do it.

EXCEPTIONS ELIMINATED.

Anyway, we got down to business in the second tomato by removing all the horrible exceptions and replacing them with tuple-based error returns. As it turns out, this worked pretty well.

We also walked through the code replacing most of the keyword arguments with positional arguments -- something that swift does not make particularly convenient. We did this because the code just looked better once it was done.

And then we found a torture device and subjected ourselves to it.


The github repository for this series is: https://github.com/unclebob/MACS_GOMOKU

3. Chugging Along
By Robert C. Martin and Justin Martin, 1h 13m

Wondering what the Mobile App Case Study series is all about?
Watch this free 3-minute intro video and find out!


OK, Enough of this Model First nonsense. Let's write the GUI!

And let's write the GUI in a language that has static typing cranked all the way to 11; and that interfaces to a framework that was designed for a dynamically typed language!

What could go wrong?

Actually, our dynamic duo does a pretty good job of it. Despite struggling with floating point numbers and the strange path structure, in three tomatoes they get a functioning GUI on the screen.

There's just one problem: They didn't write any tests. Wasn't this series supposed to teach TDD?

Ah, but TDD and GUIs...


The github repository for this series is: https://github.com/unclebob/MACS_GOMOKU

2. Proceeding with Precision
By Robert C. Martin and Justin Martin, 1h 21m

Wondering what the Mobile App Case Study series is all about?
Watch this free 3-minute intro video and find out!


In this episode our intrepid pair continue to employ the Model First principle by adding more capability to the game board as well as beginning to build the rules that will detect wins.

Frustration mounts with the tool, the speed of tests, and the language; causing the pair to eventually resort to long dead german poets to vent their angst.

Exceptions begin to rear their ugly head; setting the pair on a path that will trouble them for several episodes to come.


The github repository for this series is: https://github.com/unclebob/MACS_GOMOKU

1. Getting Started
By Robert C. Martin and Justin Martin, 1h 22m

Wondering what the Mobile App Case Study series is all about?
Watch this free 3-minute intro video and find out!


Hey Justin, you're something of an Mobile app expert nowadays, aren't you?

Well, I have built several significant iPhone apps for various clients over the past few years.

Do you want to do a video series on the topic?

Sure, Dad. That sounds like fun. Actually, I've been learning Swift. Do you want to do the videos using Swift?

Swift, eh? Sure, why not. I don't mind learning a new language. We can do TDD right?

Yes, the tools support TDD, no problem.

Great! OK, so let's write a simple Go-Moku app.

You mean that five-in-a-row game you play on a GO board? That sounds like fun. So what are we trying to teach in this series?

Well, I think our focus should be to use the series to teach the following principles:

  • TDD -- How to do Test Driven Development, for a mobile app, in Xcode and Swift.

  • Pairing -- You and I will pair program, and talk through our issues so that the viewers can follow along.

  • Pomodoro -- We'll use the Pomodoro time-management technique both to structure the videos, and to manage our time.

  • Model First -- We'll drive the development by building the business rules first, and then fit the GUI, network, and data access in later.

  • Clean Architecture -- We'll separate the GUI, Business rules, data access, etc. into separable components. Keeping the architecture clean.

  • Dependency Management -- Using OO, we'll create a plugin structure between those components that will allow the application to scale.

  • Swift -- And, we'll explore some of the interesting language quirks and features of Swift.

OK, so just normal, professional, mobile development. I'm on board. Sounds like a hoot. Let's go!


The github repository for this series is: https://github.com/unclebob/MACS_GOMOKU

0. Intro
By Robert C. Martin and Justin Martin, 3m

This is our free introduction to the Mobile Application Case Study, in which we develop an iPhone app using Swift.

Get ready for quite a trip as we spend 7 episodes (21 tomatoes) TDD our way to a GoMoku application using XCode and Swift.

As you watch us you'll see the problems we had with the IDE, with the language, and with the framework. You'll also see how we solve them, and drive the application from it's initial meager beginnings to a final scalable architecture.

So, buckle up, because this is one cool ride.

Clean Code In The Browser
1. Clean Code In The Browser
By Chris Powers, 1h 20m

The Web has been a dominant platform for over twenty years, but over that time code quality has been surprisingly low. An entire generation of developers came up through the ranks with a working understanding that front-end code was hard to write well, and harder to maintain over time. How did we get here, and how can we make positive changes towards quality in our browser code?

This new series is called "Clean Code in the Browser" and focuses on improving the code quality of our front-end code. In this first episode we look at how we got into this mess in the first place:

We start by exploring common pitfalls and patterns that lead to failure in Web projects.

Next, we go back through a brief history of quality on the Web since its inception, analyzing the forces that set the stage for poor code quality in front-end code.

Once we've looked at the historical forces, we move on to cultural forces. We talk about the division between front-end and back-end developers and how these rifts reinforce cultures where quality is not valued.

Finally, we will look at Client-Server architecture and how its role in the Web has shifted over the last 50 years. These changes have introduced architectural challenges to Web developers and make it more difficult to maintain best practices.