Quit Living in the Past – Practices Evolve

In 1846 it wasn’t a required practice for medical professionals to wash their hands or equipment when treating a patient. In 1847, Ignaz Semmelweis experimented and discovered that incidences of maternal death from Puerperal fever at Vienna General Hospital were drastically reduced simply by requiring midwife ward staff to wash their hands.

Despite showing data that mortality rates under his watch at his hospital rapidly fell off after instituting this new practice, his theories were not widely accepted until well after his death when Louis Pasteur confirmed the germ theory of disease.

What does this have to do with software? Well, I have to wonder why we are so filled with hubris as to think that we are not subject, as a profession, to the same evolutionary improvement steps of every other profession in existence.

In a previous post, a commenter said:

There is bucketloads of software out there designed by good coders who didn’t follow every tenent [sic] of the Alt.NET manifesto, yet their code works just fine.

On the same post, another commenter says:

Some people without a lot of credibility to back them up like to talk about quality and maintainability and simply ignore the history of software development.

Another “gem”:

Although the numbers are changing, the VAST majority of successful, well-written software wasn’t developed using TDD.

These comments pretty fairly represent things I hear an awful lot out of some community segments, and it boils down to “I don’t need to learn or apply [x] because we’ve been getting things done without it.”

…well written software wasn’t developed using TDD

How well-written was it? What is your definition of well-written? Is it maintainable? Did it handle load and scale? After 3 years of production did it cost more to make a change than that change would realize in revenue? Did it result in the dreaded ground-up rewrite because the developers who came later threw up their hands in despair? I’m sorry, but unless you are privy to the codebase you really can’t claim that it was well written. So stop saying it.

…yet their code works just fine.

Does it? Is that good enough? Is the bar so low that “works just fine” is what we’re aiming for here? And what is “works just fine” anyway? What is the metric by which you understand this statement? Is correct program execution the ultimate measure of success of a piece of software, or is it the bare minimum we are willing to accept? This is a key question, and your answer to it will go a long way in revealing your philosophy about software construction.

Prior to 1847, babies were being born without the handwashing. Yeah, sometimes the mothers died, but the babies were getting born. Isn’t that the desired outcome of childbirth? If it were a software program, would we say that it “works just fine”?

Just because we have done things one way and had some success does not mean that new and improved techniques have no value. And just because we can’t mathematically prove that a practice or methodology will work at all times for all projects doesn’t mean that the evidence present from our own experimentation has no merit.

In my previous post, I said that I believe that certain practices have a lot of value and can lead to major improvements in the way I construct software. I believe this because I have taken the time and made the genuine effort to experiment and measure results. If you have not done so, then your opinion on the matter is irrelevant.

I also said that I don’t use every tool or practice in the toolbelt on every project because the payoff isn’t always worth the effort. I don’t know anyone out there who is saying in such black and white terms that every practice touted by “alt.net” (and ps, people claiming that all of the things talked about in alt.net originated with alt.net are betraying their very narrow scope of understanding of what’s happening in the programming world at large) need be applied in every situation.

But since my credibility on these matters has been called into question, let’s talk about some highly credible people in the community. Have you ever heard Udi, or Chris Patterson, or Dru Sellers say that every application must be SOA and have a message bus? No, but they can still talk about the benefits these architectures bring. Have you ever heard Oren say that every application must use NHibernate? Have you ever heard Greg or Dave say that every problem must be solved with a strict interpretation of the DDD bible? No. Everyone who practices these things and uses these tools and credibly talks about their benefits understands that there is context in play on every project.

If you insist on dismissing anything someone recommends because they don’t have the data to prove beyond a shadow of a doubt that a given practice is globally applicable and will result in improved outcomes in all cases, then I will insist on dismissing you unless you have the data to prove the opposite. And I’m sorry kids, but “plenty of software was built without [some practice]” just doesn’t cut it as proof, so kindly take that argument elsewhere.

I’ll come right out and say it, if you have no interest in improving what you do, and are fully content to maintain the status quo and shoot down every idea that can’t be mathematically proven to be globally applicable, you are lazy, unprofessional, and have no place in this business.

Nobody is ignoring the history of software. In fact, when we strive to achieve better practices and methodologies, we are doing so with that historical context in mind and trying to improve over past outcomes. Just like hand washing in the delivery room, some of us are out there saying “we can do this better, and because we’re ostensibly professionals, we intend to try.”

n.b. any comment that clearly indicates someone hasn’t taken the time to read or understand the post will be removed. Troll elsewhere.

Technorati Tags:
, , , , , ,

About Scott Reynolds

Scott C. Reynolds is a developer with over a decade of experience creating enterprise solutions, primarily in healthcare and biotechnology. He is passionate about the art and craft of applying software solutions to business problems. He is a frequent speaker and participant of community events nationwide.
This entry was posted in community, improvement, quality, rant, software. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

21 Responses to Quit Living in the Past – Practices Evolve

  1. mob says:

    Amen brother!

  2. Maxim says:

    I totally agree with you. Babies were born without the doctors washing their hands. We would never accept an unclean doctor anymore. The same apply with software. Of course good software can come out of lousy practices. Bt just like the doctor analogy, a lot of good ideas die at the dirty hands of some programmers that didn’t care enough.

    Let’s try to improve our profession instead of arguing that there is not enough proofs. Some practices are just obvious… like washing your hands.

  3. John West says:

    The post below isn’t an argument against alt.net. It’s simply an argument against your analogy :) .

    I’m sorry, but I don’t think the analogy isn’t comparable, unless you have a tangible metric showing cost, time, resources, maintainability… differences between code written using “old” methods of software development vs “new” methods. And it would have to be the same software. Ignaz could compare apples to apples babies dying without hand washing and with hand washing, in the same hospital under the same circumstances – a controlled environment. Since each software project is different, team members are different, etc, I doubt you can give these apples to apples comparisons. What you’re really talking about is your anecdotal, gut-feel experiences between old and new methods. I’m not saying those experiences are wrong. But you are using the same kind of generalizations that the coders you criticize are using. If you’re not privy to code written in “old” ways, you can’t assume that it’s not good software any more than someone who hasn’t touched it can assume it is good software.

    As to alt.net, some parts of alt.net are useful. Some are too much engineering for some situations, in my opinion, of course. Even in mature industries such as building buildings or making cars, there are tradeoffs between safety (bugs, maintainability in our case) and economics. We could build buildings that would withstand earthquakes and tornados and last 1000 years, but we don’t always do it. Aspects of alt.net are decisions that need to be made, not rules that need to be dictated as the only truth. If someone creates sound software without TDD, you should consider them your equal in software development, not a lesser coder who needs to evolve to your ways.


  4. @john

    Analogies are illustrative tools.

    re-read this post and the ones linked before calling me out for saying someone is less than my equal for not applying a given technique to a given problem. I not only don’t say that, but in fact advocate for applying techniques in context.

    I’m tired of the “blah blah blah is too much engineering in some context” thing. So tired, in fact, that I explicitly addressed it.

  5. Jason says:

    To sympathize with those who do not see value in evolving

    Our profession is hard. Very hard. It was hard enough to learn how to code the first time; now re-learning how to work is a terrible amount of effort and the understandable reaction is to resist until there is certainty. After all, why waste time on something that might be a fad?

    Now to terrify those who do not see value in evolving:

    Some things are not fads. How many doctors who don’t wash their hands are around today? Do you want to have a job in 20 years? If you’re not getting into automated testing of some form, you better hope the lotto hits because these practices are catching on more every day and your value is steadily decreasing.

    And don’t say we haven’t warned you .. or think we will miss you.

  6. Darren says:

    Personally, I understand why the average programmer wouldn’t want to practice TDD — given that they have no knowledge of it. It seemed a little crazy to me at first, but after practicing for a few months I can’t remember how I kept my job without it. How can I continue working as a programmer when I can’t verify that my code actually works? Before TDD, the answer to that question seemed hopeless.

    What I don’t understand, though, is the backlash against TDD by those who don’t practice it — especially those who understand it. If you don’t like it, that’s fine, but why be *against* it? I’ve just had to shake my head at some of the comments and tweets I’ve read by other programmers.

  7. You would absolutely love this podcast that Scott Hanselman did with “Uncle Bob” regarding professionalism pertaining to software development: http://www.hanselman.com/blog/HanselminutesPodcast171TheReturnOfUncleBob.aspx

    It is exactly what you are talking about…including the hand washing example!

    As a profession – we are getting there. Think back when the medical practice began. You could pick up a book and do your best to self educate yourself. Then you could call yourself a doctor and hope that you didn’t kill anyone. Coding was exactly this for me. Read and absorb as much as I could until I could call myself a professional. I see us rapidly getting to a time where that will no longer be possible from the perspective that a true professional will need to know soooo much that teaching yourself will become a thing of the past (at least no in the same fashion as it has been). I know so many people that are content with what they know and that refuse to evolve with the times. I have a feeling that they will get a rude wake up call one of these days!

  8. @andrew really? I’ll have to listen to that. Maybe the hand washing thing came to mind because it was floating around out there and living in my subconscious! But glad to know someone else thought it was an apt analogy.

  9. Ryan Riley says:

    Excellent post. Unfortunately, John is right about metrics on one point: we will not likely ever see very convincing metrics as to how much better certain practices are over duck-taping (e.g. TDD). That said, I think we can also look back at large projects that eventually crumbled under the sheer weight of duck tape (e.g. Netscape).

    I disagree that we should not view someone who doesn’t want to improve his craft as a “lesser coder who needs to evolve to [these] ways.” Does a quality plumber excuse another bad plumber for his poor workmanship? Does a master carpenter enjoy ripping out crap work done by a novice and redoing it? I should think not. So why should I be satisfied with inheriting crap code that I will eventually have to re-write because it can no longer adapt to changing requirements? (And unlike many of the examples above, we are in an industry that regularly faces changing requirements.)

    I’m also tired of all the whining by those who just don’t want to learn a new trick. You don’t have to use it everywhere, and no one says you do. However, after you try it and learn it, you’ll likely never want to go back to your old habits again… unless like a dog, you enjoy eating your own vomit. And I hope that is not the case.

  10. @ryan

    “I disagree that we should not view someone who doesn’t want to improve his craft as a “lesser coder who needs to evolve to [these] ways.” Does a quality plumber excuse another bad plumber for his poor workmanship? Does a master carpenter enjoy ripping out crap work done by a novice and redoing it? I should think not.”

    well said, and I agree 100%. If the masters in our profession don’t take a stand for what quality means, we’re lost.

    I see those as opportunities for mentoring and leading rather than straight ridicule. However, if someone refuses to be mentored and learn new things, then they should be drummed out.

  11. Matt says:

    *claps* Very well-written post. The hand-washing analogy was one I hadn’t thought of before.

  12. Peter Corcoran says:

    Great post on the NEED to evolve as a professional!

    Part of the rub coders may have with this is the times they haven’t used sound design principles and have an app (or some code) that performs it’s function without needing maintenance of a long period of time.

    Business doesn’t always move at the pace technology does, so there are times certain software is utilized over a long period while the business process doesn’t change.
    Meanwhile that software is saving the business money.

    Ok, so I through it out there, now I have to back it up with numbers so that I’m relevant. I’ve written a number of apps, one specifically that has been used in its environment for 6 years. I haven’t changed the code in maybe 3 or 4, and even then it was minor tweaks. I wrote the app back when I’m was a noob…(which even after years of studying software development can I really ever say I’m more than just a semi-noob?), and with no concept of design principles. Now to quantify: since the last time I did the number the tool has saved over 13,000 hours, and avoided over $726,000 of business cost, (while costings less than $100,000 – my time – to build and maintain)

    Now since then, I have developed more as a coder (point of post). However, we shouldn’t be so brutal on the narrow-minded, since their reference comes from cost saving/avoidance etc. We need to evangelize the importance of sound design principles because improves the value of the code, the coder and all the other benefits, but avoid the religious zealousness.

    And remember – ALL of our first “HELLO WORLD”s weren’t written with TDD…or were they? (Is Hello World a test?)

  13. Agreed. I, too, tire of having to argue and defend very basic techniques, such as automated unit tests (not even full TDD) to apathetic developers. To me, it’s simply professional negligence and a complete lack of interest in the profession.

    That said, where I think your analogy breaks down is what non-developers (who are often paying our salaries) actually care about. Software development in many organizations is viewed more like the stork fable than a maternity ward in a hospital. Nobody knows where the baby came from or what was involved, but they got a baby from the stork and it has ten fingers & toes.

    Given that their customers don’t care about code quality, developers begin to focus on the things the business *does* reward (flashy UI, more features, etc) and become professionally negligent in areas that aren’t valued (process, quality, etc).

    My point is that all such developers aren’t fundamentally lazy, but that they may be in environments where the rational conclusions you and I are drawing regarding quality and professionalism are simply leading them to different conclusions.

    Until we can make software delivery a more understood process so that everybody (including non-developers) understand what quality looks like, we’re unlikely to get over humanity’s natural inclination to resist change. This allows storks to deliver the baby even if the mother didn’t survive and the baby might have long-term health risks, all the while crapping on the heads of the doctors wearing sterilized scrubs.

  14. Mathias says:

    Why bother with TDD, when DTD, aka Duct-Tape Development, seems to be the best methodology around :)

    Software engineering is a special discipline, too, in that it is very young and evolving very fast, so the best practices are still in their infancy. A medical patient hasn’t changed much in the past centuries, but a 20-year old computer is an archeology artifact. It’s important to keep learning and try out ideas, because the craft is still emerging.

  15. Brian says:

    I think some people are threatened by having to learn new things & not being able to grow their career w/ the same tool-set they’ve been using for the past 10 years. It’s always kinda struck me as similar to my parents generation being intimidated by the internet and always asking “how is this actually going to improve my life? I got by just fine with the telephone and letters in envelopes.” The world has passed them by. Likewise, at some point, the software development world is going to pass by those too lazy or scared to adapt. “Change or die, old man.”

  16. @Mathias

    Indeed. Software development is a very young profession, which is precisely why we can’t hold it back by holding on to what we’ve done in the past and being unwilling to adapt to new practices and see what fits where.

    nothing worse than being stagnant before you’re mature.

  17. Steve says:

    Wow, I’m not sure how I got lumped in with jdn when I made it abundently clear that I was just asking some quesitons and I repeatedly stated that I was not questioning your ability.

    You cherry pick comments and totally ignore their context, when I said “their code works just fine”, I followed it up with an example of a piece of code written over 6 years ago that not only is easy to maintain, it’s customizable and has made plenty of clients very happy. But yet, you somehow read that as the bar being set low? If a clients happiness isn’t in your metrics, than I suggest you re-think how you evaluate quality.

    You then quote: “…well written software wasn’t developed using TDD”

    and follow it up with this doosy:

    “How well-written was it? What is your definition of well-written? Is it maintainable? Did it handle load and scale? After 3 years of production did it cost more to make a change than that change would realize in revenue? Did it result in the dreaded ground-up rewrite because the developers who came later threw up their hands in despair? I’m sorry, but unless you are privy to the codebase you really can’t claim that it was well written. So stop saying it.”

    Do you not see what you just did there? You chastise someone for saying that “well written software wasn’t developed using TDD” because they haven’t seen the code base, all the while implying that it’s NOT well written, yet you haven’t seen the code base either. You also ignore that TDD does not even remotely guarentee that code will handle load, will scale or even that it’s well writen. It guarentees that some tests work (and there’s no guarentee that those are the proper tests). You make a massive leap there without one shred of evidence (which was quickly pointed out).

    Ditto for that horrible analogy. I’d buy it if it was related to the SOLID principles perhaps, you know, small things anyone can do to improve code (I think we can all agree that washing your hands is a small change in the baby delivering process). On that note, I don’t think anyone, anywhere is saying abandon basic principles while developing, because frankly the likes of SOLID, DRY, YAGNI, etc. are pretty much universally accepted as “right”.

    Lump me in with jdn all you want, but by doing so you completely ignore what I said in pretty much all my comments. My concern is with the tendency of “educated” C# developers to over-engineer practically everything. If Joel’s flamebait used the term “Pragmatic”, “Customer Centric”, “Logical” or a host of any other applicable terms instead of “Duct Tape”, maybe, just maybe more people would have read it without such venom.

    The way I read it was simply this: jwiz didn’t over engineer something, and we got Netscape, when Collabra came in and tried to over engineer it, they got a bloated piece of junk. That’s it, nothing more, nothing less. To that end, for some reason, people seem to think there are only two options in development, either the right way or the wrong way, and that’s clearly not true. The “right” way can be broken down into infinite solutions, using various processes, automatically thinking anything but your (meaning “your” as in anyone) right way is automatically the wrong way is just ridiculous.

  18. @steve

    I only “lumped you in” by virtue of addressing your comments here. I’m sorry if you felt there was other intent.

    As to the rest of it:

    I’m not implying that these things weren’t well-written, I’m asking the questions I would ask to qualify what well-written means. It was a generalization, not specifically addressed to the example you commented on. If you inferred other intent to these questions that’s unfortunate.

    I did not make a “massive leap…without a shred of evidence” because I wasn’t positing that TDD would answer those questions, I was questioning the nature of “well-written”.


  19. Steve says:


    >>I think some people are threatened by having to learn new things

    I honestly don’t see that as being a major problem, at least not from what I’ve seen. I think the main problem is that our industry pays so damned well. Secondly, it’s very hard to gauge success and failure. Even the best of us has had a project crash and burn, even if it’s nothing to do with the failure (changing spec, unrealistic expectations, ridiculous delivery date, changing market, etc., etc.). So does a manager fire anyone who’s ever failed a project?

    I think that’s why there are no bad tattoo artists. It doesn’t pay all that well, and if you suck, the evidence is right there right in front of you. Plus you can’t really bluff you way into being one (not the case in our profession, that’s for sure).

    So these 5:01 developers just pound keys and cash checks. They’re not particularily scared or threatened by learning anything new, they just don’t care too. The leap from tightly coupling a DAL to an Entity/Service can be fixed by simple dependecy injection in a constructor, I’m not sure if it’s possible to threaten someone with that, but if a developer a) has no reason to learn it (since they’ve never been asked to improve) or b) no desire to learn it, then it’ll never be learned.

    I completey agree with what everyone’s saying in that they hate replacing all that crappy code out there, but at the end of the day, if the code works and the customer is happy, I tend to leave it be. If I was going to fix everything that didn’t measure up to my own standards, then I’d spend 80 hrs a week refactoring 1,000s of lines of functioning code for the next two years. Back to our tattoo artist, they don’t fix every tattoo on a customer’s body when they create a new one (unless specifically asked).

  20. Yoooder says:

    I think the real matter here is drawing the line between those who learn what they have to in order to stay employed and those who want to learn to better themselves and their skills.

    One of the greatest issues in introducing quality in our profession is that at the end of the day we (and our peers) are the only ones to see the raw product of our work–the source code. Everyone else’s opinion is based on the visible result of the code rather than the code itself.

    A large hurdle to bettering the industry as a whole is that us nerds often have an elitist attitude and the opinion that our way is the best–all too often because it’s the only way we know. As a whole we need to be more humble and more willing to take advice as well as provide mentoring.

  21. alwin says:

    The thing is, it’s hard to measure the benefit of new tools like TDD and others.

    Nowadays we practice Evidence Based Medicine (at least where I live). For example, you take n=100 births, randomly half of them you let the staff wash their hands, and the other half not. All other conditions are equal, and n is large enough. Result is: significant less maternal deaths.
    Evidence / conclusion / consensus: you should wash your hands.

    I’ve never seen a study that looks at TDD or other alt.net stuff this way. Of course it’s hard to objectively measure the benefits, and thats why people on both sides resort to anecdotal arguments. The discussion is not based on evidence, but on personal experiences.

    I don’t disagree with your overall point, it’s just that your analogy is a bit off. I do think that we as software developers, like doctors, have to keep ourselves up to date about using improved tools for diagnose and treatment of our patients.