I just came across a video recording of “The Canary in the Coalmine” from Agile 2006 where Ken Schwaber discusses the factors involved in getting companies to realize that software is a Corporate Asset. My conclusion, having seen many of the same effects in a number of companies, is that most of the decisions about projects status, schedules, delivery dates, features suffer from the same problem; they are not based on facts, or at least not on all the facts. For example, which is one of the main points in Ken’s presentation, the future cost of not having software that is well-kept, which in turn is a direct effect of pushing deadlines and increasing feature sets.
As a case in point, Ken’s anecdote from the “$14M, but just some features more” situation, is an example of how easy it is to make enterprise level decisions without hard facts, and what it might lead to.
Bowling Kata “solution”
One of the most famous katas (excercises) for TDD (test-driven development) is the Bowling Kata. There are some sites that describe the Kata, which has the following “stories” as input:
- A bowling machine want to report the number of pins the player strikes down for every roll the player does
- A bowling player want to see the resulting score of a completed game
It is actually a rather simple Kata, but never the less allows for demonstration and training of some TDD tasks and strategies. But of course you need to know the bowling rules…
We have used the Bowling Kata for our Coder’s Dojos, and have learned a lot from it. The following is a recording of one of my solution to it :
Geek Test
Well, it has been far too long betwen posts now. I’ll try to fix that, but The Life Puzzle is not easy to put together, especially since our company is now picking up steam. More and more leads, and more of them seems to lead to actual business. But I suppose that is actually a problem to be happy about!
So, as the first thing I stumbled upon the New Geek Test, which I could not refrain from taking. So here’s my grades:
Refactoring with red bar?!?!?
We have been running the Coder´s Dojo Sweden during the autumn, and yesterday we started the spring sessions. One of the interesting observations that we have made is a follow-up on a comment that I made on Robert C. Martins page about the Bowling Kata.
The observation was that if you follow the rules “refactor only in the green” (you may only refactor while you have working and passing tests as your life-west) and “only develop new functionality in the red” (while you have a failing test for that functionality), you will inevitably end up with a situation that your new functionality driving test case forces a re-design, right?
It may be obvious to most of you out there, but we couldn’t find a single mention of how you are supposed to solve that predicament. We surely do not want to do a redesign with a failing test, the green bar is our safety net. Of course you could keep an eye on which tests are causing the red, but that is tedious and error-prone.
What seems logical is to temporarily get rid of the failing test, which you can easily do by commenting out the failing test. Simple, right? And possibly second nature to seasoned TDD:ers. But if so, why has there been no developmen of tools support for this? I could easy envision a “disable test” feature in the Eclipse/JUnit GUI…
CHAOS or not?
The CHAOS reports from the Standish Group has become infamous, so much so that Sean Hanly made us promise to never quote the figures as evidence against the traditional models. However I recently found an interview that Deborah Hartmann at InfoQ did with the Standish Groups founder and chairman Jim Johnson. In the interview Deborah asks some really interesting questions and Jim’s answers seems straightforward and honest. The relatively fresh statistics presented is interesting, but most interesting of all is the list of success factors, where it is obvious that the Agile values and methods addresses most of the top 10 with concrete techniques.
What is “Agile” all about? Really?
This is actually post that I did over at forum.agilesoftwaredevelopment.org in a tread with the above name. Finally I was prompted to articulate some of my thinking around this “popular” issue.
Ursprugligen inlagt av RonJeffries
Originally posted by red2
Wouldn’t you also say that Agile was a framework for enabling intuition to be quantified within an environment which prefers more empirical measurements? After all Agile would seem to be about divesting control from procedure to people.I would certainly agree that agile is about moving the center of control away from procedure and toward people working together.
I would also say that partof what Agile does is enable “intuition” to be applied.
However, I’d want to be careful with the term “intuition”. It’s a weak, and perhaps dismissive term when we use it to describe the combined experience of a group of people, brought to bear on some problem, when they are freed from their cubes and are enabled to work together.
Who am I to disagree with one of the original signatories 😉 but I am not sure that I agree that the “agile is about moving control away from procedure”. I think is actually an effect of the fact that most procedures used currently does not make it easy to become “agile” enough.
What I mean is that since most current procedures are stipulatory, rigid and founded in other values than the “true agile values” (which I’ll come to in a second), they will not be possible to follow to achieve true agility. But there is no inherent conflict in procedure and agility, just look at XP. It is full of procedures, but achieves high degree of agility. Daily stand-ups is certainly procedure!
Agile is not about techniques either. Techniques are, as procedures, just a tool to get to the result, so we must look beyond both to find the “true agile values”.
*I* belive that the true values of agile is what it delivers to the stakeholders of the activities. E.g. delivering software that is usable for purpose, delivering business values or whatever the primary stakeholders require.
The techniques, and tools and procedures, that we apply are only secondary. However, there are some techniques, tools and procedures that we agile people think *must* be applied to deliver on that stakeholder interest, which are different than what we previously have thought, and been taught. Namely, an intense closed feedback loop! To optimize this feedback loop we find that it does not work to do big design upfront, waterfall projects, etc. etc.
Instead, to tighten this loop, we communicate directly with customers and users, develop a single feature at a time, get concrete feedback, and so on. The more we can tighten this loop the more efficient we are able to deliver the best result possible to our stakeholders.
Agile is not about a fuzzy feeling of people getting together. It is based on hard, cold evidence that tight feedback loops are the best way to deliver in this world of constant changing requirements, “I know it when I see it!”, and developing features no one can imagine the full impact of. One of the most important factor in tightening this loop is to get people to talk to each other, but that is not an agile value. It is a necessity to deliver on the true agile value: best possible working software/system/product with the given resources!
Would agile have developed if Waterfall would have worked? I would say no. Agile has evolved because previous thinking did not perform to our satisfaction!
“Pairing with Thomas”
I came across Ron Jeffries book Extreme Programming Adventures in C# on Agile Alliance members page, a book which he thinks should be called “Pairing with Ron”. It’s about the development of a small XML editing tool he did. But it describes every little test, refactoring and other anecdotes that are relevant.
I thought this to be fairly interesting, and since I have just started on a similar journey I though I’d start some kind of log of it here. Of course I have already done some basic things so I try to make this log catch up quickly.
I am trying to build an Object Application Modeller. The basic functionallity is to be able to define classes with attributes, relations and views. I have seen many applications where this is actually the basic functionallity, so maybe this tool exists already but since it’s a journey the goal is not the value, the journey in itself is.
The trick is to be able to “generate” an application from these definitions, with support for persistence of the instances of the classes and relations of course. *AND* with the possibility to upgrade, which will introduce the need to refactor the persistent storage (a.k.a database) on upgrade.
I’m sorry that I will not be able to remember all the steps I have already taken, but here are the initial list of User Stories:
- Define and Delete a Class
- Save an Application Definition and Restore it
- Add a (String/Integer type) attribute to a Class and Delete it
- Create instances of the defined classes (implies deploying the Application)
- Display instances as a table with attibutes
- Select which attributes to show
- Sort and filter data according to specific column
- Define Relations with attributes between specified Classes
- Show instances with attributes in a tree using a specific relation showing attributes
- Show instances with all relations
- Deploy an updated Application Definition to an existing Application
So I started with a test that creates a Dictionary, adds a Class to it and then looks up that same Class. No problems there, implemented the Dictionary as an ArrayList which took Class.
Then save and restore, almost as straight forward. Decided to use a simple text file with one line per Class.
Then, GUI! Since many have talked about thin GUI:s I first decided to use the Eclipse Visual Class editor to just add a simple GUI on top of the functions. That was just somewhat successful. And it felt bad. Why couldn’t I do TDD on the GUI?
Having introduced Automatic Testing of the webapplication in my current project I knew there where a multitude of GUI testers, but I surely did not want to go down the path that lead us to Mercury Quicktest Professional!!
But I found Abbot, “A Better Bot”! It drives and inspects Java GUI, and JUnit functionallity to boot! So I added some tests to drive my GUI components, and of course I had to refactor those a bit to make the testing easier.
So now I could add tests to drive adding attributes. And since I implemented those as ArrayLists too I refactored out an ItemList to hold Items which became a super class to Class and Attribute.
I have just added a test to drive adding attributes from the GUI. The first test is to select a Class, press the Edit button and ensure that an “Edit Attributes for Class” window appears. And that’s where I am now.
To be continued…
Fifth Dojo, and still learning…
Today we ran the fifth Coder’s Dojo. Still the same Bowling Kata in Java and Eclipse (oh, I love that IDE!). This time we where only four, which allowed each of us a lot more driving time, which was fun.
This time we managed to get through the whole Kata, and even found some time to discuss one of the issues bothering some of the participants already from the start, namely error checking. Andreas and I went down that path while on the flight from the Agile Business Conference 2006 and had some learning to share. The main point being that error checking, like checking for score() being called before the game is finished (remember, the user stories actually calls for the game being finished) has to be made explicit, obviously driven by a user story (the user in this case being what ever actor is interested in such a message).
But, the most interesting thing was that we where very explicit about doing a refactoring to get a design which is better suited to fit new functionality into. I think we actually made a few steps better than Uncle Bob’s original. That feels nice 😉
Back from the Agile Business Conference
Well, we’re back. We participated in the Agile Project Leadership Network Summit as well as the actual ABC. Being three of us we managed to cover most of the presentations. Of particular interest was the British Telecom decision to transfer their 14000 persons IS/IT business to Agile. There where some ups and some downs, perhaps I’ll transform my notes into a blog entry in the near future.
Responsive Going to Agile Business Conference
All of us (all 3) are going to the Agile Business Conference in London on 7-9/11. Initial day will be Agile Project Leadership Network Summit. We hope for some interesting presentations and workshops.