diff --git a/uncle-bob/_posts/2011-11-22-Clean-Architecture.textile b/uncle-bob/_posts/2011-11-22-Clean-Architecture.textile index 3edf051..4fee232 100644 --- a/uncle-bob/_posts/2011-11-22-Clean-Architecture.textile +++ b/uncle-bob/_posts/2011-11-22-Clean-Architecture.textile @@ -3,6 +3,8 @@ layout: post title: Clean Architecture tags: ["Architecture"] --- + + In the weeks since I started talking about the need to clean up our architecture, I've noticed a surprising resistance to the idea. Apparently the notion that it's a good idea to hide the framework, UI, or database from the application code is not universally accepted. I first blogged about this topic "here":{% post_url 2011-09-30-Screaming-Architecture %}, I did a whole cleancoders.com "episode":http://www.cleancoders.com/codecast/clean-code-episode-7/show on the topic. I've also done several keynotes on the topic, the slides for which are "here":http://dl.dropbox.com/u/4730299/Architecture%20the%20lost%20years.key, and a video recording of which is "here":http://mchenry.softwarecraftsmanship.org/the-a-word-a-discussion-about-architecture. diff --git a/uncle-bob/_posts/2011-12-11-The-Barbarians-are-at-the-Gates.textile b/uncle-bob/_posts/2011-12-11-The-Barbarians-are-at-the-Gates.textile index 644d00d..4856b0a 100644 --- a/uncle-bob/_posts/2011-12-11-The-Barbarians-are-at-the-Gates.textile +++ b/uncle-bob/_posts/2011-12-11-The-Barbarians-are-at-the-Gates.textile @@ -3,6 +3,8 @@ layout: post title: The Barbarians are at the Gates tags: ["Coding"] --- + + There's a revolution coming. I wonder if anyone has noticed. It's not subtle. It won't be sublime, or easy to integrate. Indeed, it'll probably muck up everything for a long long time. But it's coming nonetheless, and you'd better be strapped in and ready for the impact. The challenge for computing is _power_. How much processing can you get done per unit of time. Over the last fifty years we've seen this power increase by a scale that we usually reserve for thermonuclear weapons, supermassive black holes, or core-collapse supernovae. We might characterize that power increase with the following formula: diff --git a/uncle-bob/_posts/2012-01-11-Flipping-the-Bit.textile b/uncle-bob/_posts/2012-01-11-Flipping-the-Bit.textile index 33e9c44..7b57180 100644 --- a/uncle-bob/_posts/2012-01-11-Flipping-the-Bit.textile +++ b/uncle-bob/_posts/2012-01-11-Flipping-the-Bit.textile @@ -4,6 +4,7 @@ title: Flipping the Bit tags: ["Testing", "Craftsmanship"] old_tags: ["TDD", "Professionalism", "Craftsmanship"] --- + There's a bit you need to flip in your head. It's just one bit. In this blog we'll call it "THE BIT". Some of you have already flipped THE BIT. The rest of you need to flip THE BIT as soon as possible. diff --git a/uncle-bob/_posts/2012-01-12-The-Letter.textile b/uncle-bob/_posts/2012-01-12-The-Letter.textile index 15730a8..400ca79 100644 --- a/uncle-bob/_posts/2012-01-12-The-Letter.textile +++ b/uncle-bob/_posts/2012-01-12-The-Letter.textile @@ -4,6 +4,7 @@ title: The Letter tags: ["Testing", "Craftsmanship"] old_tags: ["TDD", "Professionalism", "Craftsmanship"] --- + We need to become a self-regulating and self-policing profession. The stakes are simply too high to allow software to remain in the current ad-hoc limbo of hackers, heroics, and hermits. Consider how much software you interact with every day. Your alarm clock, your cell phone, the television and cable box, the remote control, your toaster oven, your watch, your car, the train to work, the cash register at Starbucks, the coffee maker at Starbucks, the elevator you ride, etc. etc. The list is virtually endless. Nearly every aspect of our daily lives, nearly ever corner of our civilization is somehow touched, controlled, managed, or influenced by software. diff --git a/uncle-bob/_posts/2012-01-20-Fecophiles.textile b/uncle-bob/_posts/2012-01-20-Fecophiles.textile index baab1c5..6639377 100644 --- a/uncle-bob/_posts/2012-01-20-Fecophiles.textile +++ b/uncle-bob/_posts/2012-01-20-Fecophiles.textile @@ -4,6 +4,7 @@ title: Fecophiles tags: ["Craftsmanship"] old_tags: ["Professionalism", "Craftsmanship", "Clean Code"] --- + I got an interesting email yesterday. It contained the following paragraph describing an email he had sent to his co-workers about a refactoring he had done: bq. When I originally sent this email to my co-workers, I got the following reaction; 1 team member thought it was better & 2 team members thought it was harder to understand. Of the 2 who thought it was worse; 1 thinks I should change it back, and the other is willing to put up with my change to shut me up :-) diff --git a/uncle-bob/_posts/2012-01-31-The-Ruby-Colored-Box.textile b/uncle-bob/_posts/2012-01-31-The-Ruby-Colored-Box.textile index 9c39dbc..c64d505 100644 --- a/uncle-bob/_posts/2012-01-31-The-Ruby-Colored-Box.textile +++ b/uncle-bob/_posts/2012-01-31-The-Ruby-Colored-Box.textile @@ -4,7 +4,7 @@ title: The Ruby Colored Box tags: ["Craftsmanship", "Tools"] old_tags: ["Professionalism", "Craftsmanship", "Ruby"] --- - + I recently read a "blog":http://www.unlimitednovelty.com/2011/12/can-you-solve-this-problem-for-me-on.html about a guy who had a bad interview. The blog was well written and pretty funny. He metaphorically described the interview in terms of a mexican chef being grilled about how to make crème brûlée. He made a bunch of interesting points about how unfair the interview was, and how you shouldn't ask a mexican chef how to cook pastry. The blog was in two parts, the mexican chef metaphor, and then a rant. By the time I got to the end of the metaphor I was pretty much thinking that the author was a bit of a whiner. OK, so the interview was unfair. What interview isn't? Why would any employer want to conduct a "fair" interview. I'm certainly not fair when I interview people. I put them under all kinds of stresses, and throw lots of strange issues at them. I want to see how they behave when confronted with unfamiliar problems. I want to know if they can extrapolate their experience into a new domain. diff --git a/uncle-bob/_posts/2012-02-01-Service-Oriented-Agony.textile b/uncle-bob/_posts/2012-02-01-Service-Oriented-Agony.textile index b15e2b4..3376cc8 100644 --- a/uncle-bob/_posts/2012-02-01-Service-Oriented-Agony.textile +++ b/uncle-bob/_posts/2012-02-01-Service-Oriented-Agony.textile @@ -4,7 +4,7 @@ title: Service Oriented Agony tags: ["Architecture", "Craftsmanship"] old_tags: ["Architecture", "Craftsmanship", "SOA"] --- - + I sat down with a group of developers today to do a retrospective on a project. They told me that project management has been complaining about their velocity. It wasn't serious, but the developers felt bad because things _do_ seem to take longer than they should. When I asked them why, they said that the system was very complex, and making changes to it was time consuming. I asked them to draw the system on the whiteboard. Here's what they drew. diff --git a/uncle-bob/_posts/2012-04-18-After-The-Disaster.textile b/uncle-bob/_posts/2012-04-18-After-The-Disaster.textile index 430d82b..3bfc576 100644 --- a/uncle-bob/_posts/2012-04-18-After-The-Disaster.textile +++ b/uncle-bob/_posts/2012-04-18-After-The-Disaster.textile @@ -4,7 +4,7 @@ title: After the Disaster tags: ["Craftsmanship"] old_tags: ["Professionalism", "Craftsmanship"] --- - + There's a disaster coming. I don't know when. I don't know what. But it's coming, and there's nothing we can do to stop it; but there _is_ something we can do to mitigate it. How much software is running near you at the moment? Of course you are reading this on a web browser, and that computer you are sitting next to has lots of software running in it. And there are probably many other computers near you with software running on them. Is there software in your cell phone? Of course. How about in your watch? Likely. In the light switch on the wall? How about in the light bulbs? The intercom? The doorbell? The thermostat? Your furnace? Your air conditioner? Your refrigerator, dishwasher, washing-machine, drier? How about your car; and all the other cars on the road? How about the traffic signals? Did you ride an elevator today? Get in a plane or a train? How about an escalator? Do you have a pacemaker? An insulin pump? diff --git a/uncle-bob/_posts/2012-04-20-Why-Is-Estimating-So-Hard.textile b/uncle-bob/_posts/2012-04-20-Why-Is-Estimating-So-Hard.textile index 89798c2..77a6ba8 100644 --- a/uncle-bob/_posts/2012-04-20-Why-Is-Estimating-So-Hard.textile +++ b/uncle-bob/_posts/2012-04-20-Why-Is-Estimating-So-Hard.textile @@ -4,6 +4,7 @@ title: Why is Estimating so Hard? tags: ["Craftsmanship"] old_tags: ["Professionalism", "Craftsmanship"] --- + Consider the Gettysburg Address: "Four score and seven years ago our fathers brought forth upon this continent a new nation, conceived in liberty and dedicated to the proposition that all men are created equal..." diff --git a/uncle-bob/_posts/2012-05-15-NODB.textile b/uncle-bob/_posts/2012-05-15-NODB.textile index eab5ecf..a7cd12c 100644 --- a/uncle-bob/_posts/2012-05-15-NODB.textile +++ b/uncle-bob/_posts/2012-05-15-NODB.textile @@ -4,6 +4,7 @@ title: NO DB tags: ["Architecture", "Tools", "Craftsmanship"] old_tags: ["Professionalism", "Architecture", "Database", "Rant"] --- + In the United States, in 1920, the manufacture, sale, and importation of alcoholic beverages was prohibited by a constitutional amendment. That amendment was repealed thirteen years later. During that period of prohibition, the beer industry died. In 1933, when prohibition was lifted, a few giant grain companies started brewing beer. They completely cornered the market. And for nearly 50 years, we in the United State drank this fizzy bodily effluent and called it “beer”. The only way to tolerate the flavor was to drink it very cold. diff --git a/uncle-bob/_posts/2012-08-13-the-clean-architecture.textile b/uncle-bob/_posts/2012-08-13-the-clean-architecture.textile index abbdae9..0b8b4a9 100644 --- a/uncle-bob/_posts/2012-08-13-the-clean-architecture.textile +++ b/uncle-bob/_posts/2012-08-13-the-clean-architecture.textile @@ -3,6 +3,7 @@ layout: post title: The Clean Architecture tags: ["Architecture", "Craftsmanship"] --- + Over the last several years we've seen a whole range of ideas regarding the architecture of systems. These include: diff --git a/uncle-bob/_posts/2012-08-24-functional-programming-for-the-object-oriented-programmer.textile b/uncle-bob/_posts/2012-08-24-functional-programming-for-the-object-oriented-programmer.textile index 53c7aeb..498e3ad 100644 --- a/uncle-bob/_posts/2012-08-24-functional-programming-for-the-object-oriented-programmer.textile +++ b/uncle-bob/_posts/2012-08-24-functional-programming-for-the-object-oriented-programmer.textile @@ -4,6 +4,7 @@ title: Functional Programming for the Object Oriented Programmer tags: ["Tools"] old_tags: ["Clojure", "Functional Programming"] --- + This book, written by Brian Marick, is important. Indeed, it may be _necessary_. We need something to bridge the gap between the huge population of OO programmers, and the growing need for functional programmers. I've seen nothing else that fills this need so well. I read a lot of books, but few are so competently written. I'm a hundred pages in and I'm loving it. If you are a Java, C#, C++, Ruby, or Python programmer, and you are wondering what all this _functional programming_ noise is about, this is the book for you. diff --git a/uncle-bob/_posts/2012-09-06-I-am-Your-New-CTO.textile b/uncle-bob/_posts/2012-09-06-I-am-Your-New-CTO.textile index 0e2e54f..42302f8 100644 --- a/uncle-bob/_posts/2012-09-06-I-am-Your-New-CTO.textile +++ b/uncle-bob/_posts/2012-09-06-I-am-Your-New-CTO.textile @@ -4,6 +4,7 @@ title: The New CTO tags: ["Craftsmanship"] old_tags: ["Craftsmanship", "Professionalism"] --- + "So, what did you think of _that_?" I asked as we sat down at our regular table in the cafeteria. As I scanned the other tables in the lunchroom I could see that many other teams were leaning in to their conversation and speaking in semi-hushed tones. The normally light-hearted lunchtime banter had been replaced with a new intensity. "It started pretty well." said Jasper. "I mean he was nice enough at first, introducing himself as the new CTO and all." diff --git a/uncle-bob/_posts/2012-12-19-Three-Paradigms.textile b/uncle-bob/_posts/2012-12-19-Three-Paradigms.textile index 635029c..100c491 100644 --- a/uncle-bob/_posts/2012-12-19-Three-Paradigms.textile +++ b/uncle-bob/_posts/2012-12-19-Three-Paradigms.textile @@ -4,7 +4,7 @@ title: Three Paradigms tags: ["Tools"] old_tags: ["Functional Programming"] --- - + In the last 40 years computer hardware technology has increased the computing power of our machines by well over twenty orders of magnitude. We now play Angry Birds on our phones, which have the computing power of the freon cooled supercomputer monsters of the 70s. But in that same 40 years software technology has barely changed at all. After all, we still write the same if statements, while loops, and assignment statements we did back in the '60s. If I took a programmer from 1960 and brought him forward through time to sit at my laptop and write code; he'd need 24 hours to recover from the shock; but then he'll be able to write the code. The concepts haven't changed that much. diff --git a/uncle-bob/_posts/2012-12-22-FPBE1-Whats-it-all-about.textile b/uncle-bob/_posts/2012-12-22-FPBE1-Whats-it-all-about.textile index 13df336..a89b91d 100644 --- a/uncle-bob/_posts/2012-12-22-FPBE1-Whats-it-all-about.textile +++ b/uncle-bob/_posts/2012-12-22-FPBE1-Whats-it-all-about.textile @@ -4,7 +4,7 @@ title: FP Basics E1 tags: ["Tools"] old_tags: ["Functional Programming"] --- - + h4. What's Functional Programming all about? By now you've almost certainly heard of functional programming. I mean, how could you miss it? Everybody's talking about it. There are all these new functional languages coming out like Scala, F# and Clojure. People are talking about older languages too, like Erlang, Haskell, ML, and others. diff --git a/uncle-bob/_posts/2012-12-29-Brave-New-Year.textile b/uncle-bob/_posts/2012-12-29-Brave-New-Year.textile index 645adef..ee63c92 100644 --- a/uncle-bob/_posts/2012-12-29-Brave-New-Year.textile +++ b/uncle-bob/_posts/2012-12-29-Brave-New-Year.textile @@ -4,6 +4,7 @@ title: Brave New Year tags: ["Community"] old_tags: ["Prognostication"] --- + This is going to be one of those annoying, rambling, touchy-feely, new-years blogs. You know the kind. One that tries to make you think about what's passed, and what's coming. One that tries to impress you with foresight and erudition. One that claims profundity and depth. You know the kind. Still, that's the mood I'm in. So here goes. diff --git a/uncle-bob/_posts/2013-01-02-FPBE2-Whys-it-called-functional.textile b/uncle-bob/_posts/2013-01-02-FPBE2-Whys-it-called-functional.textile index 0e9c7b1..98db2b3 100644 --- a/uncle-bob/_posts/2013-01-02-FPBE2-Whys-it-called-functional.textile +++ b/uncle-bob/_posts/2013-01-02-FPBE2-Whys-it-called-functional.textile @@ -4,7 +4,7 @@ title: FP Basics E2 tags: ["Tools"] old_tags: ["Functional Programming"] --- - + h4. Why's it called Functional? In the previous episode I told you what all the functional programming hubbub is all about. Remember: Referential Transparency and the multi-core freight train? Since you are here, reading episode 2, I presume you were convinced by my arguments and want to know more. diff --git a/uncle-bob/_posts/2013-01-07-FPBE3-Do-the-rules-change.textile b/uncle-bob/_posts/2013-01-07-FPBE3-Do-the-rules-change.textile index 5c505bf..372b805 100644 --- a/uncle-bob/_posts/2013-01-07-FPBE3-Do-the-rules-change.textile +++ b/uncle-bob/_posts/2013-01-07-FPBE3-Do-the-rules-change.textile @@ -4,7 +4,7 @@ title: FP Basics E3 tags: ["Tools"] old_tags: ["Functional Programming"] --- - + h4. Do all the Rules Change? Whenever we start to use a new paradigm, we confront the problem of our old rules and our old habits. We ask ourselves whether all those rules and habits are valid in the new paradigm. Consider, for example Test Driven Development. Is it valid in Functional Programming? If so, how do you do it? diff --git a/uncle-bob/_posts/2013-01-29-FPBE4-Lazy-Evaluation.markdown b/uncle-bob/_posts/2013-01-29-FPBE4-Lazy-Evaluation.markdown index 6aa7489..dfb5b6a 100644 --- a/uncle-bob/_posts/2013-01-29-FPBE4-Lazy-Evaluation.markdown +++ b/uncle-bob/_posts/2013-01-29-FPBE4-Lazy-Evaluation.markdown @@ -4,7 +4,7 @@ title: FP Basics E4 tags: ["Tools"] old_tags: ["Functional Programming"] --- - + #### Lazy Evaluation Remember my squares of integers program in clojure? diff --git a/uncle-bob/_posts/2013-01-30-The-Craftsman-And-The-Laborer.markdown b/uncle-bob/_posts/2013-01-30-The-Craftsman-And-The-Laborer.markdown index f4c7ee0..89bf15c 100644 --- a/uncle-bob/_posts/2013-01-30-The-Craftsman-And-The-Laborer.markdown +++ b/uncle-bob/_posts/2013-01-30-The-Craftsman-And-The-Laborer.markdown @@ -3,6 +3,7 @@ layout: post title: The Laborer and the Craftsman tags: ["Craftsmanship"] --- + In a recent [blog](http://blogs.tedneward.com/2013/01/24/On+The+Dark+Side+Of+Craftsmanship.aspx) Ted Neward made this remarkable statement: >I'm criticizing because this is what "software craftsmanship" gets us: an imposed segregation of those who "get it" from those who "don't" based on somebody's arbitrary criteria of what we should or shouldn't be doing. And if somebody doesn't use the "right" tools or code it in the "right" way, then bam! You clearly aren't a "craftsman" (or "craftswoman"?) and you clearly don't care about your craft and you clearly aren't worth the time or energy necessary to support and nourish and grow and.... diff --git a/uncle-bob/_posts/2013-02-01-The-Humble-Craftsman.markdown b/uncle-bob/_posts/2013-02-01-The-Humble-Craftsman.markdown index fbdb2fa..e1eb9c8 100644 --- a/uncle-bob/_posts/2013-02-01-The-Humble-Craftsman.markdown +++ b/uncle-bob/_posts/2013-02-01-The-Humble-Craftsman.markdown @@ -3,6 +3,7 @@ layout: post title: The Humble Craftsman tags: ["Craftsmanship"] --- + There is another side to Ted Neward's [blog](http://blogs.tedneward.com/2013/01/24/On+The+Dark+Side+Of+Craftsmanship.aspx); and it's a side that I agree with. I believe Ted's overall thesis and analysis was wrong. Software Craftsmanship does not automatically give us a blue-collar/white-collar dichotomy; it does not automatically separate those who "get it" from those who don't. It does not automatically create a condescending elite who lord their self-perceived superiority over the unwashed masses. And, in case you hadn't noticed, I _really_ disliked Ted's manipulative appeal to populism. However, Ted was not entirely wrong either. Because there are folks (and, to my shame, I've sometimes numbered among them) who have behaved badly when pointing out problems or deficiencies in other peoples' code. To those people (and to myself) I'd like to make the following points. diff --git a/uncle-bob/_posts/2013-02-10-ThePrinciplesOfCraftsmanship.markdown b/uncle-bob/_posts/2013-02-10-ThePrinciplesOfCraftsmanship.markdown index 6ba3d80..4235ac2 100644 --- a/uncle-bob/_posts/2013-02-10-ThePrinciplesOfCraftsmanship.markdown +++ b/uncle-bob/_posts/2013-02-10-ThePrinciplesOfCraftsmanship.markdown @@ -3,6 +3,7 @@ layout: post title: The Principles of Craftsmanship tags: ["Craftsmanship"] --- + It should come as no surprise to anyone that I think 8th Light Inc. is a remarkable company. The company was founded, and is run, by two of my previous apprentices; one of whom is my son Micah, and the other is Paul Pagel. From the start they based their ideals on those of software craftsmanship. They wanted to build a community of professionals who _believed in their core_ that the best way to build software was to build it well. Now, with the better part of a decade behind them, they are one of the most successful software consulting businesses in Chicago; and will soon be able to make that claim about Tampa, Florida. The company is unique in many ways. For example: Their employees are called craftsmen, and the recruiting model is based upon apprenticeship. Craftsmen are not hired in the usual sense that an employee is hired. Rather, they are brought on as apprentices and gradually inducted into the company through a months long intricate ritual of training, mentoring, challenge, and accomplishment. It's a tough gauntlet to walk; and those few who make it through know they have achieved something difficult and important. diff --git a/uncle-bob/_posts/2013-03-05-TheStartUpTrap.markdown b/uncle-bob/_posts/2013-03-05-TheStartUpTrap.markdown index 4d09c0b..f430d5c 100644 --- a/uncle-bob/_posts/2013-03-05-TheStartUpTrap.markdown +++ b/uncle-bob/_posts/2013-03-05-TheStartUpTrap.markdown @@ -3,6 +3,7 @@ layout: post title: The Start-Up Trap tags: ["Craftsmanship", "Testing"] --- + * **You** have joined a new startup. * **You** are a multi-talented mega-being. * **You** can work 60, 70, 80 hours per week to get the job done. diff --git a/uncle-bob/_posts/2013-03-06-ThePragmaticsOfTDD.markdown b/uncle-bob/_posts/2013-03-06-ThePragmaticsOfTDD.markdown index a207154..eb08d3e 100644 --- a/uncle-bob/_posts/2013-03-06-ThePragmaticsOfTDD.markdown +++ b/uncle-bob/_posts/2013-03-06-ThePragmaticsOfTDD.markdown @@ -3,6 +3,7 @@ layout: post title: The Pragmatics of TDD tags: ["Craftsmanship", "Testing"] --- + So my last blog: [The Startup Trap]({% post_url 2013-03-05-TheStartUpTrap %}) raised quite a ruckus. Amidst the various shouts of agreement and support, there was also a group who vehemently disagreed. I'm not going to summarize all their disagreements here, since I've already used up my quota of curse words for the month. But one of those disagreements struck me as something I should address. It's the old argument of pragmatism vs. dogmatism. In essence, the complaint was that I was being too dogmatic. That TDD might be great in some cases, but in others it might have too high a cost. So you have to be pragmatic and choose wisely. diff --git a/uncle-bob/_posts/2013-03-08-AnOpenAndClosedCase.markdown b/uncle-bob/_posts/2013-03-08-AnOpenAndClosedCase.markdown index 98d929a..8c3f5c5 100644 --- a/uncle-bob/_posts/2013-03-08-AnOpenAndClosedCase.markdown +++ b/uncle-bob/_posts/2013-03-08-AnOpenAndClosedCase.markdown @@ -3,6 +3,7 @@ layout: post title: An Open and Closed Case tags: ["Craftsmanship", "Coding"] --- + I awoke this morning to see a twitter conversation about the Open-Closed Principle. The tweeter was complaining that it didn't make a lot of sense. He said things like: >"Presumably true OCP fans barely use version control, btw. Only reason to change a source file is for bug fixes, right?" diff --git a/uncle-bob/_posts/2013-03-11-TheFrenziedPanicOfRushing.markdown b/uncle-bob/_posts/2013-03-11-TheFrenziedPanicOfRushing.markdown index 3d50339..3b5bc33 100644 --- a/uncle-bob/_posts/2013-03-11-TheFrenziedPanicOfRushing.markdown +++ b/uncle-bob/_posts/2013-03-11-TheFrenziedPanicOfRushing.markdown @@ -3,6 +3,7 @@ layout: post title: The Frenzied Panic of Rushing tags: ["Craftsmanship", "Testing"] --- + Last week I wrote a blog entitled [The Startup Trap]({% post_url 2013-03-05-TheStartUpTrap %}) in which I lamented the unfortunate tendency of developers in a startup to cast their disciplines aside in order to maintain the "high" generated by the illusion that effort is speed. I specifically mentioned TDD as one of those disciplines that startup developers sometimes eschew. The response in support of the blog was gratifying. The response in denial (Yes, that's the right word) of the blog was expected; though I was somewhat surprised by the vehemence and amplitude of the various pejoratives, barbs, insults, and other ad hominem statements. I suppose that people who are addicted to a "high" do not take kindly to those who challenge their ability to justify and maintain that "high". diff --git a/uncle-bob/_posts/2013-05-27-FibTPP.html b/uncle-bob/_posts/2013-05-27-FibTPP.html index a09708c..d225268 100755 --- a/uncle-bob/_posts/2013-05-27-FibTPP.html +++ b/uncle-bob/_posts/2013-05-27-FibTPP.html @@ -3,7 +3,7 @@ title: Fib. The T-P Premise. tags: ["Coding"] --- - +
diff --git a/uncle-bob/_posts/2013-05-27-FlashTpp.html b/uncle-bob/_posts/2013-05-27-FlashTpp.html index ee7f752..b5859a1 100755 --- a/uncle-bob/_posts/2013-05-27-FlashTpp.html +++ b/uncle-bob/_posts/2013-05-27-FlashTpp.html @@ -4,7 +4,7 @@ tags: ["Coding"] --- - +
diff --git a/uncle-bob/_posts/2013-05-27-TheTransformationPriorityPremise.html b/uncle-bob/_posts/2013-05-27-TheTransformationPriorityPremise.html index 6bc3939..bc41f6d 100644 --- a/uncle-bob/_posts/2013-05-27-TheTransformationPriorityPremise.html +++ b/uncle-bob/_posts/2013-05-27-TheTransformationPriorityPremise.html @@ -3,6 +3,7 @@ title: The Transformation Priority Premise tags: ["Coding"] --- +
diff --git a/uncle-bob/_posts/2013-05-27-TransformationPriorityAndSorting.html b/uncle-bob/_posts/2013-05-27-TransformationPriorityAndSorting.html index abe46fc..b493ef5 100755 --- a/uncle-bob/_posts/2013-05-27-TransformationPriorityAndSorting.html +++ b/uncle-bob/_posts/2013-05-27-TransformationPriorityAndSorting.html @@ -3,6 +3,7 @@ title: Transformation Priority and Sorting tags: ["Coding"] --- +
January 1 2011
In this post we explore the Transformation Priority Premise in the context of building a sort algorithm. diff --git a/uncle-bob/_posts/2013-09-23-Test-first.markdown b/uncle-bob/_posts/2013-09-23-Test-first.markdown index 8f46e53..bb9201a 100644 --- a/uncle-bob/_posts/2013-09-23-Test-first.markdown +++ b/uncle-bob/_posts/2013-09-23-Test-first.markdown @@ -3,6 +3,7 @@ layout: post title: Test First tags: ["Craftsmanship", "Coding", "Testing"] --- + I first heard the term "Test First" in 1998. Back then it was part of the phrase "Test First Design". We often shortened it to "Test First". Later, Kent Beck, the originator of the concept, changed the name to Test Driven Development; and it has gone by the acronym TDD ever since. But the words "Test First" have a connotation that the words "Test Driven Development" don't. That connotation is deeper than most people suspect. What does "Test First" really mean? ###Tests are Specs. diff --git a/uncle-bob/_posts/2013-09-26-AT-FAIL.markdown b/uncle-bob/_posts/2013-09-26-AT-FAIL.markdown index a787e9e..67f02c9 100644 --- a/uncle-bob/_posts/2013-09-26-AT-FAIL.markdown +++ b/uncle-bob/_posts/2013-09-26-AT-FAIL.markdown @@ -3,6 +3,7 @@ layout: post title: A.T. FAIL! tags: ["Testing"] --- + Recently Kevin Liddle, a colleague of of mine at [8th Light](http://8thlight.com), wrote a blog entitled: [The Case Against Cucumber](http://blog.8thlight.com/kevin-liddle/2013/09/18/a-case-against-cucumber.html). This blog fits in with a trend started by Jim Shore in 2010 and before. Jim's position is well expressed in his blog: [The Problems with Acceptance Testing](http://www.jamesshore.com/Blog/The-Problems-With-Acceptance-Testing.html). My response to this is: diff --git a/uncle-bob/_posts/2013-10-01-Dance-You-Imps.markdown b/uncle-bob/_posts/2013-10-01-Dance-You-Imps.markdown index 39ce1c9..db3c233 100644 --- a/uncle-bob/_posts/2013-10-01-Dance-You-Imps.markdown +++ b/uncle-bob/_posts/2013-10-01-Dance-You-Imps.markdown @@ -3,6 +3,7 @@ layout: post title: Dance you Imps! tags: ["Tools"] --- + There are several tools out there that promise to bridge the divide between objects and relational tables. Many of these tools are of high quality, and are very useful. They are collectively known as ORMs, which stands for _Object Relational Mappers_. There's just one problem. There ain't no such beast! ### The Impedance Mismatch diff --git a/uncle-bob/_posts/2013-10-24-The-Careless-Ones.markdown b/uncle-bob/_posts/2013-10-24-The-Careless-Ones.markdown index c984d4a..ea62d05 100644 --- a/uncle-bob/_posts/2013-10-24-The-Careless-Ones.markdown +++ b/uncle-bob/_posts/2013-10-24-The-Careless-Ones.markdown @@ -3,6 +3,7 @@ layout: post title: The Careless Ones tags: ["Craftsmanship"] --- + Two days ago my wife placed an on-line order at Walmart for a metal-frame bunk bed for our grandchildren to sleep on when they stay over at our house. Yesterday it arrived. Wow! One day delivery to my front door. Someone cared. The metal-frame parts for the bunk bed came in a box that was, perhaps, 4ft X 18in X 6in, or 3 cu ft. It weight about 100 lbs. I looked at this carton with a growing sense of despair, knowing that the next several hours of my life would be in the hell of unpacking and assembly. I've been in that hell before. I had no desire to return to it. But I love my grand children and I wanted them to have a nice place to sleep. So... diff --git a/uncle-bob/_posts/2013-11-12-Healthcare-gov.markdown b/uncle-bob/_posts/2013-11-12-Healthcare-gov.markdown index 1ba6e61..527387d 100644 --- a/uncle-bob/_posts/2013-11-12-Healthcare-gov.markdown +++ b/uncle-bob/_posts/2013-11-12-Healthcare-gov.markdown @@ -3,6 +3,7 @@ layout: post title: Healthcare.gov tags: ["Craftsmanship"] --- + This is not a political blog. This is a blog about the Software Industry; and the profound effect that its failure is having upon our society. The Software Industry failed to deliver `healthcare.gov`. As a result, millions of people are being hurt. _We_ did that, folks. It was _our_ industry, _our_ failure. diff --git a/uncle-bob/_posts/2013-11-19-HoardsOfNovices.markdown b/uncle-bob/_posts/2013-11-19-HoardsOfNovices.markdown index 5bf86ac..4a139f7 100644 --- a/uncle-bob/_posts/2013-11-19-HoardsOfNovices.markdown +++ b/uncle-bob/_posts/2013-11-19-HoardsOfNovices.markdown @@ -3,6 +3,7 @@ layout: post title: Hordes Of Novices tags: ["Craftsmanship"] --- + Is the software industry trying to write the script for Hamlet by hiring a million monkeys to bang on keyboards? Perhaps we should rethink that strategy and hire one bard instead. Perhaps, instead of hordes of novices, we need a small team of professionals. ## Demand. diff --git a/uncle-bob/_posts/2013-11-25-Novices-Coda.markdown b/uncle-bob/_posts/2013-11-25-Novices-Coda.markdown index 43efe75..0f5b3cd 100644 --- a/uncle-bob/_posts/2013-11-25-Novices-Coda.markdown +++ b/uncle-bob/_posts/2013-11-25-Novices-Coda.markdown @@ -3,6 +3,7 @@ layout: post title: Novices. A Coda tags: ["Craftsmanship"] --- + There has been some confusion about my recent post: [Hordes of Novices]({% post_url 2013-11-19-HoardsOfNovices %}). Many people who aspire to become craftsmen took the article to mean that I don't want new people to enter the craft. Nothing could be farther from the truth. We do, in fact, need a growing stream of newcomers entering our craft. Some folks who run code academies or boot camps took the article to mean that I didn't think those schools were useful. Again, nothing could be farther from the truth. We need a growing and effective supply of accessible software education. What we _don't_ need is to throw masses of newly trained novices into mission critical projects without careful supervision, monitoring, and continuing education. What we _don't_ need is to expect novices to behave like professionals. What we _don't_ need is to continue in the absurd belief that a degree in computer science, or the completion of a boot camp, is sufficient to produce a professional software developer. diff --git a/uncle-bob/_posts/2013-12-10-Thankyou-Kent.markdown b/uncle-bob/_posts/2013-12-10-Thankyou-Kent.markdown index 0b78c31..44b8b43 100644 --- a/uncle-bob/_posts/2013-12-10-Thankyou-Kent.markdown +++ b/uncle-bob/_posts/2013-12-10-Thankyou-Kent.markdown @@ -3,6 +3,7 @@ layout: post title: Extreme Programming, a Reflection tags: ["Craftsmanship"] --- + In my hand I am holding a little white book that, fourteen years ago, changed the software world forever. The title of that book is: _Extreme Programming Explained_; and the subtitle is: _Embrace Change_. The author is Kent Beck, and the copyright date is 1999. The book is small, less than 200 pages. The print is large and widely spaced. The writing style is casual and accessible. The chapters are short. The concepts are simple. diff --git a/uncle-bob/_posts/2014-01-20-Marion_Correctional.markdown b/uncle-bob/_posts/2014-01-20-Marion_Correctional.markdown index 6256384..33557f7 100644 --- a/uncle-bob/_posts/2014-01-20-Marion_Correctional.markdown +++ b/uncle-bob/_posts/2014-01-20-Marion_Correctional.markdown @@ -3,6 +3,7 @@ layout: post title: Coding in the Clink (9) tags: ["Community"] --- + My son, Micah `(@slagyr)`, and I had planned to fly his _Archer_ on Saturday morning; but the weather said "No.". So, we fell into the far-too-familiar routine of leaving the night before, airports, commercial flights, rental cars, and hotel beds. Sigh. In the morning the two of us drive to Marion Correctional Institution; a medium security prison run by the State of Ohio. We pull into the visitor's parking lot and call the organizer, Dan Wiebe `(@dnwiebe)`. He says he's already there waiting inside with several others. I ask whether I should leave my cell phone in the car. He says to leave _everything_ in the car except our driver's licenses and the car keys. We comply. diff --git a/uncle-bob/_posts/2014-01-27-TheChickenOrTheRoad.markdown b/uncle-bob/_posts/2014-01-27-TheChickenOrTheRoad.markdown index 630737a..bdeddc0 100644 --- a/uncle-bob/_posts/2014-01-27-TheChickenOrTheRoad.markdown +++ b/uncle-bob/_posts/2014-01-27-TheChickenOrTheRoad.markdown @@ -3,7 +3,7 @@ layout: post title: The Domain Discontinuity tags: ["Testing"] --- - + ## What came first, the chicken or the road? I read, with interest, Justin Searls' [Post #13](http://blog.testdouble.com/posts/2014-01-25-the-failures-of-intro-to-tdd.html). First I am going to express my deep disagreement with the Author. I will refute his arguments and utterly destroy his conclusions. And then, once I'm done salting the ground where he used to live, I'll tell you why I completely agree with him. diff --git a/uncle-bob/_posts/2014-02-21-WhereIsTheForeman.markdown b/uncle-bob/_posts/2014-02-21-WhereIsTheForeman.markdown index da6cc3f..4a3c843 100644 --- a/uncle-bob/_posts/2014-02-21-WhereIsTheForeman.markdown +++ b/uncle-bob/_posts/2014-02-21-WhereIsTheForeman.markdown @@ -3,6 +3,7 @@ layout: post title: Where is the Foreman? tags: ["Craftsmanship"] --- + The foreman on a construction site is the guy who is responsible for making sure all the workers do things right. He's the guy with the tape-measure that goes around making sure all the walls are placed properly. He's the guy who examines all the struts, joists, and beams to make sure they are installed correctly, and don't have any significant defects. He's the guy who counts the screws in the flooring to make sure it won't squeak when you walk on it. He's the guy -- the guy who takes responsibility -- the guy who makes sure everything is done _right_. Where is the foreman on our software projects? Where's the guy who makes sure all the tests are written. Where's the guy who makes sure that all the exceptions are caught. Where's the guy who makes sure all the errors are checked, and that references can't be null, and that variables are thread-safe? Where's the guy who makes sure that the programmers are pairing enough, talking enough, planning enough? Where's the guy who keeps the floors from squeaking? diff --git a/uncle-bob/_posts/2014-02-23-OhForemanWhereArtThou.markdown b/uncle-bob/_posts/2014-02-23-OhForemanWhereArtThou.markdown index 88b7625..84f92eb 100644 --- a/uncle-bob/_posts/2014-02-23-OhForemanWhereArtThou.markdown +++ b/uncle-bob/_posts/2014-02-23-OhForemanWhereArtThou.markdown @@ -3,6 +3,7 @@ layout: post title: "Oh Foreman, Where art Thou?" tags: ["Craftsmanship"] --- + The response to my previous blog: [Where's the Foreman]({% post_url 2014-02-21-WhereIsTheForeman %}) has been mixed. While the vast majority of folks seemed to agree; there was a vocal minority of people, whom I respect, who were quite negative. The thing that most of these people hated the most was my insistence that the foreman be the only person with commit rights. The complaints were all based on the notion of _team_ vs. _foreman_. Those who disagreed with my blog seem to feel that a software team is based on egalitarian rules, where all are peers, and none has authority over others. Nearly all of these people call themselves _coaches_; which is odd because, of all the roles in a team, the role of _coach_ is the _least_ egalitarian. The coach is _special_. diff --git a/uncle-bob/_posts/2014-02-27-TheTrustSpectrum.markdown b/uncle-bob/_posts/2014-02-27-TheTrustSpectrum.markdown index 30efa27..db669b3 100644 --- a/uncle-bob/_posts/2014-02-27-TheTrustSpectrum.markdown +++ b/uncle-bob/_posts/2014-02-27-TheTrustSpectrum.markdown @@ -3,6 +3,7 @@ layout: post title: "A Spectrum of Trust" tags: ["Craftsmanship"] --- + The response to my two previous blogs: [Where's the Foreman]({% post_url 2014-02-21-WhereIsTheForeman %}) and [Oh Foreman Where Art Thou]({% post_url 2014-02-23-OhForemanWhereArtThou %}) continues to be mixed; and has gotten quite loud. That's a good thing; because we need to have this discussion. ###The Perfect Agile Team diff --git a/uncle-bob/_posts/2014-03-11-when-to-think.markdown b/uncle-bob/_posts/2014-03-11-when-to-think.markdown index bbc299b..93144da 100644 --- a/uncle-bob/_posts/2014-03-11-when-to-think.markdown +++ b/uncle-bob/_posts/2014-03-11-when-to-think.markdown @@ -3,6 +3,7 @@ layout: post title: "When Should You Think?" tags: ["Craftsmanship"] --- + In the last few weeks there have been a spate of blogs, from various sources, that have suggested that TDD could be done better if people would just think before they code. These blogs have suggested that some people leap into code too quickly, and would be better served by thinking about the problem first. In some ways these blogs remind me of Rich Hickey's now famous talk on [Hammock Driven Developmen](https://gibbon.co/wunki/clojures-best-presentations/hammock-driven-development-rich-hickey); which I enthusiastically support. diff --git a/uncle-bob/_posts/2014-03-28-The-Corruption-of-Agile.markdown b/uncle-bob/_posts/2014-03-28-The-Corruption-of-Agile.markdown index 4ae51c5..084c1a4 100644 --- a/uncle-bob/_posts/2014-03-28-The-Corruption-of-Agile.markdown +++ b/uncle-bob/_posts/2014-03-28-The-Corruption-of-Agile.markdown @@ -3,6 +3,7 @@ layout: post title: "The True Corruption of Agile" tags: ["Craftsmanship"] --- + Andrew Binstock recently wrote a blog entitled [The Corruption of Agile](http://www.drdobbs.com/architecture-and-design/the-corruption-of-agile/240166698), which built upon another blog by Allen Holub entitled [The Agile Holocracy](http://www.drdobbs.com/architecture-and-design/the-agile-holocracy/240166629). Allow me to summarize: Holub says: diff --git a/uncle-bob/_posts/2014-04-03-Code-Hoarders.markdown b/uncle-bob/_posts/2014-04-03-Code-Hoarders.markdown index 56aedbf..e33ae65 100644 --- a/uncle-bob/_posts/2014-04-03-Code-Hoarders.markdown +++ b/uncle-bob/_posts/2014-04-03-Code-Hoarders.markdown @@ -3,6 +3,7 @@ layout: post title: "Code Hoarders" tags: ["Craftsmanship"] --- + Have you ever watched an episode of _Hoarders_, or a documentary about a hoarder? Shows like this were popular a few years back. They showcased the tragic, and all-too-common, phenomenon of people who have lost control over their living space by filling it with so much junk that there's no place for them to live. These people fill their homes so full of stuff that all they have left are dark and narrow passageways winding through floor to ceiling towers of junk, trash, old food, pet droppings, dirty laundry, and other less mentionable things. The volume of each room is taken up by junk. The counters, the tables, and the furniture are invisible, buried, beneath junk. The bedrooms and bathrooms are piled high. There is no room to move. No room to eat. No room to sleep. No room to live. There have been cases in which dead bodies have been found beneath the piles of rubbish and detritus. diff --git a/uncle-bob/_posts/2014-04-25-MonogamousTDD.markdown b/uncle-bob/_posts/2014-04-25-MonogamousTDD.markdown index 88f07d2..1289aba 100644 --- a/uncle-bob/_posts/2014-04-25-MonogamousTDD.markdown +++ b/uncle-bob/_posts/2014-04-25-MonogamousTDD.markdown @@ -3,6 +3,7 @@ layout: post title: "Monogamous TDD" tags: ["Craftsmanship"] --- + When a [blog](http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html) begins like this... >"Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming." diff --git a/uncle-bob/_posts/2014-04-30-When-tdd-does-not-work.markdown b/uncle-bob/_posts/2014-04-30-When-tdd-does-not-work.markdown index 539bc51..c19d46d 100644 --- a/uncle-bob/_posts/2014-04-30-When-tdd-does-not-work.markdown +++ b/uncle-bob/_posts/2014-04-30-When-tdd-does-not-work.markdown @@ -3,6 +3,7 @@ layout: post title: "When TDD doesn't work." tags: ["Craftsmanship"] --- + Over the years many people have complained about the so-called "religiosity" of some of the proponents of Test Driven Development. The [recent brouhaha]({% post_url 2014-04-25-MonogamousTDD %}) over TDD has, once again, brought these complaints to the fore. So I thought it would be a good idea to talk about when TDD does not work. I have often compared TDD to double-entry bookkeeping. The act of stating every bit of logic twice, once in a test, and once in the production code, is very similar to the accounting practice of entering every transaction twice, once on the asset side, and once on the liability side. The running of the tests is very similar to the creation of the balance sheet. If the balance of assets and liabilities isn't zero, somebody made a mistake somewhere. diff --git a/uncle-bob/_posts/2014-05-01-Design-Damage.markdown b/uncle-bob/_posts/2014-05-01-Design-Damage.markdown index 410b570..95b908c 100644 --- a/uncle-bob/_posts/2014-05-01-Design-Damage.markdown +++ b/uncle-bob/_posts/2014-05-01-Design-Damage.markdown @@ -3,6 +3,7 @@ layout: post title: "Test Induced Design Damage?" tags: ["Craftsmanship"] --- + I miss Jim Weirich. I miss his laugh. I miss his good nature. Most of all, I miss what he would have taught me next year, and in the years to follow. I _feel_ that loss. Last October Jim gave a talk named [Decoupling from Rails](https://www.youtube.com/watch?v=tg5RFeSfBM4) in which he showed how to refactor a rails app in order to decouple business logic from rails framework code. The talk is _spectacular_. The hour you spend watching it will pay you back many times over. diff --git a/uncle-bob/_posts/2014-05-02-ProfessionalismAndTDD.markdown b/uncle-bob/_posts/2014-05-02-ProfessionalismAndTDD.markdown index 7b861c5..7e141d1 100644 --- a/uncle-bob/_posts/2014-05-02-ProfessionalismAndTDD.markdown +++ b/uncle-bob/_posts/2014-05-02-ProfessionalismAndTDD.markdown @@ -3,6 +3,7 @@ layout: post title: "Professionalism and TDD (Reprise)" tags: ["Craftsmanship"] --- + Lately I have been criticized, both directly and indirectly, for associating TDD with professionalism. Indeed, I believe much of the recent "true believer" rhetoric we have been subjected to comes from that association. I plead guilty to claiming that the association exists. I wrote extensively about it in the article [Professionalism and Test-Driven-Development, IEEE Software, 06/2007](http://www.researchgate.net/publication/3248924_Professionalism_and_Test-Driven_Development) diff --git a/uncle-bob/_posts/2014-05-08-SingleReponsibilityPrinciple.markdown b/uncle-bob/_posts/2014-05-08-SingleReponsibilityPrinciple.markdown index b2a181d..5cdcc4b 100644 --- a/uncle-bob/_posts/2014-05-08-SingleReponsibilityPrinciple.markdown +++ b/uncle-bob/_posts/2014-05-08-SingleReponsibilityPrinciple.markdown @@ -3,6 +3,7 @@ layout: post title: "The Single Responsibility Principle" tags: ["Architecture"] --- + In 1972 David L. Parnas published a classic paper entitled [On the Criteria To Be Used in Decomposing Systems into Modules](https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf). It appeared in the December issue of the Communications of the ACM, Volume 15, Number 12. In this paper, Parnas compared two different strategies for decomposing and separating the logic in a simple algorithm. The paper is fascinating reading, and I strongly urge you to study it. His conclusion, in part, is as follows: diff --git a/uncle-bob/_posts/2014-05-10-WhenToMock.markdown b/uncle-bob/_posts/2014-05-10-WhenToMock.markdown index 0106db1..94d9942 100644 --- a/uncle-bob/_posts/2014-05-10-WhenToMock.markdown +++ b/uncle-bob/_posts/2014-05-10-WhenToMock.markdown @@ -3,6 +3,7 @@ layout: post title: "When to Mock" tags: ["Testing"] --- + A mock object is a very powerful tool, providing two major benefits: isolation and introspection. But like all power tools, mocks come with a cost. So where and when should you use them? What is the cost/benefit trade off? Let's look at the extremes. ##No Mocks. diff --git a/uncle-bob/_posts/2014-05-11-FrameworkBound.markdown b/uncle-bob/_posts/2014-05-11-FrameworkBound.markdown index fcf3452..1c0602a 100644 --- a/uncle-bob/_posts/2014-05-11-FrameworkBound.markdown +++ b/uncle-bob/_posts/2014-05-11-FrameworkBound.markdown @@ -3,6 +3,7 @@ layout: post title: "Framework Bound[2]" tags: ["Craftsmanship"] --- + Frameworks are powerful tools. We'd be lost without them. But there's a cost to using them. Think of Rails, or Spring, or JSF, or Hibernate. Think about what writing a web system would be like without these frameworks to help you. The idea is disheartening. There'd be so many little piddling details to deal with. It'd be like endeavoring to construct a mnemonic memory circuit using stone knives and bearskins[1]. diff --git a/uncle-bob/_posts/2014-05-12-TheOpenClosedPrinciple.markdown b/uncle-bob/_posts/2014-05-12-TheOpenClosedPrinciple.markdown index c967404..b21ac29 100644 --- a/uncle-bob/_posts/2014-05-12-TheOpenClosedPrinciple.markdown +++ b/uncle-bob/_posts/2014-05-12-TheOpenClosedPrinciple.markdown @@ -3,6 +3,7 @@ layout: post title: "The Open Closed Principle" tags: ["Craftsmanship"] --- + In 1988 Bertrand Meyer defined one of the most important principles of software engineering. The Open Closed Principle (OCP). In his book [Object Oriented Software Construction](http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136290493)[1] he said: >A satisfactory modular decomposition technique must satisfy one more requirement: It should yield modules that are _both_ open and closed. diff --git a/uncle-bob/_posts/2014-05-14-TheLittleMocker.markdown b/uncle-bob/_posts/2014-05-14-TheLittleMocker.markdown index 5d14a65..9affa63 100644 --- a/uncle-bob/_posts/2014-05-14-TheLittleMocker.markdown +++ b/uncle-bob/_posts/2014-05-14-TheLittleMocker.markdown @@ -3,6 +3,7 @@ layout: post title: "The Little Mocker" tags: ["Testing"] --- + The following is a conversation around mocking: What is this?: diff --git a/uncle-bob/_posts/2014-05-19-First.markdown b/uncle-bob/_posts/2014-05-19-First.markdown index 65ba7a7..172d24f 100644 --- a/uncle-bob/_posts/2014-05-19-First.markdown +++ b/uncle-bob/_posts/2014-05-19-First.markdown @@ -3,6 +3,7 @@ layout: post title: "First" tags: ["Testing"] --- + In the first [_Is TDD Dead?_ hangout](https://www.youtube.com/watch?v=z9quxZsLcfo), at time 30:25 `@dhh` makes a remarkable statement: >"...you're not done until you also have tests for a piece of functionality -- I'm completely on board with that."