Archive for category agile
The usual suspects
Whenever I’m presenting anything, I try to start off showing the “Top 20 replies from a programmer when their programs doesn’t work”. In case you’ve never seen it, here it is:
- It works on my machine.
- Where were you when the program blew up?
- Why do you want to do it that way?
- You can’t use that version on your system.
- Even though it doesn’t work, how does it feel?
- Did you check for a virus on your system?
- Somebody must have changed my code.
- It works, but it hasn’t been tested.
- THIS can’t be the source of THAT.
- I can’t test everything!
- It’s just some unlucky coincidence.
- You must have the wrong version.
- I haven’t touched that module in weeks!
- There is something funky in your data.
- What did you type in wrong to get it to crash?
- It must be a hardware problem.
- How is that possible?
- It worked yesterday.
- It’s never done that before.
- That’s weird…
I’m not quite sure who wrote it originally, but I was given a paper copy several years ago. I must admit I had a good laugh at the time, as I could relate to most of the replies.
So whenever I’m presenting this list, there’s a giggle and a great deal of nodding and smiling going on in the audience. Then I go on to present something that will alleviate one or more items in this list.
But it’s not a laughing matter! It’s the sad state of our beloved profession we’re laughing at. It’s not supposed to be like this.
When I’m presenting the list in 10 years from now, there’s not a giggle. Not a smile. Just silent shame of times past or loud laughter at good ol’ days. Hopefully no one doesn’t even recognize the items on the list.
I might have a different kind of list. But not this one. We have made progress.
What to do next
So I propose this list as the metric for how mature your development organization is. Same rules apply as in the wtf code review metric. Less is better. Drop the Joel test. Drop the Nokia test. Drop test X. Use this. Now!
The worst part of this is that most of these are solved problems. Test Driven Development, Continuous Integration, and Pair Programming have existed a decade. Their poorer, but still useful cousins, Unit Testing, Automatic Builds, and Code Reviews have been around the block even longer. Iterative and Incremental development, Miniature Milestones, and Review and Adapt has been grown ups for a while as well.
So there is no excuse. The answers are at your doorstep. But it takes discipline. And time.
But you’re not alone. I’m off trying to do my part. Our mission is clear. Will you do yours?
I arrived Tuesday at NDC2008 full of anticipation and excitement; there were a lot of great talks scheduled as I could see it, and I had trouble choosing which ones to attend. I almost immediately found some old colleagues and class mates, which I hadn’t talked to in several years. That was really an added bonus, and I really appreciated the little "reunions".
Scott Hanselman started the show with a keynote, showing us a little LINQ and the new Dynamic Data-bits. Hanselman was witty, and was a great presenter. There might have been a couple of things that did go to fast if you hadn’t seen a lot of .NET 3.5 before, but I guess most got at least a glimpse of what it can do.
After the keynote I was considering several sessions, but I decided to attend Mary Poppendiecks first session titled Thrashing. She went through the reasons for them, and what can be done to remedy it. As a reader of the Mythical Man Month, Slack, Peopleware, and others, I found she conveyed a lot of the same information found there, and I really share their views. A new aspect I hadn’t thought of before was queuing theory, which we apply consciously to hardware and related problems, but seldom to team and people dynamics. I will make a follow up post on the matter.
I’ve lately dabbled with some reflection, so next I attended Roy Osheroves talk Deep Reflection, hoping it would be as deep as promised (level 400 session). It certainly was, and I’m glad I’ve recently been looking at both Reflection.Emit and CodeDom-programming. It also helps to extensively take advantage of the vanilla reflection utilities regularly. This was a prerequisite, but it seemed like a lot of eyes glazed over when it was presented. He ended the session with a song, and I think he did his presentation on this heavy topic in a great way.
Supposed to be doing a talk about agility in Typemock (the firm), I gave Roys next session a chance. But the agenda had changed and we were introduced to Designing for Testability. I had this part mostly under control, so I was a bit disappointed that the original talk was exchanged. It was an introduction to IoC, DI, and IoC-containers, as well as our options when designing for testability with mocks or subclassing. This session ended in a song as well, and the lyrics was funny as always.
There was unfortunately another change in the agenda, Roy had originally a Threading-talk I’d like to see, but it was changed to a Testing your data access layer session. With this change, I attended Mary Poppendiecks talk on The Role of Leadership in Lean Software Development. Contrary to popular belief in most Agile circles, she thinks there is a place for leaders, not only self-organizing teams. I must admit that this is something I’ve personally experienced as well; when everyone is responsible, no one takes responsibility. I won’t go into more detail here, but I think it was a great talk, and she definitively hit home many points with me.
I start out attending an Agile Panel discussion hosted by Scott Hanselman, featuring Mary Poppendieck, Roy Osherove, Ken Schwaber, Chet Hendrickson, and Ron Jeffries. An example topic was what are the first steps to become agile. It wasn’t that much of a discussion really, as all the panelists believe in the Agile values.
The next two sessions I followed the Agile crowd in general, and Jeffries & Hendrickson in particular in their first two talks about Natural Laws of Agile Software Development. They presented the same material I saw from Smidig (Agile) 2007 on the economics of releasing early. I think it shows the potential payoff of releasing early, but it misses some aspects of going to early into maintenance mode with the software. I think this has to be explored some more. After showing these teasers, they went more into how early and frequent releases can be done baking quality into the process through the means of TDD and Acceptance Tests.
While I was humming along with Ron & Chet, it seemed like Roy got quite a following. It was almost impossible to get a seat on his Advanced Unit Testing session. It really seems my fellow Norwegians are good & ready for some ALT.NET techniques & practices, especially unit testing. I eventually got a seat on the session, but I must admin I personally was a little bit disappointed as I’ve already been down most of the roads before. Hopefully it was another teaser for all those who are thinking of getting into the whole unit testing business.
Next up, I attended Mads Torgersens Microsoft LINQ Under the Covers: An In-Depth Look at LINQ. And under the covers it was indeed. He gave us a great peek into how a LINQ-expression was disassembled, and showed us the output through Reflector. I must admit it was hard to follow everything, but I was at least familiar with all the constructs. All in all a mindblowing experience, and Mads gets credit for his enthusiasm during the session.
Finally, I attended Mary Poppendiecks session on The Discipline of Going Fast. We got new insights into the Toyota Way, a little bit of history, and specifically the Stop-the-Line practice. I definitively will continue this flirt the Lean methodologies.
I’m very pleased, and I was exhausted after two days packed with great content. The only thing I have a complaint about is that a couple of Roys talks should have been moved to accommodate the massive interest his topics achieved.
I must thank the hosts for a great event, and I will come back next year!
I’ve just returned from an arrangement hosted by The Norwegian Computer Society, called Software 2008. I attended the “Agile methods in practice – What is it and how to do it?” full day seminar. (NB: The last two links are only available in Norwegian!).
Here’s a short review of the day.
The first talk was given by Aslak Hellesøy. He gave a general and a bit historical view of the agile methodologies. He spoke well, and had good anecdotes in his speech. I liked in particular the little story about how cargo cults came about, and how we see them all over the place today in the software industry.
The second talk was given by Trond Pedersen and Nils Christian Haugen. They had an original take on their speech, it wasn’t even a speech; it was a role play. They guided us through some typical scenarios in a software development project and showed the agile aspects of it. I think it was a bit contrived, but a think they got across some good points.
The “long” sessions are now history, and we’re given a serious of Lightning Talks. The topics ranged from how “GUI prototypes are evil” to “how to delete production code”. The two talks I enjoyed the most was from Kaare Nilsen, and the one from Trond Wingård. The first because of his charismatic appearance, and the second because of its great topic on present value effects with incremental delivery in agile projects. This could be a real eye opener to just about anyone.
The seminar crowd paired up with each other and interviewed each other to form mind maps. The topic was how we could introduce agile methods in our own organizations.
After a slow start with some standard awkwardness we managed to get some drawings and text down on paper. It was an ok exercise, but I’m not really sure I have any real use for it.
Here most of us was introduced to a concept called “open spaces“. I have heard of it before, but have not been a participant in such an endeavour. A range of topics from the days agenda was thrown on a flip over and we sat in on which topic we would find most interesting. Well, you could either have an “engaged foot”, or an “interested foot”, or both to participate in any given topic. But if you found yourself twiddling your thumbs, you just wandered off to another space to see if you would get any “feet” there.
I sat in on a topic about what agile practices does and doesn’t work, and I think we had some interesting discussions and got to poke a bit into the material. The session was a bit on the short side, but I certainly grew fond of the concept.
All in all, it was a good day, and I got some good input which I will take with me to my own organisation.
I liked the discussions and mingling the most, and I’m definitively going to engage more in such events.