Brought to you by:
©2011 Kohl Concepts Inc.
Accountability. This is often a scary word for some people. Sometimes when we are fearful of the results of a decision, or of our work on a project, we will look at what we can do to offload responsibility. "At least I won't be blamed if anything goes wrong." might be the thinking. It's hard to constantly offload onto other people though. After a while, we'll run out of team members to blame, and we probably won't be too popular. One easy way around this is to offload accountability onto an inanimate object: paper. Paper often comes in the form of specifications, design documents, test plans, test cases, or as I see more lately, proof of adherence to a popular development process. Paper might be substituted when we need to do something difficult, or provide reasons why a product isn't working, or when we need to say something others may not want to hear. Paper with fancy words and jargon is often accepted as a short-term solution to project problems. Trouble is, what does it help in the long-term, when you are being paid to deliver software?
In one case, paper provided hope to end an unpleasant release. The development team had just come out of a meeting with our sales team and a couple of important clients. They were quite clear that we needed to deliver a particular feature in our next release. Unfortunately, it wasn't working properly. Whenever we tested this new feature, the application crashed in a spectacular manner. There had been two attempts at redesigns, and everything else in the release seemed solid. The programmers were tired and demoralized, management didn't want to hear about any problems anymore, and the testers were tired of testing and feeling the weight of the release resting on their shoulders. They felt singled out because whenever they logged a bug report, the rest of the team would accuse them of holding up the release. "Jonathan, why are we testing this feature in this way?" the test lead asked, and pointed to the specification document.
"We're testing this because this is the most important feature in the release. Without this feature, our sales team is going to struggle, and our customers are going to be upset. Remember what we talked about in the meeting with both the customer and the sales team?" I asked. "Sure I do, but look at the spec. It doesn't spell out what the customer asked for. If we test to the spec, we can ship! The tests will all pass if we only test according to the spec." The lead tester had found a loophole. The thinking was that if we tested only to the spec, and followed the document to the letter, we could pass the tests that were currently failing, and management would happily release the software. Everyone would be relieved, and furthermore the lead pointed out, who could blame the testers if anything went wrong? The design spec would be at fault, not the testers or developers. "But it flat-out doesn't work!" I retorted. "Sure it does, according to the design spec." they replied. "But the customer can't use a design spec to do their jobs, can they? If our software doesn't do what they expect it to do, are they supposed to print out the spec, clutch it to their chests and draw comfort and dollars from it? The spec is meaningless to the customer when they are trying to use our software. They need this feature to work in their context, to help them get their work done. They are relying on us to deliver software, not a piece of paper with a hollow excuse."
I was a bit shocked at what this test lead proposed at first, but dealing with pressure in this way is not uncommon. A paper document can carry a lot of weight in an organization. People can draw a false sense of security from some official looking prose wrapped in corporate logos. I encouraged the tester to not fall for quick fix technicalities, especially if she wants to be a tester for very long. Fight the good fight, and while it may be hard in the short-term, the payoff in the long run is great. Happy customers, and the respect of your peers are just two payoffs. Being able to look at yourself in the mirror every day and know you have your integrity in tact is also something important, and no project deadline is worth sacrificing that for. A tester with a reputation for having no integrity will not be employable in the long-term.
On another project, paper was used in a different way. I was on one small team, and we met with other teams in the company periodically to share ideas. Another team came to a meeting and crowed about the "traceability" of documentation they were creating on a large project. We were on a small project at the time, and we were minimalists with documentation, preferring to deliver working software that could be deployed into production every two weeks. "That's fine, but you don't have traceability like we do!" they said. They bragged that for every method of code that would be written, there would be three documents generated as "project artifacts".
They met with us again in a few months. We had delivered two projects that were helping the company make more money, and they were still talking about documents. "Can you show us the code?" we asked. "We're still in the requirements-gathering phase", they snapped. They were too busy to code, instead, they were writing documents -- documents about the design, documents about a myriad of tools they could choose, and more documents documenting other documents. The company had spent several million dollars that year, and there wasn't one line of code to show for it. They had so-called "traceability" though, with project documents, and committees reviewing documents, and committees reviewing other committees. An entire infrastructure to support this process was developed. There were literally teams of people working full-time churning out documents, but finding a programmer in all of this was not an easy task. Expensive tools to aid in paper generation were purchased, more people were hired to keep up, and project budgets were sacrificed on the altar of the great "project artifact" gods. (All stages of each properly documented and "signed off" on of course.)
Through all of this, management was placated with a blizzard of paper. "Do you have a demo yet?" they would ask, only to be inundated with mountains of UML diagrams, meeting minutes, decision matrices and vendor white papers. This satisfied management in the short-term. Look at all this paper - lots of work must be getting done.
In the end, paper didn't deliver. There came a time when documents just didn't cut it anymore. Management wanted a return on investment. They didn't care about the development process du jour, detailed design documents, and requirements changes and budgets signed off in triplicate. They wanted to see the project working in production, helping them realize their business goals of a return to investors. There wasn't much of a product there though - there were lots of documents, but precious little in the way of tested, delivered software.
The project went several years, and millions of dollars over budget. It was also a public embarrassment for the company. People identified with that project were blamed, and association with that project was an impediment to finding work with other companies who had heard about it through the grapevine.
What went wrong? The vendors, consultants and employees knew they could placate management with paper, and management didn't demand a working solution early enough. This project could have done well, had they released working software incrementally, rather than churn out ever-growing mountains of paper. Instead of taking personal responsibility, the people working on the project placated customer demands with paper.
What were they thinking? Maybe they didn't really know what they were doing. Maybe they hoped the programming elves would rescue them if they created enough documents. Maybe they got swept away in groupthink, and followed a process instead of working to deliver software. Maybe they collectively thought that a colleague would take responsibility. Maybe they just didn't care. I don't know.
The customer unwittingly paid people to generate a lot of paper, instead of getting them to write and demonstrate working software. They accepted paper designs instead of code that could be demonstrated. They accepted paper over skill, and they accepted paper instead of accountability and working software.
Accountability. Demand it from yourself, and from others. Placating with paper may get you through the short-term, but sooner or later you have to demonstrate your skill. Skill can be demonstrated individually as a programmer, as a tester, a technical writer, a project manager, and demonstrated collectively as a team. It will ultimately be demonstrated in your product. Does what you produce match your claims? If it doesn't, a document and a nice explanation may get you out of a jam in the short-term, but in the long-term, you have to deliver what the customer needs. The customer won't blame the document - they will blame you and your company, and move on to a competitor's product. Where does that leave you?
Clinton Begin recently did a talk at a local Java users group, called "Ruby Rebuttal". While I like Ruby, I know that Clinton is tired of some of the hype surrounding the language, and the calls and predictions of Java's impending death at its hand. I was unable to attend his talk, but I particularly liked this part of his abstract:
I agree. I don't really care about Ruby vs. Java, or vi vs. Emacs, or "Agile" vs. "non-Agile", etc. etc. etc. debates. Furthermore, hype does little to impress me. Like Clinton, I find myself turned off by excessive hype, and it makes me want to run in the opposite direction. What impresses me are people who have a position on an issue and aren't afraid to speak their minds. What impresses me even more are skilled practitioners with a track record. I know Clinton--we've worked together--and I have a great deal of respect for him. Reading that section of his abstract just raised him up a few notches in my eyes.
I would take what Clinton said one step further. We also stuff what used to be good practice for development teams into a process. We then hold this process up like some mystically-endowed talisman, and through ritual and jargon create a kind of priesthood. The process might be home-grown, it might be "Agile," or it could be anything that seems fashionable at the time. There are the us, and there are the "unenlightened" them. (Sometimes, as the previous links show, the "enlightened" helpfully point out the "them" in the form of a joke. How this attempt at parody does anything constructive is beyond me.) I might like or dislike a particular process, but if it is working for the team, that's what really matters. A process, no matter what it is, is our servant, a tool to help us realize our goals.
When we lose sight of the goals of the business, it's easy to hide behind a process, a framework, or a language. "Yeah, the product sucks, but we followed the 12 Practices of XP! Look at this scatter chart! We did everything we could!" or or "It would have worked if we had used Java!" or "We used XML! It had to work!" Programming languages, frameworks, development processes and best practices can all be used as shields.
What Clinton touches on reminds me of a blog post by Robert Martin: I'd rather use a socket. Uncle Bob says:
The first time I read Martin's blog post, Clinton and I were both looking at a design document. A challenge for the proposed system was performance, but it had so many options of distributed frameworks it looked like the latest ad for a Service Oriented Architecture consulting company. Clinton turned to me and said: "If performance is a big deal, why are they looking at a distributed system? Going to disk is going to be much faster." At that moment I knew Clinton and I were going to get along just fine.
I see the same kind of behavior Clinton and Robert Martin describe when it comes to processes - Agile or otherwise. Paraphrasing Robert Martin: I think the industry should join processes anonymous and swear off gratuitous process adoption.
We should all start analyzing what our processes are doing for us, and only allowing the practices that work for your team, in your context to stick around. We need not hide behind "Agile this" or "XP that" or "CMM something-or-other", but proudly display our skill, and more importantly, our handiwork to satisfied and impressed customers.
We need to write great software, and continuously improve on whatever languages, frameworks and processes get us there. Whatever we do, we must be aligned with the goals of the business, and take the skills of the team members, as well as the corporate culture into account when we adopt a tool. We need to use the tool that serves us, whether it is a programming language, an IDE, a framework or a process. Leave the religiosity to medieval scholars. If we lose sight of what we're in business for in the first place, our processes will just end up as hollow ritual.
Edit: The second and third installments have been published.
The first article in a series: Test-Driven Development from a Conventional Software Testing Perspective, Part 1 is available on InformIT. Since I'm a software tester, I get asked about TDD a lot, so a couple of years ago I decided to really dive in and learn about it. This three-part series describes some of that process.
Brought to you by:
©2011 Kohl Concepts Inc.