Need we always write clean code?

On twitter, Naresh said this (among other things):

Clearly most startups dont value clean code & basic development hygiene, when they start off. Should they? IMHO it should not be their focus

Ron Jeffries, in addition to his tweets, linked to this blog post, which said lots of cool stuff, including this:

Clean code skills, from the very simplest to the most complex, do not take much time, and therefore pay off very soon.

So that I’m not talking about people here, Imma call Naresh’s approach “Quick & Dirty”, and Ron’s “Clean Code”.

Which brings me to just what I was wondering. Is Clean Code a bunch of difficult contortions that a seasoned developer would rather shed? Is it a burden, a necessary evil, kind of like the ropes and stuff that a climber wears? Someone could say “Look, if I need to climb fast, right now. I might choose not to suit up.” You might agree or disagree with the trade-off, but at least it makes sense. At least you could see how it might be faster. You can imagine a movie scene where the hero takes off and climbs really fast, with no gear, to save the boy.

Or is CC more like skill? Because to me, the Quick & Dirty approach seems like telling a gymnast that when it’s just a local demo, she should not worry so much about her posture on the balance beam, or sticking her dismount. She doesn’t actually know how to do an ugly dismount. Or, maybe she knows how, but it would take more work than doing the kind she’s good at. And neglecting posture, if she could, could result in a fall.

Can a CC-skilled and seasoned developer write QD code? As I’ve been approaching it, my intention is to develop my skill in coding, so that I can write code that takes the form that my skill produces.

Maybe I’m missing something. Maybe he just means “Write decent code, but spend less time refactoring. You can do that later.” Is that what he means?

Or does the Quick & Dirty camp mean that the practices they use to create Clean Code are a burden, and they work better without them?

Geeps sez…

The largest single term in the formula calculating how much your team will produce today is simple as this: the internal quality of the code they wrote yesterday. Only noobs can trade (internal) quality for faster performance.

(I just want to point out that the brevity of this answer is a new personal best for me.)

45 thoughts on “Need we always write clean code?

  1. nuttycom

    I think your analogy of the gymnast is spot-on; I like to think of myself as a CC freak, and personally find it really difficult to write QD code. Some days this feels like a disadvantage; it’s like I’m seeing potential errors everywhere that I psychologically cannot bring myself to ignore even when I perhaps should. But then again, each time I try to ignore the warning bells, I have to go back the next week and rewrite things to assuage my worries anyway because they’re rarely unfounded. For me, quick and dirty ends up being slow.

    Software is really expensive to produce, and even more expensive to maintain if it was produced quickly simply because the Q&D approach usually means higher code volume and fewer explicitly stated assumptions (and verifications that those assumptions hold.) Successful software systems also last a long time because the data that they manage has value to the business, so maintenance costs dominate.

    Something else: if time to market is the single most important consideration, you’re probably going to lose to the competition even if you make it out the gate first because your idea is so simple that it’s easily copied.

    Reply
    1. Angela Post author

      Thanks, nuttycom. I wished I’d used this analogy instead: Sure, we’ll hire you to sing at our wedding. But we don’t have much money, so none of that diaphram-breathing you people do. Trying to sing without breath sounds a lot like trying to write muddy code, to me.

      Oh, and I have had that same experience with warning bells. When I talk myself into ignoring them, I’m nearly always sorry.

      Reply
  2. David

    I’ve never found QD to be very productive for very long. Even the throwaway project often ends up living longer than expected.

    The only real disadvantage that I’ve found to getting good at CC and poor at QD is that I tend to do poorly in time-pressure programming contests. These emphasize early results and aren’t concerned with any aspect beyond the deadline. This, however, is not how most of the world works.

    Beyond the timeframe of a few hours, I’ve always found writing clean code to be a net win.

    Reply
    1. Angela Post author

      Thanks for the input, David. I know that during my apprenticeship thus far, I discovered that I work faster when I go slower. (I’m told everyone else already knew that, but it was a fresh discovery for me.) Or as my dad says, “We don’t have time to hurry.” It might work over a few minutes, but before long, the hurrying catches up with you.

      Reply
  3. Michael "Doc" Norton

    In discussions with Naresh, I’ve tried to understand his perspective on QD versus CC. There is some logic to his thinking, but I have to admit it is contrary to my experience and current set of beliefs about what makes for a good coder.

    Imagine you work in a place where the economic model is such that you are going to throw away the entire application every couple of years and start over. Perhaps the theory is that within that time-frame, technology, skill, and market opportunity will advance or change sufficiently enough that it is more cost effective to simply write it again.

    Imagine that you and your teammates are highly experienced developers who understand abstractions and composition. Developers who tend toward loose coupling, high cohesion, and DRY code.

    Is it possible that under these specific circumstances, this company could benefit from a highly relaxed set of standards?

    When we consider these questions, we often evaluate in the context of our own environment and our own experiences. Most of us work places where the code never dies. It is assigned a dedicated team of caretakers, given an occasional dose of steroids, round after round of plastic surgery, and kept monstrously alive long after we should have shown it some respect and put it down. In our environments, CC is clearly the best approach and often one we wished we had followed sooner.

    But maybe there are companies and economic circumstances where QD does make sense? I’ve never seen such an environment. But there are plenty of other things I have never seen that I do believe are possible….

    Reply
    1. Angela Post author

      Hi, Doc. :) Yeah… I’m guessing those experienced programmers would be delivering something that looks a lot like clean code, though. I am curious what things it’d make sense to give up. I want to stay open-minded, but test-coverage is my favorite thing about this new-fangled programming y’all are teaching me. If I were going to be stranded in 1990, and could only take one thing, it would be unit tests.

      Reply
  4. Ron Jeffries

    As the current pusher of CC, I guess my position is fairly clear but let me try again here: I believe that it is simply false that someone skilled in CC can go faster, over a period of even weeks, by reducing quality. Over that period, changes become hard enough, and enough defects creep in, so that they will go slower by trying to go fast.

    Naturally, if the code doesn’t have to work, we can go faster. In fact, we’re done now.

    Hmm, that’s good. I think I’ll tweet that. Thanks!

    Reply
  5. Lisa Crispin

    This may be neither here nor there but I’ll throw in my experience with my current team.

    Back in 2003 – 2004 when we first started trying to do TDD, refactoring & other clean code practices, we worked really hard to do it. Our goal was best possible quality, and biz people understood the long-term payoff.

    We did get the long-term payoff, but the code we wrote back then is generally awful, hard to change, and needs to be rewritten (though it is supported with automated tests at multiple levels).

    So, while we were attempting to be clean coders, the code we wrote might not reflect that. However, we can now rewrite it with low risk, because we do have the regression tests to make sure we don’t break it. I’m so glad we didn’t try to do QD.

    Reply
    1. Angela Post author

      Yeah, tests are pretty sweet. :) So, huh. If your team had decided on quick & dirty, how bad *would* it have been?

      Reply
  6. fqqdk

    Adding two if’s and three more static method calls to two hundred line methods in three 5kloc classes to “implement a feature” and be “done” will always be preferable to the “business” or “management” than sprouting a method, eliminating duplication, and those other funny things. After all those methods are not “your” code, you haven’t put those classes there. You might break em! And even if you don’t break it at the moment the other team working on another branch will surely somehow manage to not add the new classes you just extracted from that mess when they merge, and two weeks from now a senior developer will write a message at 2 AM in the morning telling people that they should send an email (preferably in advance) about “refactor”-s like this (link to your commit in the fisheye or sg), because they just pushed that code to production and all the graphs went down and the site stopped and it took two to five hours to “debug and rollback”.
    And yes, you may have written the tests that test your new shiny code, but since you don’t have the skill or time or whatever it takes to test every single code path of all the clients, and even if you could you can’t get the other team to run your tests, what have you accomplished? You broke the system. Do it again, and you’re fired.

    Reply
    1. Francesco Degrassi

      You broke the system

      I remember DeMarco talking about this attitude as Dilbert’s syndrome, succumbing to evil and adapting to it.
      CC does pay off soon, if management is unable to see it, it is our most important duty to make them see it, even if it is not pleasant or funny.
      If that turns out to be impossible, then getting fired from a place like that should be seen as a good thing.
      And, if you can prove that QD is in fact better ( in terms of TCO, employee retention, TTM and any other measure that is appropriate for your company), then you SHOULD do it quick and dirty, because that is our job.
      Good luck with that, though; years of experience from many experts in the field tell otherwise.

      Reply
      1. Angela Post author

        That actually raised a question for me, Francesco. If QD is better, shouldn’t we be able to demonstrate that, rather than just passing opinions back and forth? I hadn’t realized before, but I don’t think I’ve seen a real argument in favor of it.

        Reply
  7. Philip Schwarz

    The following tweets made me think of Martin Fowler’s notion of the design payoff line :

    RonJeffries: @marick is there any credible evidence at all that dirty (but working) code is faster to produce over any finite interval?

    jamesshore: @RonJeffries I certainly find non-TDD’d code faster to produce than TDD’d when I’m learning new technology.

    RonJeffries: @jamesshore yes, but for how long is that sustainable when really building something that has to work. I.e. For a first product?

    RonJeffries: @MatthewPCooke @joshuakerievsky yes. I’m talking about a period long enough to get a startup product out. Or even a week.

    jamesshore: @RonJeffries You have to bite the bullet sometime. My gut feel is that TDD pays off on products with life > 4-6 wks.

    RonJeffries: @jamesshore yes, i would support that. i can feel the difference before 4 weeks. sometimes before 4 hours

    In the Design Stamina Hypothesis, Martin Fowler says:

    “If the functionality for your initial release is below the design payoff line, then it may be worth trading off design quality for speed; but if it’s above the line then the trade-off is illusory. When your delivery is above the design payoff line neglecting design always makes you ship later. In technical debt terms it’s like taking out a loan but not using the principal for so long that by the time you use it you’ve paid out more in interest payments.”

    he also says:

    “taking out a Technical Debt is only worth doing up to a certain point. Not just do we have to consider whether delivered value is greater than the interest payments, we also have to judge whether the delivery is above the payoff line in the first place.”

    Reply
      1. Philip Schwarz

        You are welcome. The words “The Design Stamina Hypothesis” in my original reply are a hyperlink to a blog post by Fowler.

        Reply
  8. Shmoo

    If you want to paint a house, you use a ladder so that you can reach the higher parts. But the ladder is the point of painting: it’s the painting itself. It doesn’t matter how much you improve the ladder, or how much your ladder is better than someone else’s ladder: what matters is the painting.

    In this analogy, painting is coding and the ladder is TDD.

    Uncle Bob Tweeted recently somethink like, “Don’t you wish that all software that handles your money transactions was written using TDD?”

    No, UncleBob, I don’t. I don’t care how it was written as long as it’s reliable. When I book a painter to paint my house, I don’t care whether he uses a ladder, scaffolding or stilts: I just want a good paint job.

    This is the very real and understated problem with TDD: TDD is a process and too much attention on process blinds people to the fundamentals of good software writing.

    I gurarantee that, in five years time, there’ll be a lot of egg on people’s faces when TDD has been relegated to the rubbish bin of history and people have once again turn to software fundamentals for our improvements.

    TDD is the CMM of the 90s.

    TDD will be forgotten.

    Bring it on.

    Reply
    1. Angela Post author

      Schmoo, I guess you’re saying that you want people to be open to lots of strategies for creating reliable software. Yes?

      The folks I hear recommending TDD are mostly folks who, I sense, would love to talk about another method for getting reliability. I wonder what makes you think they wouldn’t?

      In our house, we have a tradition. Instead of saying “no” and blocking things, we try to say a “yes” instead. That is, “Well, I don’t feel much like playing frisbee, but a Sunday afternoon together sounds fun. Who’s up for the zoo instead?”

      What I have been hearing on the QD side is a big “no” without much “yes” to go with it. I haven’t heard QD recommending other paths to reliable software, as much as just discounting the desire for reliable software.

      Does that match your experience?

      Reply
    1. Jiri Lundak

      I second that it is about what gets delivered, not what the means are by which the work is done.

      But, to use your metaphor of the ladder: I prefer a ladder over just jumping around to paint the spots high on the wall.

      Most software developers still jump around delivering software the ‘quick&dirty’ way. Most of the time they leave a mess for the poor guys following them.

      Reply
      1. Angela Post author

        I prefer a ladder over just jumping around…

        Me too. And now I’m getting curious what sorts of things might provide an effective replacement for TDD (that is, scaffolding rather than jumping around). Has anybody come up with an alternative that works? Hmmm…

        Reply
  9. Angela Post author

    @geepawhill You are right. That is an amazingly concise answer. I bet it’s right. I wanna ask you why that’s so, but I think in the absence of a real argument to the contrary, it’s just not an interesting question.

    Reply
  10. Shmoo

    Hi, Angela,

    “Schmoo, I guess you’re saying that you want people to be open to lots of strategies for creating reliable software. Yes?”

    Well, yes I would, but I think that the path to better software is through concentrating on the fundamentals of software rather than on the process used to make the software. I might be wrong, of course.

    “The folks I hear recommending TDD are mostly folks who, I sense, would love to talk about another method for getting reliability. I wonder what makes you think they wouldn’t?”

    Well, the folks you hear are not the ones I hear. Take Uncle Bob, one of the Great Proponents of TDD, who claims, “Anyone who continues to think that TDD slows you down is living in the stone age. Sorry, that’s just the truth.” I “sense” that Bob sees more value in insulting those that oppose TDD and claiming that the “truth” is on his side than studying software fundamentals.

    http://blog.objectmentor.com/articles/2009/10/06/echoes-from-the-stone-age

    The rest of your reply to me is basically a false dichotomy.

    “What I have been hearing on the QD side is a big “no” without much “yes” to go with it.”

    I’m not advocating Quick-and-Dirty, I’m advocating a rigourous investigation of software fundamentals as the best path to improved software production rather than adherence to any single process.

    “I haven’t heard QD recommending other paths to reliable software, as much as just discounting the desire for reliable software.”

    I haven’d heard proponents of Quick-and-Dirty software production recommend other paths, either, but then this simplistic labelling of, “Quick-and-dirty,” would probably not cover anyone who made such recommendations.

    What I have heard is that investigation software fundamentals does produce the means to write reliable software, such as studying the even distribution of cyclomatic complexity over all methods, an adherence to mathematical functions to avoid side-effect programming, static typing to reflect the domain/codomain mapping of mathematical functions, the increased use of predicate-based semantics and closures outside of function-oriented programming, lexical scoping to ground encapsulation and the information-hiding that minimises change-propagation probiliity, design-by-contract to minimise the probability errors of assumption, etc. Not to mention the extensive literature on type-analysis, the lambda calculus and libraries on cuncurrency funcdamentals.

    Of course the Quick-and-Dirty crowd don’t recommend such things, but there are more groups than TDDers and QDers.

    This is the problem with TDD: It pompously implies that everyone not doing it is living in the stone age; some software students will hear that and take it to heart, evading the deep study of software fundamentals that is, I think, the best way to the production of reliable software. This is irresponsible and saddening.

    And for what it’s worth I would NEVER chose the zoo over a game of frisbee and take the implication as a great insult!

    Reply
    1. Angela Post author

      I tried to choose a label that would describe Naresh’s point of view in a way he’d agree with, but I’m not sure I succeeded. But what you’re saying makes sense to me.

      This is the problem with TDD: It pompously implies that everyone not doing it is living in the stone age; some software students will hear that and take it to heart, evading the deep study of software fundamentals that is, I think, the best way to the production of reliable software. This is irresponsible and saddening.

      This makes sense to me. I don’t much enjoy the “one way to do it” and “not doing it right” approaches. I want to understand reasons. I like the idea of investigating.

      I don’t know Bob Martin well. I’ve also been taken aback by some of his writing. I’d love to get a chance to talk to him, and understand where he’s coming from. Meanwhile, I’m glad for the friends I have who are happy to talk about the issues with care & concern for one another.

      Reply
  11. Lisa Crispin

    My team started out with a commitment to writing the best code we possibly could. We heard TDD and ATDD were two good ways to do this, so we tried them. If they hadn’t given us the quality we were looking for, we would have stopped doing them and doing something else. I agree that we shouldn’t slavishly do practices because someone else said they were good. Everyone needs to decide on a level of quality to which they want to commit, and experiment with ways to get to that level. For us, TDD and ATDD were two of the ways we got there.
    So IME, TDD is not the CMM of the 00s. I know many people who use it in an un-pompous way, including everyone on my team.

    Reply
    1. Angela Post author

      Me too. And having discovered TDD, I definitely prefer it over the way I worked before. In a nutshell, I really love breaking big problems into little ones, and having a clear statement of what the solved problem will look like.

      Reply
  12. Uncle Bob

    A doctor who doesn’t wash his hands is living in the stone age. I view TDD the same way. It is a discipline that has proven itself many times in many ways. There is no longer any good justification for avoiding it. It took some doctors the better part of sixty years to start washing their hands after the evidence was in. I imagine it will take some developers a few more decades too.

    Reply
    1. Angela Post author

      Bob,

      Your doctor who doesn’t wash his hands isn’t living in the stone age. They didn’t have doctors in the stone age.

      Maybe he hasn’t heard about germs.
      Maybe he’s heard, but isn’t convinced.
      Maybe he doesn’t think about his patients’ well-being.
      Maybe he’s found a better way to kill germs.

      I’m interested in developing knowledge, solving problems, and writing better programs.

      I appreciate your commenting here, and I appreciate your great knowledge. I am honored by the opportunity to learn from you! But learning by thinking about ideas works much better for me than trying to make sense of your unsupported declarations.

      Reply
      1. Uncle Bob

        Dogma has it’s place once options have been evaluated and decisions have been made. However, dogma also discourages those who have not evaluated those options and made those decisions. Therefore, for the moment, I shall remove my “grumpy old man” hat, in favor of a less dogmatic headdress.

        Software developers manipulate the life-blood of their companies. Regardless of whether you are building a product or an internal service, the programs you are writing are _important_. Many are critical.

        Not only are they important, they are _sensitive_. An error in a single bit within a gigabyte executable can crash the system.

        This combination of criticality and sensitivity is scary. It is entirely possible that a single bit error, at just the right place and time can destroy the project, the company, and even send the executives to jail. That may sound far-fetched, but it’s happened.

        But we are not alone. There is another group in the company that has the same problem of sensitivity and criticality. The accountants. A single digit error at just the right time and place can destroy the project, the company, and send the executives to jail. Again, it’s happened.

        How do accountants deal with this scary reality? They employ certain dogmas, certain disciplines. Taken as a group, these are known as the GAAP. (Generally Accepted Accounting Practices). One of them is: Dual-Entry Bookkeeping.

        Dual-Entry Bookkeeping is the discipline of entering every transaction twice. Once on the debit side, and again on the credit side. The two entries follow separate mathematical pathways until they meet on the balance sheet in the grand subtraction that must yield a zero. If the balance sheet doesn’t balance, an error has been made somewhere.

        Test Driven Development _is_ Dual-Entry Bookkeeping. Every logical decision is entered twice; once in the tests, and again in the production code. The two entries complement each other and produce a “green bar”. If we don’t get that green bar, we know an error has been made.

        How can professional software developers, who hold the life’s-blood of the company in their hands, treat their job with less respect than accountants do? Accountants are under time pressure. Accountants have deadlines. And yet accountants manage to follow their disciplines. How can we do less?

        Reply
  13. Hossein

    I don’t wanna talk about pro & cons of CC or QD. I just want to talk about my situation now in a startup project. I’m an idealist developer, always think a lot about the best way and then start to code. Simply you could guess that most of the time, I’m out of determined time. I think there are some key points:

    1- Most of Business Managers think about time more than quality. So if you like to think about quality more than time, you would be a beginner in his/her mind!

    2- Software development is not a single phase process (just write the code and that must be perfect!). I think, it’s a multiphase process. you write the base and then develop for the better one, and better one and …

    3- Money is a really great matter. You like to be an idealist who writes perfect (but slow)? what if you got fired? another company? then what? wanna be a software geek with no cash?

    I’m not a senior developer, but those are my concerns.

    Reply
    1. thelr

      Hossein, supervisors who are not programmers can often have trouble seeing the big picture of the software development process. If you are on a short-term project (write the code, distribute it, and never touch it again) then you may not be able to convince them of the necessity for quality code.

      However, if the project is going to receive further development after it is release, or if your company or client is going to be responsible for support and bug fixes, then quality is vital. Sure, it may seem like ignoring quality will accelerate a release date slightly, but the rest of lifecycle of the software will be horrible.

      I don’t know what your position in the company is or how much say you have in how things go, but I can tell you that there are companies out there that understand the necessity of quality code, and I hope you can find one or make yours one of them.

      Reply
    2. Angela Post author

      Hossein, thanks for bringing that up.

      I left software in 1990 because I wasn’t willing to scramble around, trying to meet arbitrary demands placed by management on a process they didn’t understand, and do it all by myself, working more than I could handle, and never being “good enough.” Oh, and then writing crap code just to get it done “on time.” So, I guess if that’s the only option, I’d just decline. I’d be poor, or work at Starbucks, or find a new way to get the money I need.

      What I’m hoping is that I can learn from folks like people like Mike Hill, Ron Jefferies, and a bunch of folks in Columbus, is another way of doing it that produces more value with less pain.

      I really recommend both those guys blogs as resources for figuring out how to make good software a bigger part of your life. Mike Hill, at anarchycreek.com, has a great post about why TDD and pairing aren’t costly, and Ron Jefferies at xprogramming.com has recently written a bunch of things on this topic. Both blogs are browse- and bookmark-worthy, imfo. ^__^

      Reply
  14. mikehill

    I think there is some kind of muddiness around the notion of quality. I distinguish between quality as in “goodness of product”, and quality as in “clean code”.

    It’s easy to trade the former for increased production. It’s not possible to trade the latter. — GeePaw

    Reply
  15. Sean McMillan

    Here’s my thought: Everyone knows that clean code is better than dirty code — otherwise we wouldn’t call them “clean” and “dirty”. But how you get to clean code may be different.

    Let’s say you get clean code by doing a thorough analysis phase up front, followed by a detailed design that is reviewed by three architects. Then the code is written, and dissected line-by-line in a Fagan-style inspection. Only then can you deliver it to the customer, who will acceptance test it and sign off on pushing it into production. This process will take weeks. Many companies believe that this kind of process will ensure clean code.

    If that is how you get clean code, then schedule pressures may lead you to say “we don’t have time for clean code.” What you really mean is, “We don’t have time to do what we believe it takes to get clean code.”

    The above process builds clean code by review and inspection. That takes time in addition to the time taken by coding. A TDD workflow (especially with pairing,) tries to ensure clean code by changing the way code is written in such a way that the code is always clean. There is no separate activity to stop doing when time is tight.

    When we sit down to write code, we should always write the best code we can. How much additional energy we will put in to making sure it’s as good as possible is a know that we can twist. (skipping code reviews, or doing less refactoring.) But you never write bad code on purpose.

    The quote from Naresh says that clean code should not be a startup’s focus. That means they shouldn’t spend extra time verifying that there code is the best it can be, or defining standards to ensure that it is good. That doesn’t mean they should write bad code, just that they have to rely on knowing that wrote the best code they could at the time.

    Reply
  16. Patrick Wilson-Welsh

    Wow! What an awesome discussion!

    Every programmer, IMO, must know how to TDD CC, and how to refactor “ok code” into CC, quickly and easily. It must be their first instinct, not their last. They must have experienced that these things are possible in various easy and difficult contexts.

    My feeling is that close to none of the professional programmers working today were trained, or learned, rigorous “method-level” CC. I want to see what happens to us as an industry if we all push that “beginning agile programmers” who want self-learning exercises (among, of course, many other things) practice “Squeeze Class” (ala Mike Hill) and “Extract Till You Drop” (from Uncle Bob) over, and over, as a First Thing to Learn.

    I’ve written this blog post, with exercises, to try to find that out. My suspicion is that these are indeed very accessible, convincing, and useful exercises/kata for your average VB6 programmer who has decided recently to “learn everything I can about agile programming, TDD, and CC.”

    What say all of you? Please Actually Try the Exercises, and provide feedback:

    http://patrickwilsonwelsh.com/?p=455

    Reply
  17. Angela Post author

    Hi, Patrick :)

    I will sure try them!

    First I learned to love & crave TDD. Now I’m learning to hate it. I think this is progress.

    I want to really get how much it can suck, then get through those stuck places (when I’ve hit a wall and am *so* tempted to say “screw this TDD; Imma write some code.”) I want to “experience that these things are possible.” It’s harder than it sounds!

    Angela

    Reply
  18. Patrick Wilson-Welsh

    Agreeing more strenuously with Ron and nuttycom: TDD/CC is faster and easier for those who have learned well enough how to do it. Short-term faster; long-term faster.

    The question for me is: how do we bring this experience, a bit of it, to as many programmers who want it, as fast as possible?

    Reply
  19. Angela Post author

    That’s been my sense of it. (faster, easier) I’m glad to hear confirmation from so many of you.

    Patrick, bringing “a bit of it” isn’t enough, imfo. Because TDD is weird, and gets weirder. A bit of it, and it seems easy, reasonable, straightforward. What I wonder is how to bring *enough* of it so that programmers get a sense of what how it works when it gets hard.

    • Lots of practice backing off to a smaller problem,
    • lots of occasions to realize, when you start to write the test, that you don’t even know what you’re trying to accomplish with the bit of code you’re writing
    • Lots of chances to get to the point where you want to stop TDDing and just write the damn thing
    • Lots of times when you realize you just wrote a bunch of code when you were totally green. And now you’re not. Oh.
    Reply
  20. Patrick Wilson-Welsh

    Schmoo, Bob, Angela: I want my Surgeon’s reflex to be to wash hands, or sanitize hands, continuously. Unconsciously. I want it to be drilled into his reflexes so deeply he would laugh if someone counted the number of times per day he does it.

    I want programmers to have TDD -> CC to be a reflex driven so deeply into them that they just crank along with it without thinking. I have seen how that speeds up more programmers and teams.

    For the record, I am suspicious of the critics of TDD-> CC: I suspect they are not yet masters of the practices, are scared to invest the time to learn the practices, and are therefore making judgments from inexperience, prejudice and fear.

    The best antidote to fear of a potentially useful practice is more of it. Works for Yoga and Meditation, BTW.

    Reply
    1. Shmoo

      Hi, Patrick,

      “Every programmer, IMO, must know how to TDD CC, and how to refactor ok code into CC, quickly and easily.”

      Of course, you’re free to have any opinion you like; TDD is a process and most widespread process devotees desire that others practice their process. CMM was extremely popular in the 90s (and continues to be so, in some circles) and seldom do you hear CMM devotees wish that fewer people used CMM. I would guess that when the waterfall process was popular in software development, most of its proponents wished that more people used the waterfall process.

      This is all fine.

      I think we would all agree that we wish our software to manifest certain properties, even if these properties are sometimes difficult to define. “Correctness,” is perhaps the least arguable; we usually want our programs to be correct. Sliding down the precision scale, we find hosts of others, “Maintainable,” for example, and, “Extendable,” both usually taken to mean that we can change the program with predictable, minimial consequences. I’m sure you can think of many more desirable properties.

      The point is that the properties of software are just that: properties of the software itself. These properties are not properties of the process used to construct the software, nor are the two sets of properties even the same. The properties of software are logical implications of the source (and, perhaps, object) code; the properties of software are not logical implications of the process by which the software was designed.

      The desirable properties of software are also more durable than the processes by which software is constructed. Programmers have always wanted their programs to, “Correct,” and, “Maintainable.” Yet, as we have seen, software development processes come and go, they are born
      to anfare and die in ridicule. We’re constantly seeking better ways to build, “Correct,” software; we seldom seek to make our software, “More correct.”

      Thus, some might think it odd that you place as a requirement on all programmers that they must know a particular software development process. Of course, you’re not discounting all other software processes, you’re merely stressing a mandatory example. Similarly, you’re not for a moment suggesting that programmers not have a knowledge of the fundamental properties of, “Good,” software, such as,
      “Correctness,” etc.

      I couldn’t think of any process that all programmers must know but I respect that you do.

      “My feeling is that close to none of the professional programmers working today were trained, or learned, rigorous method-level CC.”

      I would agree, especially if, by “CC” you mean, “Clean code,” a phrase which Robert Martin coined for his book in 2008. I’m happy to be corrected, however: when was, “Rigorous method-level CC,” first taught?

      “I want my Surgeon’s reflex to be to wash hands, or sanitize hands, continuously. Unconsciously. I want it to be drilled into his reflexes so deeply he would laugh if someone counted the number of times per day he does it.”

      So do I.

      “I want programmers to have TDD -> CC to be a reflex driven so deeply into them that they just crank along with it without thinking.”

      Analogies are fun! And they’re a fine way of succinctly portraying an opinion. Logical argument, however, they are not. That a surgeon’s washing his hands helps prevent infection does not logically imply that TDD is an equivalently (in software-terms) beneficial process.

      “I have seen how that speeds up more programmers and teams.”

      Nor is anecdotal evidence logical argument.

      “For the record, I am suspicious of the critics of TDD-> CC.”

      You won’t win them over with analogies and anecdotes. (Love the reflexivity of this sentence, by the way: you are suspicious of people who are sucpicious. Is your suspicion of their suspicion more justified than their suspicion?)

      “I suspect they are not yet masters of the practices, are scared to invest the time to learn the practices”

      You might be right; but they also might fail to see how writing test cases before production code instills in that production code the properties they seek.

      ” … and are therefore making judgments from inexperience, prejudice
      and fear.”

      Nasty lot, these anti-TDDers. Inexperienced, prejudiced and
      afraid: who’d want to wear that T-shirt?

      “The best antidote to fear of a potentially useful practice is more of it. Works for Yoga and Meditation, BTW.”

      Oh, those Yoga-cowards!

      Patrick, could you do something for me? We’ve sort of skipped around the issue, here, and it would be nice to cut to the quick.

      Could you explain why writing a test case before production code is better than writing the production code before the test case? It’s probably written on a million sites already, but please, humour me.

      Let’s debate.

      / Shmoo.

      Reply
  21. Angela Post author

    I hope you’re not thinking I’m one of those n00b critics. I’m a n00b, beyond doubt, but I’m learning all I can. I’m not looking for reasons to avoid TDD. I’m looking for opportunities to practice it.

    I’m right with you on the need to learn it deeply to understand it’s strengths and weaknesses. And if you mean “without thinking” the way we drive without thinking, ok… but I sure want my son to ask me questions, like “should I pull out into the middle of an intersection on a yellow light or not? Why? Why not?” I don’t want him to follow some rote pattern until it sinks in. I want him to do what makes sense to him, and improve his ideas all the time, and let those ideas take root and become something he does “without thinking”. Which means asking questions, and raising concerns when he has them, until the answers make sense.

    I’m cautious about discounting Naresh’s complaints. I am not one to evaluate his skill, but he *seems* to get it. He teaches it. It’s possible he might have criticism that can make the programming world better.

    And there are a lot of denotative / functional programmers who don’t have any appreciation for TDD at all. Digging in and asking questions might produce something that’s useful in broader circumstances.

    Reply
  22. Patrick Wilson-Welsh

    Angela, I think all of your insights and learning instincts are spot-on. Honestly, it’s the community of folks like you who I feel we are most letting down. We are not providing you enough useful learning systems.

    Your criticisms, your comments, and your conversation can be force-multiplication: you can help us all learn how to help others learn a little, then a little more, then a lot. And learn it faster and more efficiently than you have had to learn it. Not more easily; this stuff is hard. Just more efficiently. :)

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>