by Sammy Larbi at 2009-07-02T12:30:37Z
by Sammy Larbi at 2009-07-02T12:30:37Z
Hang around my colleagues at ThoughtWorks and you soon get the impression that the only good Enterprise Service Bus (ESB) is a dead ESB. Jim Webber refers to them as Egregious Spaghetti Boxes. So it's not uncommon to hear tales of attempts to get them out of systems that don't need them.
Battle was joined at one client and it brought to mind my younger days playing D&D. Webber swings but misses as the ESB is AC 2, Evan gets a hit and rolls 2d8 for 6 damage. Erik finally kills it by casting "Summon Request Stream Map".
So what was Erik's decisive spell? Essentially the idea was to take a simple request and show how the data for the request and response made their way through the layers of the application. Erik printed out all the code that you needed to read to understand how this would work - which ran to several pages. He also produced this diagram.

It's currently fashionable in agile circles to do Value Stream Mapping as a way to uncover waste in a software development process. I think of this as a request stream map because it similarly takes a request and shows how it moves through the layers allowing us to visualize what's going on and think about the cost and value of the layers.
Layering is an essential tool for building software applications. But like most essential things in life, excess can be almost as much of a problem as too little. A visualization like this (or the multiple pages of code) can help you find where "just enough" is.
One hazard, however. If you do need to transform data from one form to another, it's usually better to a few little transformations than one big transformation. You want to avoid unnecessary transformations not compress the ones you need.
2009-07-01T18:58:00Z
What's the most common programming language in the world?
I'm not sure how you could go about measuring this, but one thing you'd need to do is consider what we mean by programming. My candidate answer considers that the most popular programming language is one used widely by people who do not consider themselves as programmers. This language is Excel, or more generally spreadsheets.
Spreadsheets are easily used for small tasks, but are also used for surprisingly complex and important things. Often I've seen professional programmers gulp when they realize that some vital business function is being run off some spreadsheet that they'd find too complicated to muck with.
In general, we've not had much success with programming languages for these kind of LayProgrammers. Whenever someone talks about some new environment that's going to allow people to specify complex behavior "without programming" I mention COBOL, which was originally designed to get rid of programmers. So it's important to consider what Excel can teach us about programming environments.
One property of spreadsheets, that I think is important, is its ability to fuse the execution of the program together with its definition. When you look at a spreadsheet, the formulae of the spreadsheet are not immediately apparent, instead what you see is the calculated numbers - an illustration of what the program does.

Using examples as a first class element of a programming environment crops up in other places - UI designers also have this. Providing a concrete illustration of the program output helps people understand what the program definition does, so they can more easily reason about behavior.
So why do I feel we need this particular Neologism? Essentially because I think it deserves more thought. We pass by illustrative programming examples without really thinking about them or what makes them special - or even that they are special in some way. We've used illustrative programming for years, but we've not paid enough attention to it. We've not thought enough about what are its essential qualities and what its strengths and weaknesses are.
I've chosen the term "Illustrative Programming" to describe this, partly because "example" is so heavily used (and illustration isn't) but also because the term "illustration" reinforces the explanatory nature of the example execution. Illustrations are meant to help explain a concept by giving you a different way of looking at it - similarly an illustrative execution is there to help you see what your program does as you change it.
When trying to make a concept explicit like this, it's useful to think about the boundary cases. One boundary is the notion of using projections of program information during editing, such as an IDE that shows you the class hierarchy while you are working on the code. In some ways this is similar, as the hierarchy display is continuously updated as you modify the program, but the crucial difference is that the hierarchy can be derived from static information about the program. Illustrative programming requires information from the actual running of the program.
I also see illustrative programming as a concept beyond the classic REPL loop of dynamic languages. REPL loops allow you to explore execution, but they don't make the examples front and center in the way that a spreadsheet does its values. Illustrative programming techniques put the illustration in the foreground of your editing experience. The program retreats to the background, peeping out only when we want to explore a part of the illustration.
I don't think that illustrative programming is all goodness. One problem I've seen with spreadsheets and with GUI designers is that they do a good job of revealing what a program does, but de-emphasizes program structure. As a result complicated spreadsheets and UI panels are often difficult to understand and modify. They are often riven with uncontrolled copy-and-paste programming.
This strikes me as a consequence of the fact that the program is de-emphasized in favor of the illustrations. As a result the programmers don't think to take care of it. We suffer enough from a lack of care of programs even in regular programming, so it's hardly shocking that this occurs with illustrative programs written by lay programmers. But this problem leads us to create programs that quickly become unmaintainable as they grow. The challenge for future illustrative programming environments is to help develop a well structured program behind the illustrations - although the illustrations may also make us rethink what a well structured program is.
The hard part of this may well be the ability to easily create new abstractions. One of my observations of rich client UI software is that they get tangled because the UI builders think only in terms of screens and controls. My experiments here suggest to me that you need to find the right abstractions for you program, which will take a different form. But these abstractions won't be supported by the screen builder as it can only illustrate the abstractions it knows about.
My colleagues Rebecca Parsons and Neal Ford have been spending a lot of time involved in thinking along these lines too. So here's some thoughts that Neal had in an email exchange
--Neal Ford
One of the few people to take illustrative programming seriously is Jonathan Edwards. He's come up with many very imaginative ideas as to what such an environment should look like. His vision of illustrative programming is also closely bound to the notions of projectional editing and controlled copy-and-paste.
The trigger for me in wanting to coin a term here, is the use of illustrative programming by Language Workbenches by people like IntentionalSoftware. These Language Workbenches encourage you to build illustrative DSLs. Using illustration is important in this case since this should help engage lay-programmers, which is one of the aims of using DSLs. The challenge is to do this without falling into the trap of poor program structure.
2009-06-30T19:23:00Z
by Sammy Larbi at 2009-06-30T12:58:59Z
by Esther Derby at 2009-06-30T11:32:15Z
2009-06-29T23:14:00Z
by Esther Derby at 2009-06-29T21:49:28Z
The CAST testing conference is happening in Colorado Springs, July 13-16. I mention this for two reasons:
1. I will be teaching a testing tutorial there. I also will be wandering around with my various testing games and challenges hoping to do them with anyone who wants to see what I mean by “testing skills.”
2. CAST is the only conference that is organized in the true spirit of the Context-Driven School of Testing. It’s kind of our home conference. If you find my thoughts interesting, or those of Cem Kaner, Michael Bolton, Ben Simo, etc. Then you’ll want to be there, if you can.
by James Bach at 2009-06-26T22:54:30Z
2009-06-26T15:24:00Z
2009-06-26T15:24:00Z
Thanks to a pointer from Kent Beck, I’ve just read Alan Keefer’s post, Taking Responsibility. This is probably the best description I’ve ever read of the role that a software or system architect should take.
And it’s very different from the role I’ve normally seen them take. Most software architects got the title because they were very good software developers. I’ve seen far to many who assume that they should now do the “highest level” of the work they’ve been doing, that of the system level design, and leave the more mundane work to those who are still software developers. In other words, they’re considering their promotion from the point of responsibilities they’re shedding rather than those that they’re taking on.Alan, instead, speaks of the enormous responsibility that he has with the role of architect. He says, “my job is to make sure that the project doesn’t fail for technical reasons.” There’s no refuge in saying, “I did my part right.” It all has to work.
This is an important point for all of us to consider, whether architect or not. It’s never very satisfying to hide behind the statement, “I did my work well, but those people over there screwed everything up.” We can all do better than that. We can all look around and see what else is going on. We can do things to help that larger picture. We can do things to adjust to the reality of that larger picture.
Of course, we can still fail. But when we fail, it’s a pathetic refuge to blame the failure on others if we made no attempt to succeed at more than the tasks right in front of us. And if we did try hard to help the project succeed as a whole, but it still failed, then must accept some responsibility for that failure.
“In spite of my best efforts, the project failed.” There is, in that statement, both a sense of failure and a sense of pride. “I gave my best efforts.” Perhaps they were not enough for these circumstances. Perhaps they were the wrong thing in these circumstances. We do well to reflect on what we did, why things happened the way they did, what we might have done differently, and what we might do in the future. Retrospecting as a team would be wonderful. Retrospecting by ourselves is something we can always do.
This topic is a great illustration of Jerry Weinberg’s statement, “The ultimate limit to software is courage. Imagination is a distant second.”
Now, go read Alan Keefer’s post, Taking Responsibility.
by George Dinwiddie at 2009-06-26T14:38:26Z
A few weeks ago I had the opportunity to attend a webinar “Giving and Taking Design Criticism” with Rebecca Wirfs-Brock. The session teaser was: “Have you ever engaged in a design review where people didn't play fair? Do you have trouble giving design advice that sticks? An effective software developer or designer needs to be skilled at giving, asking for, and reacting appropriately to criticism.”
As someone who has done design/code reviews – I’ve always wondered why the advice didn’t stick and needed to be repeated time after time. As the victim of the same reviews I wondered why the reviewer needed to be so picky and unpleasant ;-) Two sides of the same coin?
In this Webinar Rebecca reminded us of what is going on and gave us some tools to do better reviews and be better listeners. She talked about Cognitive Biases (an excellent list >75 biases) and their effect. Key take away: everyone brings a different set of biases to the table and they cause use to react rather “think and behave logically”.
When presenting ideas keep the following biases in mind (some definitions from Wikipedia):
Giving and receiving Advice:
Finally Rebecca finished with a good recap of the reasoning fallacies (who knew that undergrad logic course would ever prove useful), among them:
All in all a very interesting session – I only wish it had been interactive and not passive so that we retained more of what we there to learn.
Rebecca’s recommended reading includes: Wikipedia for Cognitive Biases, Changing Minds, “How to Disagree” by Paul Graham and her own articles: “Giving Design Advice” and “Handling Design Criticism”.
by Mark Levison at 2009-06-25T15:31:55Z
We proudly announce Photo Suggest, a web application that helps you find photos with liberal licenses to go with your blog entry or slide Check it out.
Dancing Peacock by Hamed Saber
As a writer, I want photos to go with my blog entry, so that it looks appealing for readers and inspires me to write more.
Brickpit Ring Walk Bicentenial Park by Louise Docker
As a presenter, I want photos to go with my slide, so the slides have metaphors that make people think, and my presentations look well prepared.
For these two stories we might not have bothered writing a web application – we could use the regular flickr search. However:
As a writer or presenter, I want to easily credit the photographer so that I can fulfill the obligations that go with the license and give viewers the opportunity to see more of their work.
I used to have Super Human Powers by Esparta Palma
We found that finding photos to go with a presentation was easy enough, but collecting the credits and then adding an attribution to the photo in a blog entry or the end of a presentation) often turned out to be a lot of clicks, which meant that we would not add photos to presentations as often as we like…
Photo Suggest queries Flickr and searches for photos with a liberal license (see the about page for a short list) sorted by interestingness. If you click on the link below an image, it takes you to the details page that shows the full credits, license and description together with the image. The reason we called it ’suggest’ is that when you type a keyword, the results are often not what you’d expect, but can more often than not make an interesting contribution to your text.
With QWAN we try to apply lean and agile principles to everything we do, so we reflect at our ways of working continuously, identify things that add value, and do more of them, as well as things that are wasteful and eliminate them. We started to give more and more presentations to get the word out – we love experiential sessions over anything else, but they do not get us into more traditional conferences. Styles like Presentation Zen led us to do more with images.
Presentations with attractive imagery inspire me more when I do a presentation and they seem to energize the audience as well, so it becomes easier to add experiential elements (small exercises, questions) to a presentation.
Marc Evers and I have been thinking about how to improve our presentations as well as the way we produce them for a while. This led to a bunch of wild ideas, which we used as stories for the new new new! product development game – participants have to plan a ‘presentation 3.0′ project.
With Lasse Koskela I ran a Scrapheap Challenge at XP2009 – participants have to write a working application in half an hour. For that we needed exercises. Some stories from the game seemed well suited, so I did a small experiment – in half an hour I got quite far. Then I called Marc and asked him if he wanted to help me finish it into a working application. We had noticed we were losing some of our “superhuman powers”
, so Marc suggested to “start from production”, which meant I talked him through the app while we brought it into version control and production, before adding more features & polish.
From experiment to production took half a day. After a day it was usable enough (but was missing the finish such as about page and stylesheet) for us for blog entries and presentations. When we demoed it during xp2009 a few participants jotted down the url, which encouraged us to polish and publish it.
by Willem at 2009-06-25T12:59:23Z
by Sammy Larbi at 2009-06-25T04:39:18Z
by Esther Derby at 2009-06-23T03:46:12Z
Saw this tweet the other day…
So, I have to ask. How many toilets (buckets) do you maintain? How many of them still have projects/tasks in them? Why haven’t you flushed your toilets yet?
by Robby Russell at 2009-06-20T01:14:54Z
Susan Prior drops in on Kate to talk about some new products she would like developed.
“Hi, Susan,” said Kate. “You wanted to talk with me?”
“Hi, Kate. Yes. I’ve got some product ideas that I think we should invest in, and I wanted to talk with you about getting started. Dan is interested and said I should get your input.”
“Sure. What’s up?”
“There are three new products I’ve been talking about with my people and with customers. They’re all getting good reactions from prospects we’ve talked to. I think they would each bring us about a million dollars in the first year after release. I can show you the figures.”
Susan and Kate went over the figures, and talked about the three projects, which were codenamed Emerald, Obsidian, and Ruby.
Kate said: “The revenue looks good for each of these. What do you know about costs?”
“Gil and Jim looked at the specs and agreed that each one of these is about 15 person-months to develop.”
“OK,” said Kate. “What are you thinking you’d like to do?”
Susan said, “I have three people in Marketing who are working up feature stories. I would be the official Product Owner on all three, at least through first release. Development can free up six people soon. I’d like to get those six people committed to these projects for nine months to a year to get the products out.”
“Hmm. How did we get from 45 person months to 72 all of a sudden,” Kate said. “That’s a lot of money, from 375,000 to 600,000 dollars.”
“Well, I figured in a little extra in case Gil and Jim under-estimated, or in case they are late.”
“I understand, though I’m not sure I agree. And why are you going for all the money and time for all three projects at once?”
Susan said, “These are all important and valuable projects. We should get them all under way right away.”
“You’re asking Development to work on all three of them at once? Two people on each or something?”
“No,” said Susan. “Gil and Jim say the critical mass for each product is five or six. So I’ll have the team work on all three products.”
Kate put on her confused face. “All three? Wouldn’t it be better to work on them one at a time? Most important first?”
Susan said, “No. They’re all equally important and equally valuable. They should get equal priority.”
“Equal? Are you sure?”
“Well, as closely as we can tell,” said Susan. “Each of these projects takes about the same amount of time and will bring in about the same revenue flow. So they should get equal priority.”
Kate said: “Let’s test that thought. What if we could only afford one? What should we do?”
“I knew you would do this. This is my chance, and you want to wreck it. You’ve always hated me ever since the beginning.”
“Calm down,” Kate said. “I don’t want to wreck anything. And I don’t hate anyone. I can’t afford it, it poisons my soul. I just asked a question. What if we could only afford one? What would be best to do? Would you like to take a break to think about it?”
Susan steadied herself. “No, I’m OK. I’m just so excited and scared about this. These ideas are really good. They could make a difference to the company and I can show what I can really do.”
“I’d like that, too. You got off to a bad start with the team on Empire. But I know they are willing to work with you on this,” Kate said.
Susan asked, “You know? How do you know?”
Kate laughed: “I know almost everything around here. People tell me things. I think it’s because I spend so much time in the coffee room.
“Gil and Jim have both said, several times, that they respect your ideas and would like to see them get implemented.”
Susan calmed down some more. “They did? They never told me.”
Kate laughed again. “They’re programmers. They never say anything personal to anyone. It’s their job.”
“Good point. Anyway, if we could only do one, it should be Obsidian.”
“Why Obsidian?”
Susan said, “Three reasons. It’s a bit simpler, the prospects we have talked to seem more enthusiastic about it, and we understand it better.”
Kate thought, then spoke. “Those seem like good reasons. Thanks. Now, thinking again about doing these as you propose, let’s look at some pictures.”
This time Susan laughed. “I knew I could never get out of here without pictures.”
“It could be worse. I could make you listen to me singing. OK. Let’s look at a nine-month plan.”

“OK,” Kate said. “Here’s a planning area. We have the three projects, Emerald, Obsidian, and Ruby. They’re all about the same size in stories, and you’re planning an ideal nine-month project. I won’t show any contingency here, just for clarity. OK?”
“Yes,” said Susan. “We may need the contingency, though.”
“Don’t worry, we’ll talk about that later. Now here is the way features will grow over the nine months, according to plan.”
Kate added feature lines to the chart:

Kate went on. “The features all grow at about the same rate until the projects are all done after nine months. That’s the starting picture, agreed?”
Susan nodded. “Yes, exactly. The developers would work in parallel on all three products”
Kate said, “In parallel. Why is that good?”
“So we could see progress on each product.”
“And why do we need to see progress on each product?”
Susan thought. “Well, so that if anything goes wrong we can do something about it.”
“OK, I guess. Now when do we start making money from these products?”
Susan said, “If it goes according to the plan there and we don’t need the contingency, we start making money shortly after the nine months is up.”
“Shortly after,” Kate said.
“Well, we would have to roll them out with advertising, documentation and training and such.”
“Those couldn’t start sooner?”
Susan said, “Well but what happens if the developers are late?”
“You keep asking that,” Kate said. “In my view developers are never late. Products are late sometimes, but never developers. I suppose that sounds like crazy talk.”
“Frankly, yes,” said Susan.
“OK, we’ll defer that for a moment. Returning to the picture, we start earning money at three million a year, starting nine months out, is that right?”
“Yes, that’s right,” Susan said.
“OK. Now take a look at this drawing instead.” Kate erased some lines and drew some new ones:

“Susan, now I’m drawing a picture of what happens if we do the three projects one at a time. The new vertical lines are three release dates, at three months, six, and nine.”
Susan said, “But what about contingency?”
“I’ve left that out, as I did in the previous picture. We’ll talk about it though, don’t worry. Now in this scheme, we focus the developers on first Obsidian, then Emerald, then Ruby. Look what happens to Obsidian development:”

Susan said, “Yes. It gets done right away. But the others aren’t even started. That’s risky, isn’t it?”
Kate said, “I’m not clear on why it would be, so marshall your thoughts. But tell me what happens to company revenue with this scheme.”
“Well, we start earning after three months instead of nine.”
“Do we make more, or less, or about the same,” Kate said.
“About the same. Maybe more, because we are in the market sooner and might get more early adopters.”
“What about the impact on this fiscal year, and on our ability to fund projects?”
Susan scratched on a scrap of paper for a moment. “Well, we’d be to market six months sooner and in the first six months I think we get about 40 percent of the 12 months revenue for Obsidian. If we start right away, that would all fall in this fiscal year.”
“Yes! That would be $400,000 and that’s just about the low-end cost estimate for all three projects. What does that do to our concern about deferred risks for Emerald and Ruby?”
Susan thought. “OK, I see. Total cost of those two projects is scheduled to be less than $300K. Even if they completely failed, Obsidian’s first six months revenue would cover the costs. But again, what if development can’t get Obsidian done in three months?”
Kate smiled. “Go with me a bit longer while I finish this picture. Here’s the picture of the other two projects getting done sequentially after Obsidian:

“So here I’ve just assumed we’ll do Emerald next, then Ruby. It could be done the other way. So Emerald is done after six months. What happens with revenue there?”
“If things go according to plan, we think Emerald would bring in about 150K in its first quarter out,” Susan said.
“Yes. So even that revenue is a big chunk of the cost of doing Ruby, and of course we’re already covered by Obsidian. So by the end of the three projects, we would see $500,000 in revenue, and it would all fall into this fiscal year. And the total cost of the projects you are asking for is around $375,000 if we use the development estimates. Even with six developers, we are looking at expenses of about 3/4 of 600K, or 450K for the nine months. See the difference?”
Susan stared for a moment. “Yes, sure. Done your way, the same projects actually break even this year or earn a small profit. Done my way, we spend $450,000 before we get anything.”
Kate said, “Let’s not think my way your way. Done in parallel, the projects burn through almost a half a million dollars this year. Done in series, they burn $150,000 in the first quarter, then start earning back, and we are back to even by the end of the fiscal year.”
Kate smiled. “If it was your money, Susan, which way would be ‘your way’?”
Susan said, “I get it. My way is to do this in series. That’s what I recommend. Yes, totally. I’m sure that’s what I meant all along. Serial.”
Kate laughed. “I thought so. It’s almost lunch time, are we done for the morning?”
Susan thought. “I think so, yes. I’d ask to have lunch with you but I need to think a bit first. I’m still worried about contingencies and risks.”
“Good,” said Kate. “I’d like you to think about that. As a hint, think in terms of what you can do as Product Owner to manage the risk. But keep in mind it’s your money, and you can just barely afford the $150K a month for your six developer team.”
“That’s scary,” Susan said. “I guess that’s what you feel all the time?”
“Well, it’s the problem I have all the time, Susan. But I’m not very scared. See if you can figure out why. When shall we meet again?”
“I’d like to come in again tomorrow, if that’s OK,” said Susan.
“Sure thing,” said Kate. “I’ll be here. Thanks, this was fun.”
“It was,” said Susan. “Oddly enough, it was. Thanks, Kate.”
“You’re welcome, Susan, and thank you. We could use another three million in revenue.”
by Ron Jeffries at 2009-06-19T13:48:07Z
This comes from an ISTQB advertisement they spammed me with, today:
“To ensure the quality of any software system, testers and QA professionals must thoroughly test the product. But how do you know that these tests are effective? If your team is conducting ad hoc, informal tests with little guidance or planning, the quality of the end product can be severely jeopardized—negatively affecting your bottom line.”
I don’t like to say things like this, nor am I comfortable supporting people who do. It’s not that it’s untrue– it is not necessarily untrue. But it is the kind of statement that fans the flames of a certain sort of Factory School bigotry in our industry. “Oh, you can’t trust testing unless it is pre-planned, pre-packaged, pre-approved, formalized, etc.”
Notice they say nothing about skill. It’s all about methodology, here, not skill. This kind of setup suggests that the next statement will be about the importance of factory-like test methodology. But that’s not what happens.
“The best way to be certain that you are providing customers with quality software is to make sure your team of testers is certified.”
Friends, I’m aware of no one in the industry– not even my worst enemies, not even Rex Black or Stuart Reid– who would publicly assert this or defend it. In fact, in debates against those of us who think certification is consumer fraud, the most typical move is for certificationists to say that certification isn’t even about skill, but rather about basic knowledge. “It’s a start” they say. “It’s a foundation.” (I reply that it’s a bad start and a bad foundation. Much worse than what it tries to replace.)
But then they allow this sort of advertising to go out! Completely undercutting their innocent-sounding plea! And they wonder why I complain that they don’t have the best interests of the testing craft at heart.
Notice that the “ad hoc and unplanned” stuff doesn’t even logically connect to certification. In fact, wouldn’t a highly skilled tester be far more likely to succeed with an ad hoc testing regime? When Roger Federer plays ad hoc tennis, I bet he still wins.
I think the reasons they start talking about methodology and end up talking about certification is A) their potential customers don’t understand the difference between skill and method, B) method is more concrete than skill, thus easier to evoke, and C) they know that what they say doesn’t have to be true or even logical, as long as it evokes horror and promises hope.
Oh, but there’s more…
“By taking the Software Tester Certification course and earning an internationally recognized certification in software testing, your team will gain the expertise needed to handle your greatest testing challenges; earn credibility and recognition as competent quality assurance professionals; and provide greater value to your organization.”
It’s internationally recognized? By whom? Some people who don’t study testing and some people who study testing and financially benefit from certification. Okay, but it is also internationally ridiculed by serious testers of many nations who wish to raise themselves to a level of skill that can’t be obtained in just a couple of days of training.
I recently encountered Dot Graham, now semi-retired, who told me that it hurts her feelings when people like me suggest that certificationists are only in it for the money. Dot is a sweet person. I don’t want to hurt her feelings. But I point her to advertising like this and I challenge her to explain it in any other terms. If not greed, then what, Dot? Stupidity? Pride?
Dot doesn’t want to argue with me about this. Of course she doesn’t. Rex Black doesn’t want to argue, either. Naturally. What answer could there be? Lois Koslowski once told me that “big dogs” don’t need to debate (in fairness, Lois Koslowski claims not to be a tester. I agree that she showed no testing competence or knowledge in the conversation we had. I just mention her because she did claim to be in charge of the ASTQB organization. Yikes!) This is capitalism in its ugly form– harvesting the ignorance and fear of others. Debate has no place here.
Is there no one in that self-declared professional community who reviews the advertising and stands up for professional temperance and humility?
by James Bach at 2009-06-18T23:40:10Z
2009-06-18T20:47:17Z
by Sammy Larbi at 2009-06-18T16:33:27Z
Amr Elssamadisy reports on InfoQ that automated acceptance tests are “only used by a small minority of the community.” Is this true? If you and your team don’t use automated acceptance tests, please let me know how you handle regression tests as the application grows larger. You can leave a comment here or, if you’d rather not say it in public, email me directly.
OK, I know that “acceptance tests” are somewhat a misnomer. While they may provide a go/no go indicator for the functionality of a user story, we all know that it’s possible that the application passes the test and still isn’t what the Product Owner or Customer wants. You still need to show it to the Product Owner/Customer to get their acceptance. Bear with me, though, and let’s use this common term.
So, a Product Owner, a Developer, and a Tester walk into a bar sit down to talk about something that the system under development should do. The Product Owner describes the user story. The Developer and Tester ask questions (and make suggestions) until they think they can answer the basic question, “How will I know that this story has been accomplished?”
No matter how or when it’s done, these three amigos (to borrow a term from my friends at Nationwide) must agree on this basic criteria or things will go wrong. Turning this agreement into an automated acceptance test (or three) gives it a precision that often tests the agreement and uncovers fuzziness or conflicting definitions in the words we use. Automated acceptance tests help us express our expectations.
If you don’t use automated acceptance tests, how do you clearly communicate desires (”requirements”) between the business, the developers, and the testers?
If your testing is manually executed, or is automated using record-and-playback, then you’ll have the problem where the testers have to wait until the developers think they’re done before they can start verifying the functionality. This puts the testers behind from the very beginning. It also delays the feedback to the developers when the functionality doesn’t behave as expected and results in bug-fix cycles on code thought to be complete. These things combine to slow down the pace of development.
It’s more valuable to automate those tests while the code is still written. As development proceeds, you can see those tests start to pass, providing a clear indication of the progress. If a developer writes code expected to make a particular test scenario work, but the test fails, then you can delve into the issue right away. Is there a mistake in the code, in the test, or just a lingering disagreement about what we intended to do? Automated acceptance tests express the growth of functionality in our application.
If you don’t use automated acceptance tests, how do you monitor the progress of development?
Once the functionality works, we want it to continue working, unless we expressly decide it should work a different way. If we want to know that it continues to work, we need to verify that. That means that we need to continue to check a growing amount of functionality. If that checking requires significant human effort, we’ll soon be overwhelmed by it and our progress will get slower and slower.
Computers are great for doing our repetitive grunt work. Yes, it’s a continually increasing job for them, too, but they’re usually faster than people, they can work longer hours, and they can easily scale to handle more work by adding hardware. If computers are checking that all of our tests are still working on a daily or more frequent basis, then we rapid notification when we’ve accidentally broken an old feature. Automated acceptance tests express our confidence that the system continues to work.
If you don’t use automated acceptance tests, how do you maintain confidence that the system still works?
If you don’t use automated acceptance test, please let me know the answers to these questions–especially the last one.
by George Dinwiddie at 2009-06-17T23:04:14Z
by Sammy Larbi at 2009-06-17T17:31:17Z
by Sammy Larbi at 2009-06-17T17:26:39Z
A salesman from G2 Test Labs just called me. He said he was from India. He wanted to know if my testing company needed to partner with an offshore lab like his. I’m writing this now, while the memory of the conversation is fresh.
After he made his brief brief opening monologue I asked him “I’m a testing company. Why are you calling me?”
“Maybe you want to have an offshore arm.” He said.
“Well that depends on the skills of your testers. How do you train your testers?” I asked.
“Oh… we don’t do any training. But our testers are certified by other organizations.”
“Which organizations certify your testers?”
“Uh… I will have to check on that and get back to you.”
“Yes, that’s important information. Are ALL your testers certified?”
“Probably… most of them are.”
“Sounds like you don’t know.”
“…”
“Hey, this will make a funny post. Check my blog in about an hour. Goodbye!”
Now, in fairness, the salesman sounded like he was about 22 years old. Perhaps they sent him to call me as part of some hazing ritual.
[Oh, I just remembered, in his opening statement, he mentioned that his company was ISO-9001 certified, too. Wow. That takes me back to 1992, when I was fighting ISO-9001 certification. That certification program turned out not to amount to anything, either.]
by James Bach at 2009-06-16T22:53:38Z
A pizza of radius z and thickness a has volume pi*z*z*a
Per Jens Ohlig, twitter “johl”
by Ron Jeffries at 2009-06-16T22:12:44Z
2009-06-15T22:05:39Z
Matt Heusser wrote an interesting post about “boutique testers.” I like the idea of boutique testers (boutique intellectuals of all kinds, actually, which is why I wrote my new book.) And I am an example of one. The testing I’ve done in recent years has been mostly on court cases or part of coaching testers, though. I want to do more ordinary testing. I need that in order to keep up my practice.
I live on an island, making travel expensive and annoying. But I have a great Internet connection.
There are important challenges to being a remote tester, though. The main technical problem, in my experience, is acquiring and configuring the product to test. Getting up to speed fast benefits from being onsite. The main social problem is trust. Hiring a remote tester, especially one who’s supposed to be high powered, is a little like hiring a therapist. In my experience, developers feel more sensitive about a well-paid, high status outsider poking at their work, than they do about an internal tester who probably will disappear in a few weeks.
Then there’s communication. Despite all the tools for modern communication, we haven’t yet developed a culture of remote interaction that lets us use those tools effectively. Even though I’m always on Skype, and people can see I’m on Skype, they still ask permission to call me on Skype! And I also feel nervous about calling other people on Skype. They might be annoyed with me. I do use GoToMeeting, and that helps a lot. Michael Bolton and I have been collaboratively writing, recently, using it. We like it.
Finally, there is one big logistical problem: availability. You can call me up and have me test for you. But, being a fully independent consultant, my time is chopped up. I have a week here and a few days there, usually. This is the main reason I go in for short-term consulting and coaching. Unless a rich client comes along and induces me to clear my schedule, I can’t afford to have only that one client.
Still, with the price of travel so high, I think this is the direction we need to go: each of us developing ourselves into unique thinkers with strong brands, and then remotely connecting (interesting oxymoron, eh?) with our clients.
Phone: 360-440-1435
Email: james@satisfice.com
Skype: satisfice
by James Bach at 2009-06-15T21:09:43Z
Paul Relf is a Scrum Product Owner at Nortel and one of the few people I’ve seen that really gets the role of product owner. In April he gave a presentation at Agile Ottawa that I missed, luckily for all of us Fred Dixon, recorded the presentation on video and the results are now up at the Code Factory: The Product Owner.
If you enjoyed this post, subscribe now to get free updates.
by Mark Levison at 2009-06-15T19:45:47Z
We humans like to take a very soft cloud of ideas and give it a name, such as Waterfall or Scrum or Lean or Kanban, in an attempt to get a better handle on some good ideas. We also seem to have an irresistible impulse to describe how good our Named Cloud is compared to some other Named Cloud. I imagine part of this is no more than a normal desire to share our Internal Cloud with others, so that they may benefit. Sometimes we seem to go overboard with that, to Named Cloud Bashing.
“Kanban is better than XP because Kanban has more WIP.”
“XP is better than Kanban because in XP we have actual programming.”
Sometimes it seems that all this revolves around personalities. I know of a small number of people who appear to me to think Scrum is bad because they don’t like Ken. There must, therefore, be hundreds of people who think XP is bad because of Yours Truly.
Trouble with clouds is that they change. They even run into each other as the wind blows them around. That cloud you stupidly thought looked like a bunny ran into my cloud that looks exactly like a dinosaur. Now it looks totally like New York, and you foolishly insist that now it is a big dinosaur-eating bunny.
“Is it still Scrum if we use a kanban board instead of a burndown?”
“Is it still XP if we don’t break things down into tasks but just use stories?”
The question we ought to be asking is whether, if we adopt this idea from wherever we found it, will we do better than if we adopt this other idea. The absolutely best way to determine this is to try it. We can get ideas from experts, even if they happen to be proponents of Other Named Clouds Which Shall Be Anathema.
The process wars have gone on more than long enough. It doesn’t matter who had an idea, or what process originally contained an idea. What matters is what ideas we apply skillfully and wisely to our situation in order to improve it.
I’ve been helping software development teams improve for a long time now. In so doing, I draw ideas from the whole range of the Fuzzy Cloud Cluster named Agile. I try to give credit where it is due to the individuals who invented this idea, if I know them, or to the authors who best describe the idea.
But that Named Cloud that looks like a Rat today? I don’t think we should care much about that, because the wind is blowing away the front part of it and very shortly no one is going to give a Rat’s Ass about what it used to be.
by Ron Jeffries at 2009-06-13T13:42:52Z
by Esther Derby at 2009-06-12T22:18:18Z
My talk at the Rose City SPIN last night went very well. We had a small core of dedicated people. Lots of good questions and we could dive into the specifics. Thanks to Rhea for doing a great job organizing the event.
You can find my presentation here.
I also wanted to provide some links to some of the books and sites I referred to during the talk.
by Wayne Allen at 2009-06-12T22:12:00Z
2009-06-12T17:16:00Z
2009-06-11T20:57:00Z
2009-06-11T20:57:00Z
A newsletter is much like software – if you create a larger batch of items, the work grows more than linearly (editing, translating, scrolling, selecting). It’s still worth it though – creating the newsletter on a regular basis helps to reflect on what we’ve done, but also creates focus: what are we going to do or research to make the next one interesting…. The positive response we’ve gotten so far also helps. Marc was kind enough to create a wordle to reveal more of the content:
Maybe because of the delay (we skipped May eventually) we not only have more items, they are also longer. We try to keep the newsletter short, but the things we discussed at conferences and while making the product development training gave us some inspiration to explain some topics in more detail. If the topics pique your interest, you can read it online or subscribe.
by Willem at 2009-06-11T20:18:45Z
On a recent trip to Las Vegas, I picked up The Four Hour Workweek for my Amazon Kindle to read on my flight. When I came back from my short vacation, I decided that I was going to change how I approach email on a daily basis. In my position, I receive a lot of business-related emails on a daily basis, whether that be from employees, clients, or potential clients. A typical day would consist of me trying to get a few tasks done while keeping an eye on any new requests. This resulted in a lot of context-switching and my days were extremely fragmented. Our team had started an experiment where we’d track all of our time throughout the day on printout. Our goal was to log all of our start/stop times for each activity and also capture each interruption within those time windows. After just a few days of doing this, I was noticing how much time was being spent on emails each day. I also noticed that it was rare to have a full hour of uninterrupted work on a single activity. Aside from distractions that you’d typically find in an office environment, email was keeping me from attaining the level of focus that I was seeking on my work.
So, using some motivation from The Four Hour Workweek1, I opted to come back to the studio and change my behavior. That morning, I emailed my entire team and my clients to let them know that I would only be checking my email at 10am and 4pm each day. I explained that they could call me at the studio if there was something that needed my urgent attention. Admittedly, I was nervous as I hit send. What was I getting myself into? What were my clients going to think? Would they think that I’m just an unorganized mess?
Three weeks later…? It was one of the best emails that I’ve sent in ages.
Here are a few realizations and conclusions that I’ve been able to attribute to this change.
Before I made this decision, I came up with a lot of excuses for why this was a bad idea.
In three weeks, none of these things has bitten me in the ass. It hasn’t been perfect, but I don’t believe that it’s had any significant impact that outweighed the benefits.
I spend less time on email than I did before. Why? I don’t treat email the same way that I used to. As a result of approaching email differently, I noticed that I am now more likely to keep my emails short and sweet… and most importantly, to the point. One of the great things about Gmail is that it’s made it easy to have conversation-style emails with people, but it’s also made it too easy to have conversations with people. I now realize that so many conversations that I would participate via email would entail single sentence questions/responses with similar length follow-ups. Each time you come back to that email, your attention is on that conversation and those can eat up a lot of time if you’re not careful.
So, now that I’m checking email twice a day, I tend to write only what is necessary to move the conversation forward until the next time I check my email. As a result, email conversations are slower now, but they aren’t taking as much of my time. The benefits have outweighed the negatives.
Since this change, there has been a handful of days where I have been able to focus completely on a single activity (task) for over a hour at a time. My record was nearly three hours one morning early last week. Unfortunately, I completed the task I had budgeted five hours for was finished in less than three. ;-)
I’m able to do this more now because I’ve been able to release my check-your-email-again-just-to-be-safe demons. I’ve been able to trust my system and I’ll share some tips on how I eased myself into this.
More focus time has allowed me to spend less time working on individual tasks because they are subjected to nearly as much context-switching.
Another benefit that I’ve seen since this change is that with this time that I’ve salvaged, I find myself with more time to be creative. I haven’t pinpointed what the reason behind this is, but I do feel like I’ve been more creative the past few weeks than I have been for the several months prior. Perhaps it’s just a side-effect to altering my workday… or that I don’t feel like a victim to the INBOX… or that it’s been extremely sunny in Portland… or that I’m more aware of how I’m spending my day.
Whatever it was, it started within days after I implemented this new approach to managing email. I’m happy to attribute it to this for the time being. ;-)
Here are a few things that I did to start this process. Credit is due to Tim Ferris for suggesting most of these and here are some of my further thoughts.
Chances are, you don’t have as many as you think you do. I started with the critical ones and really weighed the pros/cons. It’s safe to use the, “Will anybody die if I do this?” question to help you respond to each of these. You can be a little less cynical and ask yourself, “Will we go out of business if I do this?”... or “Will we lose client X if I do this?”
Then ask yourself, “Is it unreasonable for me to do this?” If the answer to, “will we lose client X if I do this?” and this don’t match up, you might want to re-evaluating your client roster. If your clients are reasonable people, they’ll see that there is value in this that will benefit both parties. As I mentioned, just remind them that they can call you if there an urgent request. If they abuse this, straighten them out or it’s time to re-evaluate your client roster.
It’s not unreasonable to protect your time as much as possible, despite how much they pay you.
You can’t just say, “I’m only going to check my email twice a day.” There isn’t any way that I would have been able to honor such a commitment. “When exactly?,” is the obvious response to that.
I set a scheduled event on my calendar that happens everyday at 10am and 4pm. I have a 15 minute notice on that event so that I’m reminded that it’s time to wrap up what I’m working on. When I have a conflicting meeting, I will just reschedule my email for another time of the day. The time is visible to all of my teammates and my clients know when I’ll be catching up on email.
Why did I chose 10am and 4pm? Well, I start my day at the studio at 7am. This allows me to have up to three hours of time to focus on getting other things done before tackling email. Why 4pm? This is a hour or so before I leave for the day. Email isn’t the first or the last thing on my mind at each ends of my workday.
This will not work if you don’t set peoples expectations. If people are accustomed to you being extremely quick to respond to emails and you change your behavior all of a sudden, you’re going to freak them out. Let them know what you’re doing, why you’re doing it, and you might even encourage them to consider it too. More often than not, everyone you work with is feeling overwhelmed and wants more control over their day. Send them a link to this post. ;-)
It all comes back to managing their expectations.
Seriously, quit that application when you’re not using it. In fact, quit any program that is open when it’s not related to the activity that you’re focused on. For email, we use Gmail for domains and I run it through Fluid. This means that at 10am and 4pm, I launch the Fluid app and start working my way through emails. Once I get through my inbox and finish what I need to handle right now, I quit it.
Also… disable email notifications. They aren’t worth it.
I’ve been practicing the habit of keeping my INBOX empty for nearly a year. Everything gets labelled, organized, and archived properly once I open up each email. Some stuff gets sent to Highrise to respond to later while some emails get an immediate response.
One of my favorite things about maintaining Inbox Zero and checking my email twice daily is that when I open up my email client, I’m faced with a list of nothing but unread emails. Since I know they’re all unread, I can start at the oldest and move my way through them, one by one. When I get to the end of that list, I’m almost done. I then fire up Highrise to see if there is anybody to get back to today. If so, I fire off those emails and close off those tasks. Once I have both lists completed, I’m done.
The one thing that I’m working on the hardest right now is not cheating. I’ve caught myself a few times. I’m waiting in line at the coffee shop and I pull out my iPhone. Out of habit, I launch the Mail.app and find myself looking at incoming emails. You might argue that if you’re not in the middle of something, it’s a good way to feel useful, but I’m sure that there are other things you can be tackling. Your email will be there at 10am… I promise.
The biggest problem with cheating is that if you see that someone responded to something you sent in your previous email, it’ll force you to make a decision. a) do you look now? or b) look later? If you choose b, your brain is going to be wondering what she said. It’s can really bug you for a few hours. Trust me. :-)
It’s only been three weeks since I adopted this and I know it’s far from perfect. However, I assure you… it’s been worth the self-proclaimed risks. I enjoy my email time more than I used to. As I mentioned earlier, I like being presented with a healthy list of unread emails to work my way through. Sometimes it takes only five minutes to get through them all, sometimes a hour or more if I have a lot of people to follow up with.
It’s been a fun ride so far and I’m sure that there are many more challenges ahead, but I am planning to stay on course. Who knows, maybe I can move to once daily after a few months?
by Robby Russell at 2009-06-11T01:33:05Z
As if delivering projects wasn’t hard enough. Delivering projects on time is even harder. As practitioners, we’re all responsible for measuring up the obstacles in front of us and are accountable to those measurements. At least, we should be.
One of those measurements is time. Time is a funny thing. People have a lot of interesting things to say about time. Some say that it’s one of the most valuable things that we have… but I’ll avoid diving into a philosophical discussion for now.
What I wanted to talk about was project estimation. Specifically, estimates for deliverables. For the past several years, our team has put a lot of effort into becoming more accurate in our time estimating skills. Despite analyzing how often we over and/or underestimate the time each of us believes it’ll take to complete a task, we find ourselves coming back to the drawing board.
A few things that we’ve learned.
When we began to step back from this and look for patterns, we found that several of the tasks that we would budget hours for (versus estimate hours for) were proving to be more accurate. This approach is most commonly known as timeboxing. With timeboxing, we can place a dollar value on a specific task and work within that constraint. For example, with our clients, both parties can come to the conclusion that, “we believe that it’s worth up to $800 to implement this new functionality.” With that, we’re able take that dollar amount and figure out how many hours to box ourselves within.
The underlying question to our client with each change/feature request is, “How valuable is this to your business at this point in time?” Whereas, with a typical approach to time estimates, a client comes to you with a list of changes/features and you provide them with time estimates. “We estimate that it’ll take 6 hours at $200/hour for feature X and we’d do it like this…” The client will have to evaluate your estimate and figure out if it’s worth $1200 and make a decision. They can respond with, “no, that’s too expensive, can we do it for less?” The following steps would entail your team trying to find ways to reduce your estimate.
While these two paths might seem very similar, it’s been my experience that the standard approach to estimating takes more time for negotiating the terms of the agreement.
However, with timeboxing, you are asking your client to provide you with an initial budget. This will completely change how you respond to the feature request. When you have a timebox, from the moment that you begin to evaluate the request, your brain will add the necessary constraints to keep things within scope.
Through this process, we’ve revamped our estimating process so that as we’re building our iteration costs for clients. For each deliverable, we break down a series of objectives/tasks and apply timeboxes to each of those while knowing what the budget is for the deliverable as a whole. Usually, the deliverable is directly related to the request that came from our client with a budget. The process is completely transparent and our team is responsible for working within those constraints.
..and as we’ve learned from Ruby on Rails, constraints can be extremely beneficial.
While I don’t have all the answers yet, my goal is to share some of my experiences and lessons on the topic. I’d love to hear about how you’re adopting timeboxing in your project planning and estimating process.
Anyhow, just some thoughts that I wanted to share. More to come…
by Robby Russell at 2009-06-11T00:05:41Z
2009-06-10T14:04:00Z
2009-06-10T14:04:00Z
Two “facts” heard on the radio today:
by steve.freeman at 2009-06-10T12:25:19Z
I’ve released a new video, which is a whimsical look at a serious subject: explaining exploratory testing.
In the video, my brother and I independently test an “Easy Button” for 10 minutes. Neither of us had seen the other’s test session. Then I edited the 20 minutes of total testing down to a 4 minute highlight reel and added subtitles.
The subtitles are important. One of the core skills of excellent testing is being able to reflect upon, describe, explain, and defend your work. The rhetoric of testing is a big part of Rapid Testing methodology.
So, everything we did, we can explain. If someone stops me when I’m testing, I can give a report on the spot, in oral or written form, and I can put specific technical terminology to it. In my experience, most testers are not able to do that, and there’s one major reason– they don’t practice. It does take practice, friends. While you were enjoying your Sunday, my brother and I were challenging each other to a testing duel.
You might quibble with me about the specific terminology that I used in the video. Indeed, there is a great deal of leeway. One single test activity might simultaneously be a function test, a happy path test, a scenario test, a claims test, and a state-transition test! There’s no clean orthogonality to be found. And as you already know if you read my blog, I reject any “official” lexicon of testing. But I’m not just throwing these terms around, I can explain each one, and say what is and is not an example of it.
What about the Easy Button?
Our principal finding is that the Easy Button is extremely durable. I’m surprised at the high quality of the fit and finish. Also it feels solid (I discovered why when I disassembled it and found apparently lead weights inside. Plus, the button surface is amazingly resilient to repeated hard blows with a rock hammer).
But I’m also surprised that it claims not to be a “toy.” Of course it’s a toy. Of course little kids will play with it.
If I were seriously consulting about testing it, I would probably suggest that its physical qualities were more important to validate than its functional qualities. There appears to be little risk associated with its functionality. On the other hand, there appears to be little risk with its physical qualities either.
I would suggest that it’s far more important to test the web version of the “Easy Button” than the physical version. I would move on to that.
by James Bach at 2009-06-10T08:14:41Z
by Sammy Larbi at 2009-06-09T11:06:38Z
This post has been stewing for a little while, and now I’ve been kicked into writing it up by Naresh Jain’s post on Lessons Learnt from Restaurant Business.
Since Channel 4 in the UK started supporting the Mac for their online replays, I got hooked on Gordon Ramsey’s Kitchen Nightmares series1. I’ve never worked in a restaurant and I know that TV programmes are a manufactured narrative, but (inbetween all the swearing) there are some interesting themes that come through every week:
I know it’s relatively easy to come in and see how to rescue a business that’s months away from failing, after all an outsider has the advantage of not having been sucked into the mess. But, even through the box of mirrors that is TV, Ramsey shows two strong drives: total focus on providing the best service to the customer, no excuses; and, total respect for the craft of cooking. He just lights up when he finds a junior with ability and enthusiasm.
Somehow, I feel this ties in with a post from another coach given to immoderate use of language, Mike Hill wrote about how raising your internal quality makes you go faster. I think there’s a commonality of purpose there that we should take note of.
1) I mean the UK version of this series. The US series is like a boil-in-a-bag version: manufactured, over-spiced, unsatisfying. In fact, the opposite of everything Ramsey is promoting. But that’s another story.
2) Yes, I know there have been some “scandals” with Ramsey’s London restaurants, but that doesn’t invalidate the point.
by steve.freeman at 2009-06-08T23:03:40Z
Twitter is fun, c2.com is almost dead and blogs have a lot of great ideas, but the best discussions about Agile still occur on the mailing list. Yet I keep coming across people in interested in learning about Agile who don’t know about the mailing lists.
What follows is the mailing lists I know of (most of which I subscribe to). BTW I don’t recommend subscribing to this many mailing lists your mail volume will be insane (mine is about 300-400 messages a day), I can only handle it because gmail collapses long conversations into a single thread.