Permalink
Browse files

redirect 8th Light blogs

  • Loading branch information...
1 parent 8f7469c commit 45bed34e80ca901f409ce803d50cb7911b206111 @unclebob committed Jun 20, 2014
Showing with 58 additions and 11 deletions.
  1. +2 −0 uncle-bob/_posts/2011-11-22-Clean-Architecture.textile
  2. +2 −0 uncle-bob/_posts/2011-12-11-The-Barbarians-are-at-the-Gates.textile
  3. +1 −0 uncle-bob/_posts/2012-01-11-Flipping-the-Bit.textile
  4. +1 −0 uncle-bob/_posts/2012-01-12-The-Letter.textile
  5. +1 −0 uncle-bob/_posts/2012-01-20-Fecophiles.textile
  6. +1 −1 uncle-bob/_posts/2012-01-31-The-Ruby-Colored-Box.textile
  7. +1 −1 uncle-bob/_posts/2012-02-01-Service-Oriented-Agony.textile
  8. +1 −1 uncle-bob/_posts/2012-04-18-After-The-Disaster.textile
  9. +1 −0 uncle-bob/_posts/2012-04-20-Why-Is-Estimating-So-Hard.textile
  10. +1 −0 uncle-bob/_posts/2012-05-15-NODB.textile
  11. +1 −0 uncle-bob/_posts/2012-08-13-the-clean-architecture.textile
  12. +1 −0 uncle-bob/_posts/2012-08-24-functional-programming-for-the-object-oriented-programmer.textile
  13. +1 −0 uncle-bob/_posts/2012-09-06-I-am-Your-New-CTO.textile
  14. +1 −1 uncle-bob/_posts/2012-12-19-Three-Paradigms.textile
  15. +1 −1 uncle-bob/_posts/2012-12-22-FPBE1-Whats-it-all-about.textile
  16. +1 −0 uncle-bob/_posts/2012-12-29-Brave-New-Year.textile
  17. +1 −1 uncle-bob/_posts/2013-01-02-FPBE2-Whys-it-called-functional.textile
  18. +1 −1 uncle-bob/_posts/2013-01-07-FPBE3-Do-the-rules-change.textile
  19. +1 −1 uncle-bob/_posts/2013-01-29-FPBE4-Lazy-Evaluation.markdown
  20. +1 −0 uncle-bob/_posts/2013-01-30-The-Craftsman-And-The-Laborer.markdown
  21. +1 −0 uncle-bob/_posts/2013-02-01-The-Humble-Craftsman.markdown
  22. +1 −0 uncle-bob/_posts/2013-02-10-ThePrinciplesOfCraftsmanship.markdown
  23. +1 −0 uncle-bob/_posts/2013-03-05-TheStartUpTrap.markdown
  24. +1 −0 uncle-bob/_posts/2013-03-06-ThePragmaticsOfTDD.markdown
  25. +1 −0 uncle-bob/_posts/2013-03-08-AnOpenAndClosedCase.markdown
  26. +1 −0 uncle-bob/_posts/2013-03-11-TheFrenziedPanicOfRushing.markdown
  27. +1 −1 uncle-bob/_posts/2013-05-27-FibTPP.html
  28. +1 −1 uncle-bob/_posts/2013-05-27-FlashTpp.html
  29. +1 −0 uncle-bob/_posts/2013-05-27-TheTransformationPriorityPremise.html
  30. +1 −0 uncle-bob/_posts/2013-05-27-TransformationPriorityAndSorting.html
  31. +1 −0 uncle-bob/_posts/2013-09-23-Test-first.markdown
  32. +1 −0 uncle-bob/_posts/2013-09-26-AT-FAIL.markdown
  33. +1 −0 uncle-bob/_posts/2013-10-01-Dance-You-Imps.markdown
  34. +1 −0 uncle-bob/_posts/2013-10-24-The-Careless-Ones.markdown
  35. +1 −0 uncle-bob/_posts/2013-11-12-Healthcare-gov.markdown
  36. +1 −0 uncle-bob/_posts/2013-11-19-HoardsOfNovices.markdown
  37. +1 −0 uncle-bob/_posts/2013-11-25-Novices-Coda.markdown
  38. +1 −0 uncle-bob/_posts/2013-12-10-Thankyou-Kent.markdown
  39. +1 −0 uncle-bob/_posts/2014-01-20-Marion_Correctional.markdown
  40. +1 −1 uncle-bob/_posts/2014-01-27-TheChickenOrTheRoad.markdown
  41. +1 −0 uncle-bob/_posts/2014-02-21-WhereIsTheForeman.markdown
  42. +1 −0 uncle-bob/_posts/2014-02-23-OhForemanWhereArtThou.markdown
  43. +1 −0 uncle-bob/_posts/2014-02-27-TheTrustSpectrum.markdown
  44. +1 −0 uncle-bob/_posts/2014-03-11-when-to-think.markdown
  45. +1 −0 uncle-bob/_posts/2014-03-28-The-Corruption-of-Agile.markdown
  46. +1 −0 uncle-bob/_posts/2014-04-03-Code-Hoarders.markdown
  47. +1 −0 uncle-bob/_posts/2014-04-25-MonogamousTDD.markdown
  48. +1 −0 uncle-bob/_posts/2014-04-30-When-tdd-does-not-work.markdown
  49. +1 −0 uncle-bob/_posts/2014-05-01-Design-Damage.markdown
  50. +1 −0 uncle-bob/_posts/2014-05-02-ProfessionalismAndTDD.markdown
  51. +1 −0 uncle-bob/_posts/2014-05-08-SingleReponsibilityPrinciple.markdown
  52. +1 −0 uncle-bob/_posts/2014-05-10-WhenToMock.markdown
  53. +1 −0 uncle-bob/_posts/2014-05-11-FrameworkBound.markdown
  54. +1 −0 uncle-bob/_posts/2014-05-12-TheOpenClosedPrinciple.markdown
  55. +1 −0 uncle-bob/_posts/2014-05-14-TheLittleMocker.markdown
  56. +1 −0 uncle-bob/_posts/2014-05-19-First.markdown
View
2 uncle-bob/_posts/2011-11-22-Clean-Architecture.textile
@@ -3,6 +3,8 @@ layout: post
title: Clean Architecture
tags: ["Architecture"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2011/11/22/Clean-Architecture.html" />
+
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.
View
2 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"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2011/12/11/The-Barbarians-are-at-the-Gates.html" />
+
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:
View
1 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"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/01/11/Flipping-the-Bit.html" />
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.
View
1 uncle-bob/_posts/2012-01-12-The-Letter.textile
@@ -4,6 +4,7 @@ title: The Letter
tags: ["Testing", "Craftsmanship"]
old_tags: ["TDD", "Professionalism", "Craftsmanship"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/01/12/The-Letter.html" />
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.
View
1 uncle-bob/_posts/2012-01-20-Fecophiles.textile
@@ -4,6 +4,7 @@ title: Fecophiles
tags: ["Craftsmanship"]
old_tags: ["Professionalism", "Craftsmanship", "Clean Code"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/01/20/Fecophiles.html" />
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 :-)
View
2 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"]
---
-
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/01/31/The-Ruby-Colored-Box.html" />
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.
View
2 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"]
---
-
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/02/01/Service-Oriented-Agony.html" />
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.
View
2 uncle-bob/_posts/2012-04-18-After-The-Disaster.textile
@@ -4,7 +4,7 @@ title: After the Disaster
tags: ["Craftsmanship"]
old_tags: ["Professionalism", "Craftsmanship"]
---
-
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/04/18/After-The-Disaster.html" />
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?
View
1 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"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/04/20/Why-Is-Estimating-So-Hard.html" />
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..."
View
1 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"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/05/15/NODB.html" />
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.
View
1 uncle-bob/_posts/2012-08-13-the-clean-architecture.textile
@@ -3,6 +3,7 @@ layout: post
title: The Clean Architecture
tags: ["Architecture", "Craftsmanship"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html" />
<img width="100%" src="/uncle-bob/images/2012-08-13-the-clean-architecture/CleanArchitecture.jpg"/>
Over the last several years we've seen a whole range of ideas regarding the architecture of systems. These include:
View
1 ...e-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"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/08/24/functional-programming-for-the-object-oriented-programmer.html" />
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.
View
1 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"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/09/06/I-am-Your-New-CTO.html" />
"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."
View
2 uncle-bob/_posts/2012-12-19-Three-Paradigms.textile
@@ -4,7 +4,7 @@ title: Three Paradigms
tags: ["Tools"]
old_tags: ["Functional Programming"]
---
-
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/12/19/Three-Paradigms.html" />
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.
View
2 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"]
---
-
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/12/22/FPBE1-Whats-it-all-about.html" />
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.
View
1 uncle-bob/_posts/2012-12-29-Brave-New-Year.textile
@@ -4,6 +4,7 @@ title: Brave New Year
tags: ["Community"]
old_tags: ["Prognostication"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2012/12/29/Brave-New-Year.html" />
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.
View
2 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"]
---
-
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/01/02/FPBE2-Whys-it-called-functional.html" />
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.
View
2 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"]
---
-
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/01/07/FPBE3-Do-the-rules-change.html" />
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?
View
2 uncle-bob/_posts/2013-01-29-FPBE4-Lazy-Evaluation.markdown
@@ -4,7 +4,7 @@ title: FP Basics E4
tags: ["Tools"]
old_tags: ["Functional Programming"]
---
-
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/01/29/FPBE4-Lazy-Evaluation.html" />
#### Lazy Evaluation
Remember my squares of integers program in clojure?
View
1 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"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/01/30/The-Craftsman-And-The-Laborer.html" />
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....
View
1 uncle-bob/_posts/2013-02-01-The-Humble-Craftsman.markdown
@@ -3,6 +3,7 @@ layout: post
title: The Humble Craftsman
tags: ["Craftsmanship"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/02/01/The-Humble-Craftsman.html" />
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.
View
1 uncle-bob/_posts/2013-02-10-ThePrinciplesOfCraftsmanship.markdown
@@ -3,6 +3,7 @@ layout: post
title: The Principles of Craftsmanship
tags: ["Craftsmanship"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/02/10/ThePrinciplesOfCraftsmanship.html" />
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.
View
1 uncle-bob/_posts/2013-03-05-TheStartUpTrap.markdown
@@ -3,6 +3,7 @@ layout: post
title: The Start-Up Trap
tags: ["Craftsmanship", "Testing"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/03/05/TheStartUpTrap.html" />
* **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.
View
1 uncle-bob/_posts/2013-03-06-ThePragmaticsOfTDD.markdown
@@ -3,6 +3,7 @@ layout: post
title: The Pragmatics of TDD
tags: ["Craftsmanship", "Testing"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/03/06/ThePragmaticsOfTDD.html" />
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.
View
1 uncle-bob/_posts/2013-03-08-AnOpenAndClosedCase.markdown
@@ -3,6 +3,7 @@ layout: post
title: An Open and Closed Case
tags: ["Craftsmanship", "Coding"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/03/08/AnOpenAndClosedCase.html" />
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?"
View
1 uncle-bob/_posts/2013-03-11-TheFrenziedPanicOfRushing.markdown
@@ -3,6 +3,7 @@ layout: post
title: The Frenzied Panic of Rushing
tags: ["Craftsmanship", "Testing"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/03/11/TheFrenziedPanicOfRushing.html" />
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".
View
2 uncle-bob/_posts/2013-05-27-FibTPP.html
@@ -3,7 +3,7 @@
title: Fib. The T-P Premise.
tags: ["Coding"]
---
-
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/05/27/FibTPP.html" />
<div id='wrap'>
<div class='post'>
<div class='post_header'>
View
2 uncle-bob/_posts/2013-05-27-FlashTpp.html
@@ -4,7 +4,7 @@
tags: ["Coding"]
---
-
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/05/27/FlashTpp.html" />
<div class='post'>
<div class='post_header'>
View
1 uncle-bob/_posts/2013-05-27-TheTransformationPriorityPremise.html
@@ -3,6 +3,7 @@
title: The Transformation Priority Premise
tags: ["Coding"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/05/27/TheTransformationPriorityPremise.html" />
<div class='post'>
<div class='post_header'>
<div class='post_info'>
View
1 uncle-bob/_posts/2013-05-27-TransformationPriorityAndSorting.html
@@ -3,6 +3,7 @@
title: Transformation Priority and Sorting
tags: ["Coding"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/05/27/TransformationPriorityAndSorting.html" />
<div><span class='post_time'>January 1 2011</span></div>
<div>
In this post we explore the <a href="{% post_url 2013-05-27-TheTransformationPriorityPremise %}">Transformation Priority Premise</a> in the context of building a sort algorithm.
View
1 uncle-bob/_posts/2013-09-23-Test-first.markdown
@@ -3,6 +3,7 @@ layout: post
title: Test First
tags: ["Craftsmanship", "Coding", "Testing"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/09/23/Test-first.html" />
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.
View
1 uncle-bob/_posts/2013-09-26-AT-FAIL.markdown
@@ -3,6 +3,7 @@ layout: post
title: A.T. FAIL!
tags: ["Testing"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/09/26/AT-FAIL.html" />
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:
View
1 uncle-bob/_posts/2013-10-01-Dance-You-Imps.markdown
@@ -3,6 +3,7 @@ layout: post
title: Dance you Imps!
tags: ["Tools"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/10/01/Dance-You-Imps.html" />
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
View
1 uncle-bob/_posts/2013-10-24-The-Careless-Ones.markdown
@@ -3,6 +3,7 @@ layout: post
title: The Careless Ones
tags: ["Craftsmanship"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/10/24/The-Careless-Ones.html" />
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...
View
1 uncle-bob/_posts/2013-11-12-Healthcare-gov.markdown
@@ -3,6 +3,7 @@ layout: post
title: Healthcare.gov
tags: ["Craftsmanship"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/11/12/Healthcare-gov.html" />
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.
View
1 uncle-bob/_posts/2013-11-19-HoardsOfNovices.markdown
@@ -3,6 +3,7 @@ layout: post
title: Hordes Of Novices
tags: ["Craftsmanship"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/11/19/HoardsOfNovices.html" />
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.
View
1 uncle-bob/_posts/2013-11-25-Novices-Coda.markdown
@@ -3,6 +3,7 @@ layout: post
title: Novices. A Coda
tags: ["Craftsmanship"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/11/25/Novices-Coda.html" />
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.
View
1 uncle-bob/_posts/2013-12-10-Thankyou-Kent.markdown
@@ -3,6 +3,7 @@ layout: post
title: Extreme Programming, a Reflection
tags: ["Craftsmanship"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2013/12/10/Thankyou-Kent.html" />
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.
View
1 uncle-bob/_posts/2014-01-20-Marion_Correctional.markdown
@@ -3,6 +3,7 @@ layout: post
title: Coding in the Clink (9)
tags: ["Community"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2014/01/20/Marion_Correctional.html" />
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.
View
2 uncle-bob/_posts/2014-01-27-TheChickenOrTheRoad.markdown
@@ -3,7 +3,7 @@ layout: post
title: The Domain Discontinuity
tags: ["Testing"]
---
-
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2014/01/27/TheChickenOrTheRoad.html" />
## 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.
View
1 uncle-bob/_posts/2014-02-21-WhereIsTheForeman.markdown
@@ -3,6 +3,7 @@ layout: post
title: Where is the Foreman?
tags: ["Craftsmanship"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2014/02/21/WhereIsTheForeman.html" />
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?
View
1 uncle-bob/_posts/2014-02-23-OhForemanWhereArtThou.markdown
@@ -3,6 +3,7 @@ layout: post
title: "Oh Foreman, Where art Thou?"
tags: ["Craftsmanship"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2014/02/23/OhForemanWhereArtThou.html" />
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_.
View
1 uncle-bob/_posts/2014-02-27-TheTrustSpectrum.markdown
@@ -3,6 +3,7 @@ layout: post
title: "A Spectrum of Trust"
tags: ["Craftsmanship"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2014/02/27/TheTrustSpectrum.html" />
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
View
1 uncle-bob/_posts/2014-03-11-when-to-think.markdown
@@ -3,6 +3,7 @@ layout: post
title: "When Should You Think?"
tags: ["Craftsmanship"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2014/03/11/when-to-think.html" />
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.
View
1 uncle-bob/_posts/2014-03-28-The-Corruption-of-Agile.markdown
@@ -3,6 +3,7 @@ layout: post
title: "The <i>True</i> Corruption of Agile"
tags: ["Craftsmanship"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2014/03/28/The-Corruption-of-Agile.html" />
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:
View
1 uncle-bob/_posts/2014-04-03-Code-Hoarders.markdown
@@ -3,6 +3,7 @@ layout: post
title: "Code Hoarders"
tags: ["Craftsmanship"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2014/04/03/Code-Hoarders.html" />
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.
View
1 uncle-bob/_posts/2014-04-25-MonogamousTDD.markdown
@@ -3,6 +3,7 @@ layout: post
title: "Monogamous TDD"
tags: ["Craftsmanship"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2014/04/25/MonogamousTDD.html" />
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."
View
1 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"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2014/04/30/When-tdd-does-not-work.html" />
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.
View
1 uncle-bob/_posts/2014-05-01-Design-Damage.markdown
@@ -3,6 +3,7 @@ layout: post
title: "Test Induced Design Damage?"
tags: ["Craftsmanship"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2014/05/01/Design-Damage.html" />
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.
View
1 uncle-bob/_posts/2014-05-02-ProfessionalismAndTDD.markdown
@@ -3,6 +3,7 @@ layout: post
title: "Professionalism and TDD (Reprise)"
tags: ["Craftsmanship"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2014/05/02/ProfessionalismAndTDD.html" />
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)
View
1 uncle-bob/_posts/2014-05-08-SingleReponsibilityPrinciple.markdown
@@ -3,6 +3,7 @@ layout: post
title: "The Single Responsibility Principle"
tags: ["Architecture"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html" />
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:
View
1 uncle-bob/_posts/2014-05-10-WhenToMock.markdown
@@ -3,6 +3,7 @@ layout: post
title: "When to Mock"
tags: ["Testing"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2014/05/10/WhenToMock.html" />
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.
View
1 uncle-bob/_posts/2014-05-11-FrameworkBound.markdown
@@ -3,6 +3,7 @@ layout: post
title: "Framework Bound[2]"
tags: ["Craftsmanship"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2014/05/11/FrameworkBound.html" />
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].
View
1 uncle-bob/_posts/2014-05-12-TheOpenClosedPrinciple.markdown
@@ -3,6 +3,7 @@ layout: post
title: "The Open Closed Principle"
tags: ["Craftsmanship"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2014/05/12/TheOpenClosedPrinciple.html" />
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.
View
1 uncle-bob/_posts/2014-05-14-TheLittleMocker.markdown
@@ -3,6 +3,7 @@ layout: post
title: "The Little Mocker"
tags: ["Testing"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2014/05/14/TheLittleMocker.html" />
The following is a conversation around mocking:
What is this?:
View
1 uncle-bob/_posts/2014-05-19-First.markdown
@@ -3,6 +3,7 @@ layout: post
title: "First"
tags: ["Testing"]
---
+<meta http-equiv="refresh" content="0; url=http://blog.8thlight.com/uncle-bob/2014/05/19/First.html" />
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."

0 comments on commit 45bed34

Please sign in to comment.