The only reason you would probably care about who I am is I was the token tester at the group, the workshop that created the manifest for Agile software development. It is my belief though I am not 100% certain that my entire contribution to that effort was the word manifesto which I believe I suggested. Other than that I jumped on testing in Agile projects, as something I wanted to work on, and I have been working on that more or less ever since, though I am currently drifting away from testing hoping that wiser and more level headed people will take over the mantle of Agile testing.
2. What is micro-scale retro-futurist anarcho-syndicalism?
One of the reasons for the workshop that created the Agile manifesto was that these various methods that different people had been working with in the past, like XP and Scrum and so on, and so forth had the umbrella term for them was light weight processes. And there were some people who felt that light weight doesn’t have the best possible connotations if you are trying to get people to take you seriously. So one of the outcomes of that workshop was coining the phrase in marketing term Agile, which has been widely successful, and possibly too successful, one of the reasons it has been possibly too successful is everybody thinks they know what Agile means just like everybody thinks they know what testing means and lots of terms. So I made it a practice at times in my career to pick names that are so incomprehensible that nobody can possibly have any preconception as to what I am talking about so they will have to ask. So micro-scale retro-futurist anarcho-syndicalism is a bit of a back to the golden age kind of movement, if a single person can be considered a movement. I am trying to capture and push back again some of the things that I think are hampering Agile today.
One of the main things hampering the movement is success. And success has led to a watering down and at times, of dummying down of Agile values.
4. What does anarcho-micro, whatever it is, have to do with that?
Well it’s a combination of three terms, each of these terms is supposed to be directed to a particular problem in Agile. So which term would you like to hear about first?
5. Let’s see let’s start with the m thing: microscale.
In the past several years there has been an increasing emphasis on Agile, as applied to the enterprise. There has been an increasing emphasis on great leaders with vision, who climb mountains or fly in space shuttles, who will inspire the team and inspire the organization and do this, that and the other. And that is not in fact what I care about and therefore no one else should care about it either. What I got into Agile and the reason I was into Agile was I would go into team rooms and I talked to people on teams, and especially the business people was gratifying, what we would call today product owners, I talked to them and they would say “This is the best project I have ever worked on in my life”. And if you look at people like Ron Jeffries or Ward Cunningham or Eric Evans or a lot of these thought leaders in Agile you can find them tracing their inspiration back to that particular great project which they cannot see any reason why all projects shouldn’t be great that way. That’s very motivating. Nowadays, when I go into teams, especially teams in large organizations, what I am hearing from people is “At least work doesn’t suck now as much as it used to”. Which somehow seems less of an important thing to devote your life to creating: “He helped work suck a little less, but it still sucked”. The micro scale is intended to connote that we need to re-focus our attention on the people inside the team, on their happiness and on their success, and on empowering them and in particular we should stop hoping that someone in the organization the powers that be will reach down and give us permission to do Agile, give us permission to do reasonable things, help us out, we need to focus on the individual one to one scale which is where living a useful life lies.
It includes actual human beings that you interact with in the same way we are interacting with. So, I am not particularly interested in people who are in the boundaries who are just roles, like testers or the most amorphous possible role of stakeholder. I care about Fred and Benji and those people.
7. And what about retro futurist? How does that relate?
I think there is a mistake in the Agile manifesto.
8. Wait a minute: you think there was a mistake in the Agile manifesto?
Yes, there were several mistakes, but one of the mistakes was people and interactions and something over processes and tools. It made tool a bad word, it made tool a weapon word so if you start to worry about things that have to do with the actual, let’s speak softly when we say it “production of code”, people will say “individual action over processes and tools”, you can’t talk about tools, you can’t be excited about tools, you can’t say “ooh, shiny”. Which I think is a good thing, I think we under appreciate the degree to which evolution in raw processing power has enabled the tools that allow us to do this things that are good for human reasons. Like if our computers weren’t fast enough we wouldn’t be successful at a lot of the interactions that we are doing. So retro-futurism is an artistic movement in a way, examples of that include the movie “The Rocketeer” which is about a guy who finds a jet pack, there were something “World of tomorrow”, the movie that was completely generated.
9. "Sky Captain in The World Of Tomorrow”
“Sky Captain in The World Of Tomorrow”, with giant walking robots, and all of these images from the past where when we got to now, we were supposed to have flying cars and jet packs and nifty, keeno things. Kitchens that clean themselves or with anamorphic robots doing the cleaning and instead we get expensive gas and all the disasters we have around us in the world and I think that in a lot of ways the “Gosh! Wow!” attitude that allowed the original Agile people had, when combined with in many cases a late blooming interest in other human beings, was a big part of what made Agile work. And right now what we see in Agile is that tooling and the writing of code and that sort of stuff has much less cache than all of the interaction part and I want to bring that back into focus.
10. And on to my favorite part: anarcho-syndicalism. That sounds really subversive
It is really subversive. Anarcho-syndicalism was a turn of a century movement, quasi-anarchist, quasi-socialist from the overlap of those two movements and it was an anarchist movement in the sense that it wanted the state which is viewed as an agent of oppression, to somehow go away. And the mechanism by which the anarcho-syndicalists were going to make the state go away was through trade unions. So trade unions would be the mechanism by which oppressive forces that made the workers life bad would be gotten away with. So the reason why anarcho-syndicalism appeals to me, two reasons: one is the word anarcho. Especially in the past a lot of the Agile people were referred to by the more heavy weight process people as anarchists. And I think that was true, and I think that we have drifted away from admitting that because the people who will give us money won’t give us money if we are anarchists but if we are something anodyne they will give us lots of money and so we can do what we do. But I think being an anarchist and trying to move in that direction is a good thing. The syndicalist is not because I could ever advocate a trade union because I live in the United States of America and we are not allowed to say good things about trade unions but because I like to focus on the team, I think the team should be a collection of individuals who are providing help for each other, making a good team, one of those projects that you really want to work on. And so syndicalism has that connotation of teams and in some sense the micro-scale is there to remind us that I am really talking rather than the continent sweeping labor movement of the real anarcho-syndicalists I am trying to focus on the individual teams and empowering them. So that is micro-scale retro-futurist anarcho-syndicalism.
12. I can’t even do it as an anagram so I guess we have to leave it as it is.
And I am looking for somebody to develop the logo for it. So if any of your viewers have the slightest bit of visual skill, please contact me.
Well as a matter of fact as the next of my career ending moves, since you are encouraging me to do so, in the past seven or eight years, we have discovered that, as implausibly as it sounds, that testing can be a big contribution to programmers and they can come to love it and the reason they love it is not because they suddenly become masochists it’s because each stage of the test driven design mini cycle provides them with insight, aha!, I can see how I can craft this thing better. Just by way of review, the Test Driven Design cycle consists of me saying “I have got this object I am trying to create with an interface help me think through what that interface should be” and you do that by creating examples of use of the interface which is a test. Then you write the code and often times when you are writing the code the act of writing the code makes you realize something about the example, makes you realize something about something else, so you get another “Aha!” moment. The third stage is the refactor stage and in refactoring you tend to do things like say “Oh this thing over here that I made then is like this thing that I just made now, so I can put those together and often times, sometimes a new idea pops into the world and it gives you leverage as a programmer. So Test Driven Design works really well and a lot of people came up with some obvious extrapolation, which is if it works so well at the individual needy greedy class level, why wouldn’t it work well for product design? So the ideas you haven’t outer cycle of design in which you create a test that says “Here is the next thing we want the product to do as opposed to just a class”, and then the programmers go off and implement that using the inner cycle of Test Driven Design and when that passes they are handed the next test or they collaborate on the next test and you go around that cycle. And you get the aha! moment.
The interesting thing that I have noticed is that it doesn’t seem to work anywhere near as well as unit Test Driven Design, in the following sense: when you design a test, you often get all kinds of insight that is clearly a win. And of course the unit testing all does the same thing the unit testing used to do. But the actual writing of supporting code, that is needed to make that example, that test automated to run without human intervention, very often does not have any of the same “Aha!, wow I am really glad I wrote that code, I really learnt something, it’s my I just written a bunch of code that was boring, and I didn’t learn anything” so there is not the reward you get from writing that code, you don’t get that actual benefit from it in addition from the benefit of having the test. And then to date it hasn’t seemed like acceptance tests, these outside examples, lead to really profound structural consequences like refactoring does to unit tests. So the question I have is if the value comes from the creation of the test, and there is a substantial cost to writing all this code, are we really getting our money’s worth by actually automating those tests? Because if we are not getting our money’s worth with that, why don’t we just make the tests on a white board, have the programmers implement them one at a time, checking them manually even showing them to the product owner manually and when we are done with it, why not just erase it and forget it? Why do we have this urge to save these tests and run them over and over and over again?
Yes there are. And for example Lisa Crispin who is writing a book with Janet Gregory on testing and Agile projects has had a lot of success with this. I am by no means making the claim that this is always a waste of time. What I haven’t said it that it hasn’t had nearly the success, nearly the traction of unit testing. So, we can continue down this path and continue having some people having success some people not having success, we can continue incrementally improving. The question however is: is there another path we can take? And so the other path that I am exploring goes something like this and it does have that tools in there so that will be good. A struggle we had in the Agile testing world for a long time is in the beginning people tended to think that anyone who would do any sort of manual testing was some sort of low grade moron and should not be allowed in an Agile team room and should probably go find a job flipping burgers at McDonalds. And the interesting thing about that was that the backgrounds of a lot of the Agile people tended to be internal IT and they tended to say they never met any good testers before. Over the past few years more good testers have been popping in Agile and it is now becoming close I think to the conventional wisdom that there are two questions you want to answer, with the act of testing. One is I programmer, team intended to do something have I done it? And tat is the role of automated tests. There is another important question to ask, which is “We intended to do this thing, was it the right thing to do? Did we forget to intend something?” And those are the really nasty bugs and those are the bugs that are kind of, many of which are found during the design process, figuring out what things we want the system to do, writing pretty explicit examples for the programmers to implement. But many of them are found only when some human being gets their hands on the keyboard, tries the system out and notices things because just like doing a test drive in a car, you can read everything you want to read about a car, but until you get in the seat and get a test drive, you just don’t understand some important things.
Although I want to say that actually random people aren’t that good at looking around, that’s why exploratory testing is actually a skill trait, because normal people are pretty good at looking at what they are supposed to look at and not so good at paying attention to the man behind the curtain. But let me tie this back into tools. I have this theory: exploratory testing is an overly difficult job, because our systems are not designed to help the exploratory tester to do her job, so for example it’s often the case you would be doing some exploratory testing, you will be going along, trying things out, you will be investigating something and you will say “Oh that was interesting”. And what you want to do is back up in time to the step before then and start playing with little variations. Systems don’t let you back up in time, for those of you who know for example Rails and the design pattern thing, it’s a mistake in my opinion for web frameworks to treat incoming requests as nothing more than a call to a method, they should be using the command pattern so that you can undo kinds of things. Another example is it’s often the case that if you are doing testing of a web application, that you don’t want to look at all the pretty stuff on the screen, I committed a really embarrassing bug in a shipped product, that I didn’t notice and I would have noticed it if I could have said to the application “You know how normally you show the screen with the hyperlinks underlined and the actual URL hidden behind the link? I want you to grey out all the text show me nothing but the http:// www those links and if I have had that different view of the results of an operation I would have not been publicly humiliated, which is good. And that also have implications about system design because of the style the system design is and that is you call a method and it blacks out the string of HTML, is not the right system, you want something more like a builder pattern.
We have to do exploratory testing anyway because we need to find those bugs where “Oh you forgot to do something or Oh you intended the wrong thing”. Now, if our systems were structured for exploratory testing, we’d get a lot more benefit from exploratory testing at a lot less cost. And it is my belief that the combination of let’s call it example driven development where you write your test cases on a whiteboard, you have the programmers implementing them with standard unit testing practices, you have people demonstrating what they have accomplished to the product owner, who then erases the test from the whiteboard and the you have this backend exploratory testing which was very fluid and very fast and very effective, then we are progressively shrinking the role that conventionally automated acceptance tests play. They are producing less and less value so you can take them out and shoot them and not do them anymore. And so my current idea is to shoot off into the fringes of the testing world and explore making systems that are heavily tuned for exploratory testing, build stuff with them and see if that hypothesis is correct. Because in many, many cases the actual automation of automated acceptance tests it’s really a sinkhole, it sucks the fun out of the project. And I think where you suck fun out you suck value out as well.
18. So Brian what’s next for you?
Right now because of my sudden retro futurist geeky interest in tools what I am doing right now is I am working on a book on using Ruby language to program your Mac using the Ruby framework and that is mainly about how Macs work but that is always going to be a lot of my testing content in there, it’s going to be heavily test driven examples I am going to talk about testing user interfaces, unit testing user interfaces which is a common hot topic and the running example that goes through the book, I in fact a prototype of the kind of exploratory testing interface assistant thing, that I was saying we need somebody to experiment with and build. So I am trying to use a single stone to wipe out a whole flock of birds with this book. After that my plan is to go and visit companies that have really got their act together and learn from them because there are all sorts of people out there who know things that I need to know because I don’t know them, and the tentative idea of this book is there will be a blog called Travels and Software with maybe some bizarre cross of travelogue slash technical book so I am going to go and visit those teams and I am going to steal their ideas, and as much as they will let me I am going to sit down and work with them, write up these blog posts and turn that into a book which will convince many people with money that I know things better than perhaps I really know so they will hire me and I will make vast amounts of money as a consultant.
My final words are from my favorite poem by the American poet Robert Frost and they go like this: Nature's first green is gold, Her hardest hue to hold. Her early leafs a flower; But only so an hour. Then leaf subsides to leaf. So Eden sank to grief, So dawn goes down to day. Nothing gold can stay. And in my pessimistic times I am thinking that Agile movement as a whole is subsiding and what I hope is that more people get fired up to recapture its early spirit, as currently exemplified by micro-scale retro-futurist anarcho-syndicalism.