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:
community, craftsmanship, quality, rant, software, software writing, improvement