Currently there is a thread ongoing on the XP mailing list. Based on a rant from Nick Robinson, the discussion started about programmers that take pride in their work as opposed to programmers that just do that coding stuff. Today, Kurt Häusler wrote a reply in which he states his experience. You should go and read it – now – the initial rant from Robinson is in there, too. I’ll wait here for you to come back.
So, after having read Kurt’s reply, it struck me. At once it all started to make sense. Do you remember James Bach‘s two pieces on why quality is dead? Great! After having read his two pieces on why quality is dead, I was curious about the third part, which he hasn’t written so far – unfortunately. Over the course of the last year, I re-read Bach’s entry, and got finally in touch with him, trying to find out, why he thinks that quality is dead.
James explained to me, that quality is dead, since the software we use is built upon multiple layers of components. The way we build software is merely a re-composition of already available components and frameworks. Thereby we put together the pieces in ways which may or may not be initially intended for use. The complexity of this leads to an every emerging quality problem. According to Bach this quality problems is as serious as quality itself is dead, and can never be brought back. I needed some time to see this happening. And it’s true. I write this blog post based on a software, that runs on my server, written in php, with some plugins, and my browser does the spell checking while I type. Continuously the javascript code in the page is saving draft copies of this blog entry into the sql database in the back. Clearly, I could take a pen and some pieces of paper to do the same without even considering a computer. So, using the computer complicated the mere writing.
In fact, this is also true for software testing. The bug tracking tools in use, the communication tools for online chats with off-shore teammates, just pick your piece. One lesson I noticed over the course of the last four months spent in Weekend Testing sessions is that any additional tool you bring into the process is a possible source for distraction. Many tools once initially used make testers spent less time on testing. Well, this shouldn’t surprise me, as Weinberg wrote in The Secrets of Consulting about the New Law (page 141):
Nothing new ever works.
So, any new tool brought into the process will not work – at first. But, in addition, I noticed that testers get distracted from working around problems, having the urge to use the tool, while it does not serve their purpose. Of course, having build the tools on multiple components, that need twenty dependencies to be installed is a great way to distract them.
As a reply to James Bach’s quality is dead series, Robert Martin wrote about the software craftsmanship movement being called to live – claiming that quality is alive. In fact, Uncle Bob recently noticed, that testers are taking care in their profession. Now, today I noticed, that developers just as testers are taking pride in their work for maybe 5% overall. The other 95% consists of hacking together frameworks, and banging keys. So, I propose to take Jason Gorman’s approach on it, and lead by example, hoping the others will follow.
Hi, Markus,
I disagree that “nothing new ever works.” If “works” means “meets requirements to some degree”, then I can safely say that during the Weekend Testing sessions that I participated in as host, a little app called typewith.me met my requirements for helping to see live testing and to give me a way to facilitate and evaluate the work being done.
The thing was, it was very very very simple. I knew it would be risky to introduce a new tool into whatever processes the WT group used, so it had to add value without changing the way testers did their work. I think typewith.me did that.
I’ve read James’ “Qualty is Dead” posts, and I agree to a large extent. Then again, a product can be full of bugs, but if I don’t see them (or don’t mind them as a user) I don’t care. From what I could tell, and for my purposes, typewith.me met my expectations and added value. It had good enough quality for what I needed it for and a few of the weekend testers agreed.
Jon
As you wrote it, typewith.me seems to be among the 5% of the applications that were done well. But I must confess that I observed during the Weekend Testing sessions, that any tool we bring in as part of the testing missions probably leads one or the other tester to getting distracted by it. During the final hour of discussion testers explain that they realized they fell for the trap then. One great example was the EWT12 session, in which we asked testers generate test ideas and create a mind map for their session reporting:
http://weekendtesting.com/archives/947
By bringing in the application to test and a helper tool for the testing report, I noticed two things happening. Testers familiar with the tool they choose were making great progress and were able to use it to their advantage. Tony Bruce was very familiar with session tester. Likewise, I had played with the application I picked for mindmapping my progress beforehand, and had experience using another tool at work (but not for test reporting). On the other hand, the remaining testers were struggling to learn the new tool for the report, while making an own mental model of the application under test. Some got distracted by this complexity to the degree, that they noticed the passed time rather late.
For your session using typewith.me I read many great experience reports. I don’t know whether the tool is really in the 5% of good tools or not, as I haven’t used it myself. But, maybe The New Rule just didn’t apply to you, since you knew the tool beforehand. But, I may have to get some more own experience before having an improved picture of it.
Hi Markus,
regarding the whole hassle I believe that the term “monkeys” is degrading and incorrect albeit a good flame bait. Rather than creating elite vs. idiots composition the whole profession has started to create different career tracks as the industry has grown bigger and bigger. Alan Skorkin has an excellent viewpoint that I share, see http://www.skorks.com/2010/03/the-difference-between-a-developer-a-programmer-and-a-computer-scientist/ .
Someone has to design and implement the frameworks, libraries and components we use to compose larger entities. Industry is wider than ever so people working in it must spread wider. In my opinion the rant was just an expression of longing back to the “good ol’ days” when everything was better and the pixels larger.
Truly, the term monkey is degrading, but I didn’t mean to offend. I use the term in the sense, that I find the work of simply putting together ever new emerging frameworks in some new way, not very challenging. When developers start to google to find a snipplet of code to do basic math for dates, it just doesn’t feel right in my eyes. As a professional, I should either know how to write it, or know how to learn to write it. Don’t get me wrong. Seeking inspiration through google is a great place, but simply copying the code found there without even a simple understanding on how it works, is just copy & paste programming. Seeing the configurability of today’s frameworks, and seeing how people treat them, is just the same discussion to happen. Copying configuration snipplets from one place to another does not solve the problem of not understanding what is happening.
What I miss in the discussion of new roles in the act or creating new software and having it shipped is the awareness that with every new role the possibility for silo-building, lack of responsibility taking and “just-throw-my-piece-of-work-over-the-wall” mentality is created. How to tackle this risk, is a question that I haven’t really seen dealt with.
I agree, but the whole problem boils down to individual effort, thus I align myself with Uncle Bob’s software craftsmanship ideal. If an individual does not take pride in his work, he might as well be doing a conveyor-belt work at a factory and fear of being replaced in any minute (that is not to say that conveyor-belt work is somehow worthless).