Testing re-Revisited

Last week I went to SCNA: first time, but good conference overall. I may post separately about it, but no promises.

Anyway, Michael Feathers gave a talk titled Testing Revisited in the afternoon of the first day. The basic message of the talk is that we shouldn’t become hostage of our tests: they are just a means to an end and at every step we should be able to evaluate the value that they provide and even (GASP!) delete them when they are not needed anymore. In principle, this is a valid message. When you’re new to something you get to exaggerate and stick to a new principle or to a newly learned technique a bit too much. It may also be a matter of staying in the comfort zone. In fact, every team that successfully transitions to automated testing may be afraid of losing confidence in its code base by reducing the test suite.

Feathers motivations are mainly fed by the idea that he has met several teams reporting to him that at a certain point they felt that their test base was slowing them down. That is to say that the developers had a clear impression that without tests, or with less tests, they would have moved faster. This is already controversial, but there are some elements presented by Feathers which are interesting nonetheless:

• First of all, as a team we should always be able to evaluate the actual utility that every test brings to the table. Tests that used to serve a purpose but not anymore should be deleted from the suite. An example could be a regression test originally written to reproduce a bug at  a big scale, slow and clumsy => if the bug cannot happen anymore by design, then there’s no reason to keep that test in the suite.
• Secondly we should be able to reason about the risk involved in removing any test, especially before scaling a build system that cannot accommodate an infinite growth. More importantly, by reasoning about the risk and the utility of every test we can decide to rewrite them, maybe in a lighter way.

Let’s get to the point of this blog post then. Feathers said something very specific, which was: “maybe we rely too much on automated tests”.

I think that this is a dangerous and ambiguous message. In my experience, the only way to be slowed down by tests is always, absolutely always, no exceptions, because of the code base that is under test, not because of the tests themselves.

What follows is what I tweeted the day of the conference:

thinkingbox While I appreciate some elements of @mfeathers talk I disagree about the sentence: “maybe we rely too much on automated tests” #scna 12-11-09 5:45 PM

thinkingbox Teams who deliver good code and have good practices are the ones writing more tests and suffering less from them. /cc @mfeathers #scna 12-11-09 5:48 PM

thinkingbox Teams who suffer from legacy code, with devs not up to the par & suffering from tests are the ones who need them the most. @mfeathers #scna 12-11-09 5:48 PM

thinkingbox Going after tests seem to me going after the symptoms, not the cause, hence perpetuating the problem. @mfeathers #scna 12-11-09 5:48 PM

And then the day after:

thinkingbox @yehoram @mfeathers I think that the main problem is sending a somewhat mixed message to teams which don’t have consolidated practices yet 12-11-10 9:33 AM

thinkingbox @yehoram @mfeathers While it’s true that we should always evaluate the risk which is covered by tests and ultimately their actual utility 12-11-10 9:34 AM

thinkingbox @yehoram @mfeathers Team which work better are the ones having the least amount of problems with their tests. 12-11-10 9:35 AM

What I’m saying here is that in my experience the teams that are truly slowed down by their tests are in reality slowed by the bad quality of the code under test, not the tests themselves. In practice, I’ve seen cumbersome and brittle tests due to the complexity and intricate dependencies of the code under test. This can be noticed more easily with legacy code.

Some teams struggle, but they are able to navigate through these problems and radically change their systems. Some other teams don’t seem to be able to take the bull by its horns, sometimes also because they focus too much on the tests and not enough on the cause of the pain: their code.

So in the end, while I appreciate Feathers point of view and overall his talk, I think that in particular this aspect can be misunderstood and taken as an excuse to test less, so that teams won’t be slowed down. Unfortunately this is just an illusion and when it backfires it hurts.

The Technical Debt Trap at Agile Tour Toronto 2010

After Fowler’s keynotes, this is the best session that I have attended. The main reason is that its speaker, Michael Norton, was very good: sharp, clear, concise, as a speaker should be.

The presentation was focused on the concept of Technical Debt, conceived by Ward Cunningham back in ’92 and touched by Fowler as well in his third part keynote.

Norton’s intents are to clarify what the metaphor means and which is the proper way to use it. The point is that it’s ok to cut corners in the short timeframe to gain an opportunity (for example, for a demo), but things have to be fixed up properly as soon as possible immediately afterwards. The power of the metaphor lies primarily in the concept of debt and the need of repaying it:

• Every corner that you cut for a specific purpose, for example in terms of code that you know should be done in a different, better way, is debt
• All the debt adds up very quickly and it slows you down
• If you don’t fix that code potentially you’ll end up in a situation where development slows down to a halt and the system needs to be rebuilt from scratch

We should always remember, however, that this is just a metaphor and we can’t stretch it beyond its intended use. It’s indeed a way to think about our own work, it doesn’t magically replace our work with its own laws because we are leaving in a delusion. Norton uses the term metaphorphosis for this kind of phenomenon. In Cunnigham words:

• “[Many] have explained the debt metaphor and confused it with the idea that you could write code poorly with the intention of doing a good job later.”
• “The ability to pay back debt […] depends upon you writing code that is clean enough to be able to refactor as you come to understand your problem.”
• “Dirty code is to technical debt as the pawn broker is to financial debt. Don’t think you are ever going to get your code back.”

Hence, the important things to remember are:

1. Debt is bad => if you can get away without it, just do it
2. Tech debt is a strategic tool => use it under specific circumstances (eg: I need to change this thing and deploy it in an hour, I’ll refactor it right after the deployment), not as an excuse to do sloppy work
   • Remember Fowler => only the quadrant Deliberate/Prudent is acceptable and only for very short timeframes
3. I’d say that 99.99% of your daily work should be debt free
4. Unintentional dirty code, missing tests, bad choices will happen anyway, that’s why Norton called it cruft => it’s physiological, but it’s not technical debt
   • In my team, for example, we do code reviews also to catch that
   • Intentional cruft is always a bad choice, something that you need to avoid and that when done shows a lack of professionalism
5. You have to deal with cruft every day/hour/minute, don’t let it accumulate, because big incremental fixes don’t work => the complexity keeps growing up at the same rate
6. Clean constantly & follow the Boy Scout Rule: Leave the campground cleaner than you found it (of course campground=code)
7. Monitor your tech debt, also by means of metrics like test coverage, procedural complexity (aka cyclomatic complexity, McCabe number) and cohesion/coupling

I’m not a huge fan of slideshare & viewing slides without attending a presentation, but FWIW Norton has uploaded his slides and they are actually good/helpful. As usual, here you can find my mind map as well.

This is the mind map that I have taken live during Norton's presentation

Fowler’s keynotes at Agile Tour Toronto 2010 (with mind maps!)

On October 20th I attended the AgileTour Toronto 2010 conference with a colleague. Well, calling it “conference” is a bit generous but I’m not unhappy about it. It was warm and cozy. I’ll explain more in details in some other posts.

For me, the big highlight of the day was Martin Fowler‘s keynote. Let me rephrase: Fowler gave 3 keynotes in one, which is nice because it’s not too boring and it flows smoothly.

The essence of Agile

In the first keynote Fowler wanted to clarify his view on Agile, talking about its essence. His motivation was to steer clear of a phenomenon that he calls Semantic Diffusion: when you start being successful at innovating and modulating a message, people try to copy you without deeply understanding what you’re doing, just by mimicking your work and distorting your ideas badly. There’s not a lot that we can do about it, with the exception of reminding people about the core principles at the root of what we are doing.

So he wanted to characterize Agile first of all by difference, talking about traditional plan driven methods. In a plan driven method, success is achieved when you do something according to the plan. This is not absolutely impossible per se, but it requires at the very least that the requirements are stable. The bad news is that outside of very limited and insignificant niches, there is NO such thing (and we all know it very well).

So Agile methods are characterized by adaptive planning, which means continuous planning and release early and often. These qualities together constitute an evolutionary design approach, which I’d prefer to define differently and at the software design level in terms of responsive design, but that’s fine, I can take this.

Fowler also briefly mentioned a quote from the Poppendiecks, which sounds more or less like this: being able to deal with a lot of changes in requirements is a competitive advantage. This is a fairly powerful tool in your hands, so use it wisely.

Another fundamental quality of Agile is its focus on people. We all know that after the industrial revolution the way we intend work has been shaped too much and for too long by Taylor and his stopwatch, the so-called system process. This has greatly slowed down the evolution of knowledge work and it has taken a long time and great minds like Deming and Drucker to correct these problems and show a different path. As Deming said, “A bad process would beat a good person every time”. So Agile methods are characterized by putting that good person at the core of the method and allow her/him to shine and do great things, rather than suffocating her/him with bureaucracy.

Because of this, Agile methods need to be adapted to the specificities of the people and their organization, while maintaining the other characteristics mentioned above (while this is fundamental, it is also another contributor to Semantic Diffusion, but again we can’t do much about it). So, Agile methods are characterized by self adaptivity. As Kent Beck says, “In software development, “perfect” is a verb, not an adjective”. This means that the process is never static, but it is continuously verified and improved, always striving for perfection (but of course never achieving it fully).

This is the mind map that I have taken live during first Fowler's keynote

Continuous integration & delivery

In the second keynote Fowler focused on continually adding value to a system.

He started by describing an experience so common if you have developed software for a living in the previous millennium: if you have worked in an environment that doesn’t adopt continuous integration then you know that a project can be easily doomed, staying in integration mode for a very long time.

The idea is simple:

• Individual developers work on their own code, that is they develop feature independently
• Towards the end of the project they put everything together and of course nothing works

The metaphor is having 2 teams digging a tunnel into a mountain from 2 opposite sides and failing to meet in the middle. I actually have seen something like this happening in big construction work in Italy. It’s scary.

Even when versioning systems became popular, people tended to do feature branching more than anything else:

• Every developer has his/her own branch, defined for the feature that he/she is developing
• Because integration is difficult and painful integrate less often
• Because integration happens less and less, when it actually happens is more difficult and painful

This brings to what Fowler calls big scary merges, where you merge together a lot of files, even through sophisticated tools that do that automatically for you and from a text perspective the code seems good, but what about the semantics? You need tests to tell you whether the merge was good or not. And you have a lot of red bars for a very long time, because no tool can automate a slight change in the semantics of the protocol between two classes, for example.

The amount of pain that a team gets grows exponentially with the amount of time that incurs between integrations. I mean, more pain = more time & more bugs = more costs & fewer opportunities to generate revenues.

In the Agile world, typically when something hurts you wanna do it more often. What does this mean? It means that when something is problematic, we want to make it simpler, less expensive, so rather than hiding our head in the sand and try to procrastinate the pain as much as possible, we prefer to tackle it right away and make it better before it’s too late.

So, we want to do continuous integration many times a day, which is exactly what happens at my main gig (my beautiful day job) and in many other companies. I’d say that continuous integration has become more or less mainstream these days, which is good. For example, yesterday we have integrated our code something like 30 times. Integrating means compiling, building all the artifacts, running various kind of checks and thousands of tests. All this is entirely automated.

A bad consequence of feature branching, by the way, is that it encourages avoiding code/design improvement (because it’s painful). So the code quietly rots, day after day, to the point where it becomes a big steaming pile of PUT HERE YOUR FAVOURITE EXPRESSION. Been there, done that, never want to do it anymore in my life.

En passant, Fowler recommended Paul Duvall book on continuous integration.

Towards the end of this part Fowler spoke about continuous delivery, which is a big topic. For the non technical people out there the basic idea is to stretch continuous integration into the actual deployment. How can you do that? By building a pipeline of machines where:

• The code is automatically compiled and unit tested => this should take less than 10′
• Artifacts are generated into a repository
• Artifacts are taken and deployed in a different environment where all functional/acceptance tests are executed in a timeframe that can be measured in hours for complicated systems
• The next stage is typically the one where performance tests are executed to ensure that the system is still executing in an acceptable way and again it can take hours, even more than the previous stage
• If everything is fine the code can be automatically deployed in production in a controlled way, where you do smoke tests to see that nothing is horribly broken

Fowler emphasized that while the last step can be typically controlled manually, and it may vary a lot from org to org (eg: you can’t do it automatically if you have to ask for permission to a committee in a bureaucratic organization), the infrastructure should be in place to do it automatically, with a simple click of a button. As Fowler said: “There should be no technical reasons impeding an automated deployment, while it’s perfectly reasonable that there are business reasons to batch many commits in a single deployment controlled manually”.

Of course Fowler recommended Jez Humble book.

This is the mind map that I have taken live during second Fowler's keynote

A sketch of continuous delivery pipeline depicted by Fowler

Effort, quality and feature development

This third part can be summarized with the following quote: We need to put less effort on quality to put more effort on feature development

At a first glance, this seems sacrilegious, but if you think about it, it doesn’t talk about results, it talks about effort. Hence, it’s actually good to achieve high quality without putting into it much effort, so that we can concentrate on devoting this effort to more labour intensive feature development. Or anyway let’s put effort where our labour is more likely to pay us back directly.

Fowler started by mocking Uncle Bob and his preaching attitude towards quality. It was actually very funny and I think that Fowler is right. Nevertheless, in all fairness Uncle Bob makes the point that all effort devoted to quality pays you back in terms of sustainability and efficiency over time. But certainly he deserved to be mocked, even though with a great deal of sympathy.

Fowler wondered whether quality is tradable. He makes the distinction between internal and external quality:

• Internal => It’s not visible, it’s about software design, cohesion and coupling, code, architecture, etc. It’s like the engine of the car, it’s a kind of magic, hidden under the hood, if it’s not in order all of a sudden the car will break and you’ll be left counting on your feet only
• External => It’s the classic concept of quality in terms of visible behaviour or features of a system, what customers and end users experience out of it

Fowler’s point, and I can’t agree more, is that while external quality is tradable, internal quality is not. Now, we should open a big parenthesis here, related to the differences between startups and sustainable development, the cost of missing opportunities, but for now bear with me. Let’s just say that in the long run, internal quality is overall not tradable. I think that we would all agree on that.

Fowler goes on with his Design Stamina Hypothesis, in order to explain what I just briefly synthesized. The graph from Fowler’s article says it all I suppose.

The idea is that beyond a certain critical mass, the only way to have your system growing linearly with your effort is to keep things in order in the house. Otherwise, development slows gradually.

Then Fowler talks a little bit about the Technical Debt metaphor, that I will explain more in details when talking about another session. Just think that every bit of cruft that cripples into the system is going to sediment and accumulate and you’ll have to pay it back like accrued interest on the principal. It’s a very powerful metaphor that explains well certain phenomenons happening on aging code bases.

Lastly Fowler put up a nice table that tries to classify the different ways in which a team can get in Technical Debt.

	Reckless	Prudent
Deliberate	no time for design	ship now and deal with consequences
Inadvertent	what is layering?	now we know how we should have done it

I think that he was being nice, because I would have used Incompetent instead of Inadvertent. Anyway, the only quadrant where eventually can be temporarily acceptable to be is Deliberate/Prudent, but you don’t wanna stay there for very long. Certainly never Reckless.

So, in the end, the conclusion is that to put more effort into feature development you have to put more continuous effort into internal quality, without compromising in the long run, or this will slow you down more and more and more. I don’t remember if Fowler explicitly said that but that was clearly the whole point.

This is the mind map that I have taken live during third Fowler's keynote

To recap, an enjoyable keynote, or series of keynotes if you prefer, delivered by Fowler in a very pleasant way. For me, they keynote alone was well worth attending the conference.

Guide to Test-Driven Development on ThinkCode.TV

It is done: a few minutes ago the English catalog of ThinkCode.TV has gone live! We are 2 days later on our original plan (oh boy, you have no idea of the amount of glitches, 3rd party service disruptions, personal tragedies, Murphy’s law manifestations… that we have incurred into in the last few weeks), but at this point it doesn’t matter anymore. What matters is that the catalog is out and we can finally get feedback outside of the Italian technical community.

While some videos are derived from our Italian catalog, translated and narrated by an English mother-tongue speaker (David B. Harris, who happens to be a colleague, a good friend and an outstanding author as well), there is some original content that is not available in the Italian catalog too. For example, Renzo Borgatti has updated his screencast about MacRuby and HotCocoa to the latest version and David, as hinted above, has started his course about FOSS Document Management tools.

We are proud to offer subtitles for every video. I personally know English-speaking geeks who like subtitles in any case, at the very least because they can be searched and they can provide an alternative way to browse a video. On the other hand, we are convinced that a lot of people who are not too comfortable with Enligh-only content will benefit from the possibility to read the subtitles to catch even the tiniest detail.

With regards to my stuff, the first lesson of the Guide to Test-Driven Development is available. I’m very excited to see what the reaction of the community will be. Only in the last few days we are starting to see some excellent screencasts popping here and there, but nothing yet to my knowledge that resembles a complete approach to TDD like this course. The Italian version of the guide is one of the bestsellers of the Italian catalog and I hope that it will go well in English too. There are currently 3 lessons available in Italian (with the 4th one coming very soon), so you can expect a steady flow of lessons.

There are a lot of other screencasts that I’d like to produce, touching mainly on topics like OOP, design, refactoring and testing. So many things to do, so little time. 🙂

Coming soon, apart from continuing on the courses that we have started, we will have a great introduction to HTTP, an excellent course on Smalltalk and an interesting screencast covering how to upgrade a webapp to upcoming Rails 3.0 release. So, enjoy, give us feedback, and stay tuned!

If you like Python or interested into it, please grab a “bite”

I’ve been extremely quiet in the last months, but for a good reason: together with some friends we have founded ThinkCode Labs Inc., a Canadian startup whose first project is ThinkCode.TV. Our mission is to deliver high quality technical screencasts, mostly about programming themes.

We have launched on the Italian market in November 2009 and it has been quite a success and a hell of a ride! Now we are on the verge to launch in the English speaking market as well. We will launch on April 19th.

I’m producing an 11 lessons course on TDD which is doing great with the Italian public. I’m touching on subjects like characterizing TDD’s microcycle, finding the next test, dependency injection & mock objects, responsive design, BDD and dealing with aspects like legacy code, handling time & databases. I can’t wait to see which reaction we will get with English speakers.

In the meantime, we are offering a free appetizer for anybody interested: a fantastic 19′ video about implementing a maze solver in Python. You can grab it here: please, let us know what you think about it and if you like it, by all means, spread the news.

Tweets from Agile 2008

For what is worth, I’ve decided to publish my live tweets from Agile 2008.
Bear in mind, it’s twitter, so it’s meant to be volatile, imprecise, etc. I’ve just posted it to give you an idea.

• very nice keynote from James Surowiecki, author of “Wisdom of crowds” => http://tinyurl.com/6acndq
  10:05 AM Aug 5th, 2008
• Compared to other previous European and American editions, the conference is massive!
  10:38 AM Aug 5th, 2008
• Is following “Test-Driven AJAX” ==> http://tinyurl.com/5magmf (interesting so far, basic but interesting)
  11:05 AM Aug 5th, 2008
• Speaker has released his own Mock framework for javascript code => http://tinyurl.com/6fpzrv
  11:07 AM Aug 5th, 2008
• The presentation was good, actually better than my expectation => check it out at http://tinyurl.com/5aczsh
  12:09 PM Aug 5th, 2008
• “Programming with stars” is a great and funny idea, but execution is really poor. Maybe they’ll get better in the next days
  12:58 PM Aug 5th, 2008
• Actually the pair doing javascript with continuous testing (Lasse Koskela’s pair) was quite good, even uncle Bob was nice with them… 🙂
  1:21 PM Aug 5th, 2008
• Has attended “ET by example”: interesting, but I’ll pass for now => http://tinyurl.com/5aym6e
  3:41 PM Aug 5th, 2008
• Attending 2 experience reports about releasing and deployment (from salesforce and yahoo)
  4:08 PM Aug 5th, 2008
• Impressive numbers from salesforce.com
  4:20 PM Aug 5th, 2008
• 40+ scrum teams, 1.1 M users, 3 releases x year, 1 codeline for all
  4:20 PM Aug 5th, 2008
• The release manager is the scrum master of the release sprint, in a high collaboration env with the teams
  4:31 PM Aug 5th, 2008
• over 26,000 automated tests that run on every build
  4:32 PM Aug 5th, 2008
• on top of that there are selenium tests as well
  4:37 PM Aug 5th, 2008
• imagine breaking the build with 40+ teams involved!
  4:37 PM Aug 5th, 2008
• Yahoo can do dynamic, automated, realtime re-deployment based on peak observation (neat!)
  5:10 PM Aug 5th, 2008
• It’s all about heavy automation, speed, dashboards to manage everything and don’t let bad things slip through
  5:31 PM Aug 5th, 2008
• 4-6 months to transition from a chaotic, uncontrolled env to a fully automated one? don’t buy it, too good to be true
  5:33 PM Aug 5th, 2008
• Attending “Coaching agile teams” => http://tinyurl.com/5vhwkt
  8:35 AM Aug 6th, 2008
• The exercise was nice: a laptop screen decorator. Roles: 2 players, 1 coach (only asking questions), 1 observer
  9:16 AM Aug 6th, 2008
• Nice: the coach brings the outside world to the team and reminds about that
  9:48 AM Aug 6th, 2008
• The outcome of the workshop will be available at the conference website
  10:01 AM Aug 6th, 2008
• Attending “Tools, Frameworks and Libraries: the Devil’s work or Manna from Heaven?” (another workshop)
  10:35 AM Aug 6th, 2008
• Done, not particularly impressed. Just 2 decent recommendations out of it: Hudson & TeamCity
  12:02 PM Aug 6th, 2008
• 4 pairs left at “programming with the stars”
  12:48 PM Aug 6th, 2008
• Continuous testing seems the flavour of this year…
  12:53 PM Aug 6th, 2008
• Belshee & Chen refactored some Fit.Net code (continuously testing). Vote: 26
  12:58 PM Aug 6th, 2008
• I liked Mike Hill rant about copy&paste: please don’t always start coding with C&P existing code, because that may lead to deep legacy code
  12:59 PM Aug 6th, 2008
• Koskela & Jacobson have been awesome again. They have changed jsunit own tests, cont. testing at the bottom. Vote: 25, even uncle Bob gave
  81:08 PM Aug 6th, 2008
• Rainsberger & Brackley did TDD from 0, focused on Eclipse tricks for novices. Vote: 23 (but it was good in terms of showing how to teach)
  1:26 PM Aug 6th, 2008
• Feathers & Bache refactored some C++ code. Better than yesterday, but still… Vote: 2
  41:31 PM Aug 6th, 2008
• Bache and Feathers were saved by the crowd… don’t really agree about it, but who cares!
  1:33 PM Aug 6th, 2008
• Attending Clean code session (uncle Bob book just came out)
  2:05 PM Aug 6th, 2008
• Clean code: separate construction from use
  2:05 PM Aug 6th, 2008
• I like it: lazy initialization is bad (for testing, because it messes construction & use, breaks SRP…)
  2:09 PM Aug 6th, 2008
• Scale up systems on demand: keep it malleable, avoid rigidity (like EJB 1 & 2)
  2:21 PM Aug 6th, 2008
• It’s so relieving to hear somebody intelligent talking about EJBs in terms of crap (even though EJB 3 is ok and it’s known stuff now)
  2:24 PM Aug 6th, 2008
• The issue of mixing clean domain code with security, transactions and persistence, but aspects can help (AspectJ or Spring/JBoss AOP)
  2:32 PM Aug 6th, 2008
• 2 cool citations: BDUF doesn’t give you feedback, you are thinking in a vacuum; hard to throw away when you have invested so much into it
  2:45 PM Aug 6th, 2008
• Grow the system in response to test pressure
  2:46 PM Aug 6th, 2008
• Optimize decision making: at the last responsible moment, when the most recent info is available
  2:55 PM Aug 6th, 2008
• Does the std meet the needs? Use standards wisely, when they add demonstrable value
  3:07 PM Aug 6th, 2008
• Minimize the mental gap between requirements and code
  3:07 PM Aug 6th, 2008
• Does the code read like the problem domain? ==> DSLs!
  3:13 PM Aug 6th, 2008
• Having clean code. well modularized, is an enabler in making a decision at the least possible moment
  3:16 PM Aug 6th, 2008
• Overall a great implementation. Last version of the slides available at http://tinyurl.com/6mr6qf
  3:17 PM Aug 6th, 2008
• Attending “Executable User Stories with RSpec and BDD”
  4:06 PM Aug 6th, 2008
• From CHAOS report: 56% of errors are introduced with requirements gathering, elicitation & specification
  4:07 PM Aug 6th, 2008
• I don’t like it: BDD starts with a functional test, from the very outside in. This means that BDD resolves to STDD. Bleah…
  4:30 PM Aug 6th, 2008
• Nice: getters are like horseshit. In a matter of few days a lot of classes will be attracted to it, like flies to horseshit
  4:32 PM Aug 6th, 2008
• I was hoping to focus more on RSpec Spec, rather than Story. Not much interested in cucumber, a reimpl of Story made by the presenter
  4:57 PM Aug 6th, 2008
• You can use RSpec::Story or Cucumber to drive Watir => http://wtr.rubyforge.org/ or Celerity => http://celerity.rubyforge.org/
  5:09 PM Aug 6th, 2008
• Testing java code in RSpec (or Cucumber) by using JRuby is kind of neat
  5:11 PM Aug 6th, 2008
• Memo for the presenter: close all porn images when you plug your laptop to the projector! 🙂 🙂
  5:25 PM Aug 6th, 2008
• Overall I’m quite disappointed, but maybe my expectations were too high (and the abstract kind of mislead me)
  5:31 PM Aug 6th, 2008
• Attending “Agile Architecture IS Possible – You First Have to Believe!” => http://tinyurl.com/5j6fdc
  8:31 AM Aug 7th, 2008
• Whackamole bug: you fix something here and suddenly something else breaks in a totally different place
  8:42 AM Aug 7th, 2008
• Rule: No tasks longer than 2 days
  8:45 AM Aug 7th, 2008
• Offline rollout can be an effective way to gradually migrate a 24/7 live service without disruptions
  8:56 AM Aug 7th, 2008
• @bbossola maybe: presenter was implying a temporal discontinuity between one fix and a totally unrelated bug… fragility in the large? 🙂
  8:59 AM Aug 7th, 2008
• Great session, maybe too short (30′ because it’s an experience report)
  9:07 AM Aug 7th, 2008
• Attending “Technical Debt – How not to ignore it” now => http://tinyurl.com/5bf8vw
  9:07 AM Aug 7th, 2008
• The presenter is the guy who wrote the excellent “Scrum and XP from the Trenches” => http://tinyurl.com/6zzazx
  9:11 AM Aug 7th, 2008
• tech debt detection: gut feeling (customers & developers), metrics (code, velocity)
  9:17 AM Aug 7th, 2008
• Why? 1) short-term thinking (“we’ll fix it later”), 2) pressure (lack of slack & sustainable pace), 3) not talking about it (denial)
  9:18 AM Aug 7th, 2008
• 4) lack of dev skills, 5) broken window syndrome
  9:19 AM Aug 7th, 2008
• Prj Management practices like Parkinson’s Law are major causes for tech debt (this is me saying it, not the presenter… 🙂 )
  9:20 AM Aug 7th, 2008
• Ah nice, another attendee mentions the Parkinson’s Law 🙂
  9:21 AM Aug 7th, 2008
• The maximum theoretical velocity is diminishing over time
  9:23 AM Aug 7th, 2008
• To avoid it (or mitigate it): 1) talk about it (with PO too), 2) pull scheduling (taking for granted if you do XP & Scrum right)
  9:27 AM Aug 7th, 2008
• 3) TDD, 4) put no increased tech debt with the definition of done (me: why not automatic measures on McCabe => build fails if it incr …
  9:29 AM Aug 7th, 2008
• Another attendee was talking about failing the build if code coverage diminishes => nice!
  9:30 AM Aug 7th, 2008
• Preferred approach to fix it is incremental improvements => slow down and stop accumulating debt
  9:35 AM Aug 7th, 2008
• You can’t have a PO working against fixing the tech debt. Major crashes & disasters typically help the biz understanding! 🙂
  9:39 AM Aug 7th, 2008
• Me: 20% of resources allocated to fixing tech debt. It took months of problems to convince management it was a good idea
  9:40 AM Aug 7th, 2008
• In order to fix the process retrospectives are the key: root cause analysis, 5 whys, etc.
  9:40 AM Aug 7th, 2008
• test automation backlog: what tests we are missing and we want to do? prioritize them and maintain in a backlog
  9:43 AM Aug 7th, 2008
• It’s a nice technique once you have tech debt, but at the same time it institutionalize one aspect of the debt => you need to get out …
  9:54 AM Aug 7th, 2008
• all in all: tech debt is a powerful metaphor to use with non tech people, stop accumulating it no matter what, fix it incrementally…
  9:56 AM Aug 7th, 2008
• …with a viable pace (avoid big bang approaches), fix the process (not only the product)
  9:57 AM Aug 7th, 2008
• Very nice session in the end
  10:01 AM Aug 7th, 2008
• Attending “A Hundred Days of Continuous Integration” => http://tinyurl.com/554tfc
  10:27 AM Aug 7th, 2008
• It’s on the proceedings at page 289
  10:31 AM Aug 7th, 2008
• it’s from M$, amazing! 😉
  10:32 AM Aug 7th, 2008
• it’s the Service Factory: Modeling edition, a team of ~15 people between Redmond, Holland, Argentina, India…
  10:34 AM Aug 7th, 2008
• Nice: a distributed env that spans across 18 hours TZs invalidates the concept of nightly build => you are left with continuous integ …
  10:37 AM Aug 7th, 2008
• But some specific tasks can be executed at specific times (eg: static analysis with NDepend => plug here your java tool if you want)
  10:38 AM Aug 7th, 2008
• 100 days, 4000 hours of dev time, 551 check ins, 515 builds, 69 build breaks
  10:39 AM Aug 7th, 2008
• distribution of breaks: 18 compile errors, 19 unit tests, 4 server issues, 27 fxcop (static analysis issues)
  10:43 AM Aug 7th, 2008
• Worst breaks to fix (up to 9 hours to fix) were related to server issues & unit tests failures (but small time during working hours)
  10:44 AM Aug 7th, 2008
• on avg 45′ to fix the build
  10:45 AM Aug 7th, 2008
• Model shows an est. saving of 40% using CI against ideal teams that don’t use CI but never break the build too (using more time to checkin)
  10:50 AM Aug 7th, 2008
• I like the idea of additional builds for time zone issues (with distributed teams)
  10:51 AM Aug 7th, 2008
• Lessons: 1) overspec your CI srv. 2) additional builds for TZs, 3) capture all the data, 4) real time analyssi, 5) warnings ARE errors
  10:52 AM Aug 7th, 2008
• (one warning is a broken window) 🙂
  10:52 AM Aug 7th, 2008
• 5) don’t check in and go home (especially on a distributed team), 6) you break it so you fix it
  10:53 AM Aug 7th, 2008
• they weren’t doing any rollback on checkin, because it was hard (heavily dependent on chosen SCM of course, pre commit hooks are the key)
  10:57 AM Aug 7th, 2008
• ~70% coverage combining UTs and ATs
  10:59 AM Aug 7th, 2008
• nice session, now “Team pace – Keeping build times down” from TW! => http://tinyurl.com/6j2em7 (page 294 on proc)
  11:01 AM Aug 7th, 2008
• 2 teams working in java, bubble & squeak – bubble was ~10 people, 4w iterations, build dealing with out & in-container testing + fitnesse
  11:04 AM Aug 7th, 2008
• team squeak had 2′ build, 12 devs, 16 people, 1w iteration, colocated, customer frequently on site, smaller build with jar,war, set db, ut
  11:06 AM Aug 7th, 2008
• (team bubble part of a bigger distributed team, ~100)
  11:06 AM Aug 7th, 2008
• team bubble checked in much less, much slower build time
  11:07 AM Aug 7th, 2008
• between 760 and 10 checkins per day!! over 9 months (team squeak, while bubble a few per day only)
  11:09 AM Aug 7th, 2008
• checkin every 15-20 seconds is nuts!!! 🙂 interesting though, I got to give it a try, but my current CVS srv would die miserably 🙂
  11:10 AM Aug 7th, 2008
• team bubble had a huge resistance to refactor, once they had 6 weeks with no good build!! very unstable builds
  11:11 AM Aug 7th, 2008
• of course team squeak had a great willingness to refactor
  11:12 AM Aug 7th, 2008
• team bubble couldn’t cope dealing with the build, so they have created a cross-functional team to deal with it
  11:13 AM Aug 7th, 2008
• bubble tried parallel test running, websphere was a major problem (5-10′ just to rebuild the profile), a lot of infr problems
  11:14 AM Aug 7th, 2008
• squeak rarely had build issues, and those that happened were typically fixed in 20-30′
  11:15 AM Aug 7th, 2008
• typically the build weren’t fixed for both teams the first time => a new failure gives you more info to actually fix it
  11:16 AM Aug 7th, 2008
• because of the broken builds pairs started sequential checkins
  11:17 AM Aug 7th, 2008
• broken builds for bubble prevented to get into the “flow”, it was a source for distractions and inefficiencies
  11:19 AM Aug 7th, 2008
• team squeak did some manual tests for javascript & browser related issues
  11:20 AM Aug 7th, 2008
• bubble worked on the order of tests to anticipate likely failures, segmented tests, added tests not dependent on DB
  11:21 AM Aug 7th, 2008
• squeak worked with a in-mem db that didn’t help much, using the db itself was almost quite the same, all tests in junit
  11:21 AM Aug 7th, 2008
• squeak really relied on out of container tests, with extremely light servlets and all biz logic in POJOs
  11:22 AM Aug 7th, 2008
• make the build a priority for every member of the team, small improvements for every iteration
  11:23 AM Aug 7th, 2008
• keep the build simple, ideally a single build file for all environments
  11:24 AM Aug 7th, 2008
• keep the number of tech as low as possible, focus on small technologies
  11:24 AM Aug 7th, 2008
• build once, reuse the built artifact as many times as possible
  11:25 AM Aug 7th, 2008
• minimise runtime dependencies, run the application standalone and use stub/mocks as much as possible
  11:25 AM Aug 7th, 2008
• keep test & data in the code together => it helps refactoring! (nice)
  11:26 AM Aug 7th, 2008
• Not too bad, now attending “Effective and pragmatic Test Driven Development” => http://tinyurl.com/6kx76v
  11:31 AM Aug 7th, 2008
• Exp report from Valtech about applying TDD to a project in T-Mobile
  11:31 AM Aug 7th, 2008
• Decision to use TDD came after project inception (with management awareness, agile-savvy and willingness to try new things)
  11:35 AM Aug 7th, 2008
• Risks of using TDD was shared with the whole team and interactive sessions / presentations were held
  11:36 AM Aug 7th, 2008
• MVC app, this team responsible for backend, very well defined integration point (contract) with frontend team
  11:37 AM Aug 7th, 2008
• top down dev, starting from AT (bleah), deriving major services, implementations, their UTs and DAOs (and their UTs) from it
  11:40 AM Aug 7th, 2008
• In retrospect they thought they have left too much freedom to less experienced developers
  11:41 AM Aug 7th, 2008
• Some negative feedback not related to TDD, but to the fact that devs were more involved (and being accountable) with estimates, meetings,etc
  11:51 AM Aug 7th, 2008
• But TDD helped in getting things better in terms of improved efficiency
  11:51 AM Aug 7th, 2008
• Too much focus on TDD “dogmas” and TDD application, too much time spent on enhancing tests
  11:51 AM Aug 7th, 2008
• Benefits: better code, more cohesive, top down approach with mocks helped with SRP (but yet, bleah), YAGNI (discourage speculation)
  11:51 AM Aug 7th, 2008
• Stakeholders involvement payed back with increased confidence and a favourable comparison with previous experience (better defect rate)
  11:51 AM Aug 7th, 2008
• This in turn caused support for refactoring, which brought code cut faster, shorted feedback cycle, and more confidence (etc)
  11:51 AM Aug 7th, 2008
• conclusions: TDD is good, can be difficult to introduce, not much experience around, devs who embrace it got rewarded
  11:56 AM Aug 7th, 2008
• made real differences in delivery
  11:57 AM Aug 7th, 2008
• all in all, I’d yeeeesh, not a fantastic session 🙂
  12:01 PM Aug 7th, 2008
• at programming with the stars the 3 remaining pairs will do the same, STDD something (eh eh, Joshua… 🙂 )
  12:47 PM Aug 7th, 2008
• pairs: Lasse & Noah, Michael & Emily, Arlo & Andrew
  12:48 PM Aug 7th, 2008
• for once, the judges have been judged and scored a remarkable total of 6!! (they were doing uncle Bob’s prime factors kata)
  1:01 PM Aug 7th, 2008
• lasse & noah are using RSpec Story with a well defined scenario ready to go
  1:03 PM Aug 7th, 2008
• they are working on a rails app, in the end
  1:04 PM Aug 7th, 2008
• Using Rspec Story to drive Watir
  1:05 PM Aug 7th, 2008
• jumped on javascript code (with continuous testing) to implement the missing function, but didn’t have time to complete it
  1:09 PM Aug 7th, 2008
• uncle Bob didn’t like the test through the gui (because it was slow and he was kind of right) ==> 2
  11:11 PM Aug 7th, 2008
• Michael & Emily are using a swing app, with junit UTs and AT with a recorder that drives the app and manages the text through text output
  1:15 PM Aug 7th, 2008
• the app is TextTest => http://texttest.carmen.se/
  1:16 PM Aug 7th, 2008
• they have involved the “customer” => nice!
  1:16 PM Aug 7th, 2008
• much better this time: they have scored 26 (uncle Bob biased towards Michael Feathers?)
  1:20 PM Aug 7th, 2008
• Arlo & Andrew pulled out a board with planned cards, a PO, a kind of lavalamp for build status, rspec Spec, cruisecontrol.rb
  1:23 PM Aug 7th, 2008
• they are really driving the lamp in the story
  1:23 PM Aug 7th, 2008
• kind of eating your own dog food
  1:24 PM Aug 7th, 2008
• nice idea, but confused execution
  1:27 PM Aug 7th, 2008
• total score: 1
  81:29 PM Aug 7th, 2008
• finale: Michael & Emily vs Lasse & Noah (Arlo & Andrew are gone)
  1:31 PM Aug 7th, 2008
• Attending “The Economics of Agile: The competitive advantage of developing commercial software with Agile methods”
  2:02 PM Aug 7th, 2008
• Remarkably empty room (a big one too), I guess that an IBM VP doesn’t attract a lot of geeks, but the topic is interesting
  2:03 PM Aug 7th, 2008
• http://tinyurl.com/6j2ozy
  2:04 PM Aug 7th, 2008
• Each table can hold 10 people and there are 36 tables, but only ~35 people in the room (vs a capacity of 360!!)
  2:05 PM Aug 7th, 2008
• IBM started a transformation in 2005 in order to control quality better, manage stakeholders satisfaction, and anticipate return/profit
  2:09 PM Aug 7th, 2008
• from waterfall (still used for mainframe dev), through iterative (lacking discipline), to agility (with discipline, adaptability)
  2:12 PM Aug 7th, 2008
• extremely distributed teams, compliancies, heterogeneous environment => the Poppoendiecks helped them
  2:14 PM Aug 7th, 2008
• Nice: a project dashboard with “corporate revenue”!! 🙂
  2:15 PM Aug 7th, 2008
• 1100 people in agile@IBM, 5000 trained, 220 projects, 78% of teams are using some elements of agile
  2:16 PM Aug 7th, 2008
• schedules are more predictable and early (18 -> 12 months, some other teams 12 months to 9 months)
  2:17 PM Aug 7th, 2008
• IBM’s customers seem to like it, especially in terms of increased confidence of what is delivered (they are involved early and often)
  2:18 PM Aug 7th, 2008
• Metrics: B/C R = Benefit/Cost Ratio, ROI
  2:19 PM Aug 7th, 2008
• E^2 value framework: efficiency + effectiveness
  2:20 PM Aug 7th, 2008
• headcount is used primarily as a source of cost, which is scary, but at the same time they say that people are reused elsewhere
  2:22 PM Aug 7th, 2008
• revenue generated per head I like it better
  2:23 PM Aug 7th, 2008
• Ted Rivera is focusing on DB2 (600 people) => 60 M$ in terms of investment (rough figure, but it scares!)
  2:25 PM Aug 7th, 2008
• In the past it was impossible for IBM to make changes in terms of plans until it was too late, but now it’s different
  2:28 PM Aug 7th, 2008
• the assessment is a total of ~90.6M savings up to date because of agile adoption (prod gain at startup & tasks implementations, …
  2:31 PM Aug 7th, 2008
• cost & waste avoidance too)
  2:31 PM Aug 7th, 2008
• it’s all about defect reduction & time saved in terms of quality injection after the fact (IBM has tons of historical data to qualify that)
  2:33 PM Aug 7th, 2008
• expected: 168 field tickets, 1056 trouble tickets – actual: 32 field tickets, 57 trouble tickets (with more customers)
  2:35 PM Aug 7th, 2008
• what does that mean? roughly 2.576M$ in savings and much more customer loyalty
  2:36 PM Aug 7th, 2008
• it’s nice to see an IBM tech guy with a huge impact in the org to talk intelligently about XP practices and Lean principles, like TDD
  2:41 PM Aug 7th, 2008
• An internal agile survey showed an improvement in every area of agile adoption (testing, CI, scrums, etc.)
  2:50 PM Aug 7th, 2008
• IBM’s commitment to agile is remarkable. Practices are treated in guidelines and the situation is constantly evolving
  3:01 PM Aug 7th, 2008
• Nice (from the crowd): IBM tools are notoriously heavy and difficult to work with for agile teams (eg: websphere in CI), so?!?
  3:03 PM Aug 7th, 2008
• Basically: what are you going to do about it?
  3:03 PM Aug 7th, 2008
• The answer is not that satisfactory, just a generic promise of making it simpler and having more internal people validating products
  3:04 PM Aug 7th, 2008
• Question about pair programming adoption. Answer: we treat practices as a menu. PairProg is used to one degree or another.
  3:07 PM Aug 7th, 2008
• But not broadly: if PairProg is not used some other practices related to code reviews should kick in
  3:08 PM Aug 7th, 2008
• Reuse is a key aspect of savings, but it’s not clear the connection with agile adoption
  3:09 PM Aug 7th, 2008
• I don’t know, I suppose that given the context it was an interesting session, but I didn’t hear much new and I was hoping for more meat
  3:26 PM Aug 7th, 2008
• Attending “Workshop on build/test grids and selective testing tools” => http://tinyurl.com/6ntzrv
  4:02 PM Aug 7th, 2008
• 5 attendees, too bad
  4:05 PM Aug 7th, 2008
• VersionOne lead tester looking for breaking the tests and distribute them (+3hours now)
  4:06 PM Aug 7th, 2008
• One more attendee (a good one: Rick Mugridge? )
  4:07 PM Aug 7th, 2008
• selective testing: a tool that can dynamically figure out which tests to run, a dynamically built suite, based on modified code
  4:07 PM Aug 7th, 2008
• Presenter: the team was large, many many thousands of developers. WOW! I wonder what it is.
  4:18 PM Aug 7th, 2008
• Breaking the build was quite an issue. Done some prioritization of tests in python, not satisfactory enough. Dependencies were big and messy
  4:20 PM Aug 7th, 2008
• TW lead tech guy talks about Cruise, evolution of cruise control that will take into account also distr test, selective test, etc
  4:24 PM Aug 7th, 2008
• googletester is a selective tester tool
  4:25 PM Aug 7th, 2008
• sorry, google-testar => http://tinyurl.com/vuhf
  74:27 PM Aug 7th, 2008
• the sourceforge page is even better => http://tinyurl.com/5lba8f
  4:30 PM Aug 7th, 2008
• Mugridge: the complexity is finding the right dependencies in order to run only certain tests
  4:35 PM Aug 7th, 2008
• Instrumentation seems the key and it’s not that difficult if you use a system like Spring on top of your classes
  4:35 PM Aug 7th, 2008
• 12′ for the whole build cycle, not bad but he’d like faster
  4:40 PM Aug 7th, 2008
• TW was working on VM cloning, tests split and collection of results
  4:45 PM Aug 7th, 2008
• Build cycle based on stages (packaging, UTs, FTs, PerfTs, UATs depl stage, Prod depl) where every stage can be broken and distributed
  4:51 PM Aug 7th, 2008
• Using VMs gives the advantage & flexibility of deciding how to distribute it: all the VMs can run in 1 box in reality
  4:52 PM Aug 7th, 2008
• 2 stages of the same pipeline cannot start concurrently, but Pkg can start when FTs are running because of a new commit
  4:53 PM Aug 7th, 2008
• Robert Norton is the TW guy
  4:54 PM Aug 7th, 2008
• 10′ build time for mingle
  4:58 PM Aug 7th, 2008
• Selective testing tools are good but very context dependent (and even the same project may change in its lifetime)
  5:27 PM Aug 7th, 2008
• Careful with getting false confidence with selective testing (all the attendees agreed on it)
  5:28 PM Aug 7th, 2008
• The concept of smoke tests is to provide early feedback (some end-to-end tests) and they be considered an appendix to UTs
  5:29 PM Aug 7th, 2008
• workshop report to be submitted at http://tinyurl.com/5spxln
  5:38 PM Aug 7th, 2008
• Nice session, in the end, mostly because of the experiences and thoughts from various participants
  5:45 PM Aug 7th, 2008
• Just had a demo of mingle => http://tinyurl.com/2otxqj => it rocks!!!
  6:49 PM Aug 7th, 2008
• mingle is a fantastic product, but a few things are missing to make it really irresistible: snapshot, better and more integration, eg: build
  6:51 PM Aug 7th, 2008
• and a 1 click gantt generator for those customers that demands it (for reporting purposes)
  6:51 PM Aug 7th, 2008
• Attending “Starting a Kanban System for Software Engineering with Value Stream Maps and Theory of Constraints”
  8:34 AM Aug 8th, 2008
• http://tinyurl.com/55vglo
  8:35 AM Aug 8th, 2008
• Kanban systems & agile => http://tinyurl.com/2vlv9
  58:41 AM Aug 8th, 2008
• Assigning tasks early creates and artificial critical path => that’s why on task allocation too we want to use the last possible moment
  9:24 AM Aug 8th, 2008
• Limit multitasking (or avoid it, if possible)
  9:24 AM Aug 8th, 2008
• I don’t agree that reprioritizing the sprint backlog continuously is waste => it looks like an opportunity to create biz value to me
  9:31 AM Aug 8th, 2008
• @pierg Sorry, I haven’t detailed the context: when a person is available to pick a new task => reprioritize (if needed) seems good to me
  9:52 AM Aug 8th, 2008
• @pierg Worth to mention that the presenter was proposing to have a READY state between TODO and IN PROCESS
  9:53 AM Aug 8th, 2008
• Of course, low availability resources decrease productivity => you need to add buffering in order to cope with that and keep high thr …
  9:55 AM Aug 8th, 2008
• pull model, not push; global optimization, not local
  9:56 AM Aug 8th, 2008
• the workflow should reflect the relative skills and strengths of actual team members
  9:57 AM Aug 8th, 2008
• check presenter’s blog at http://tinyurl.com/6s9nwg
  9:58 AM Aug 8th, 2008
• and participate to http://tinyurl.com/5t9fa2 (low volume)
  9:59 AM Aug 8th, 2008
• I’m not sure I’ve enjoyed much this presentation, kind of messy and conceptually unfocused (but the subject is very interesting!)
  10:00 AM Aug 8th, 2008
• In 30′ it’s time for the last keynote, from Alan Cooper (aka mr. VB) 🙂
  10:00 AM Aug 8th, 2008
• Alan Cooper is reading, I don’t particularly like that
  10:37 AM Aug 8th, 2008
• BUM: programmers are the smartest people in the human race! 🙂
  10:38 AM Aug 8th, 2008
• Watching a programmer works is as revealing as watching oysters grow
  10:39 AM Aug 8th, 2008
• Once again, programming is craft and all software is bespoke, custom
  10:40 AM Aug 8th, 2008
• programming is not art => YEAH! FINALLY!!! Programs are practical, art is not, even though some code is beautiful
  10:41 AM Aug 8th, 2008
• programming is extremely creative and design is every day job
  10:42 AM Aug 8th, 2008
• Interfaces are the most critical part of sw. They are the place in between (sw and humans, sw and sw => API)
  10:44 AM Aug 8th, 2008
• Mmm: too much emphasis on using existing libraries, etc. => even though after that he recognize you don’t want to choose the wrong tool
  10:46 AM Aug 8th, 2008
• there is no silver bullet, but agile is different => it’s about process and people rather than tools and it’s inclusive of other people
  10:48 AM Aug 8th, 2008
• sw is a multistage process, but waterfall is an obsolete one => waterfall doesn’t work, it produces improper crap rejected by users/c …
  10:50 AM Aug 8th, 2008
• waterfall introduces mistrust, opacity, isolation, delay, failure of design
  10:51 AM Aug 8th, 2008
• the boundaries of stages are fuzzy and overlap and recur continuously
  10:52 AM Aug 8th, 2008
• a reaction to waterfall failure was a reduction to just coding (construction), but that fails too
  10:53 AM Aug 8th, 2008
• four stages: 1) big idea, 2) design (meaning product use), 3) Engineering (about how we build), 4) construction, that is let’s build it
  10:54 AM Aug 8th, 2008
• Disagree: programming time requires solitude
  10:59 AM Aug 8th, 2008
• agile is a powerful tool for coping with incompetence
  11:01 AM Aug 8th, 2008
• agile is a tool for coping with BDUF, unreasonable customers (confront with the options), incompetent designers, foolish managers
  11:03 AM Aug 8th, 2008
• the big sin of dealing sw production as a manifacturing line, cmd & control, but programming is post-industrial
  11:04 AM Aug 8th, 2008
• dealing with a knowledge worker is completely different and it’s based on competence, respect, education, quality of work
  11:05 AM Aug 8th, 2008
• efficiency (reducing prices) vs effectiveness (increasing quality)
  11:06 AM Aug 8th, 2008
• going fast in the wrong direction is worse than going slow in the right direction => no real advantage in reducing costs
  11:07 AM Aug 8th, 2008
• because of the lack of understanding of sw, pressure is applied to reduce time, quality is neglected
  11:09 AM Aug 8th, 2008
• no competent business person would choose speed over correctness if they have confidence in the outcome
  11:09 AM Aug 8th, 2008
• challenge stupid deadlines, demand quality lines
  11:11 AM Aug 8th, 2008
• agile brings design, engineering and construction together in an iterative fashion
  11:14 AM Aug 8th, 2008
• agile brings the desire to create better product to the programmers, which is exactly what the interaction designers want too
  11:16 AM Aug 8th, 2008
• why they are not in love with each other? interaction designers love to do those things that the programmers typically don’t like
  11:17 AM Aug 8th, 2008
• creating user stories is the programmers weakest skill, but it’s the interaction designers strongest one
  11:19 AM Aug 8th, 2008
• interaction designers can be very effective and helpful at dealing with distortions, cognitive illusions and communication issues with users
  11:25 AM Aug 8th, 2008
• requirements are not design, requirements cannot be gathered like colored eggs on Easter’s morning 🙂
  11:27 AM Aug 8th, 2008
• the first work product of interaction designers is a narrative restatement of the problem => this triggers validation, feedback, corr …
  11:29 AM Aug 8th, 2008
• the interaction designers when coding starts is related to reconcile all the ideas that pop up with the interaction with customers/prgmers
  11:32 AM Aug 8th, 2008
• some misconceptions about planning and change in requirements => we do plan and we do design, we just do it continuously
  11:34 AM Aug 8th, 2008
• Brooks: Plan to throw one away
  11:37 AM Aug 8th, 2008
• Cooper suggests to REALLY plan to throw the first time away ==> prototyping?
  11:37 AM Aug 8th, 2008
• The way he intends it is a big bang prototype that solves all the problems and build all the necessary knowledge, so that production is easy
  11:39 AM Aug 8th, 2008
• agile methods are the first to make room for interaction designers, whose purpose is to make software better for the user
  11:40 AM Aug 8th, 2008
• seems like a happy marriage, a win-win (in Cooper’s mind)
  11:41 AM Aug 8th, 2008
• slides and notes available at http://tinyurl.com/5cvop5
  11:42 AM Aug 8th, 2008
• question: what about biz analyst? is it the same; answer: BA are about biz processes, but interaction designers are about human behaviour
  11:46 AM Aug 8th, 2008
• a question challenges the approach of doing it first in an agile way, throw it away and doing it again in a non agile away
  11:49 AM Aug 8th, 2008
• but he doesn’t clarify the second time how it should be built
  11:50 AM Aug 8th, 2008
• Mike Hill (the brit one) and Steve Freeman are going to demonstrate a bit of TDD as stars… 🙂
  1:05 PM Aug 8th, 2008
• of course they are all messed up, one doesn’t listen to the other, one talks at the phone, one holds onto the keyboard, both complains cont.
  1:08 PM Aug 8th, 2008
• test name: RobotLightbulbManagerServiceTest 🙂 😀
  1:09 PM Aug 8th, 2008
• joshua killed them and asked them to go away! 🙂
  1:10 PM Aug 8th, 2008
• now it’s Michael Feathers and Emily Bache (for real)
  1:11 PM Aug 8th, 2008
• argh, python code
  1:11 PM Aug 8th, 2008
• refactoring a poker engine written in python
  1:12 PM Aug 8th, 2008
• got themselves a bit into trouble, the rhythm is slow, wrote some code, being bashed by the audience on YAGNI, still haven’t executed tests
  1:18 PM Aug 8th, 2008
• still red bar
  1:18 PM Aug 8th, 2008
• nope, time is up, no green bar, amazingly bad
  1:20 PM Aug 8th, 2008
• judges: 5+5+6=16
  1:23 PM Aug 8th, 2008
• a “Deloitte & Touche” consultant is going to collect audience scores 😀
  1:25 PM Aug 8th, 2008
• Lasse and Noah now, refactoring slow tests, because of a movie file being read
  1:25 PM Aug 8th, 2008
• actually is slow code and they want to decouple sync logic from file reading logic
  1:26 PM Aug 8th, 2008
• using a stub for testing the sync reader
  1:27 PM Aug 8th, 2008
• red bar, green bar
  1:27 PM Aug 8th, 2008
• introducing a virtual clock to simulate lagging, nice
  1:28 PM Aug 8th, 2008
• mixing a mock object for the TimeSource and the stub for file processing
  1:29 PM Aug 8th, 2008
• I mean, they are going fast, but they are not refactoring any test code (and it would need it)
  1:32 PM Aug 8th, 2008
• they have played the movie missing frames in the end, nice
  1:34 PM Aug 8th, 2008
• uncle Bob gave a 9! total: 2
  11:36 PM Aug 8th, 2008
• now the pairs have to type 2 sentences at the keyboard
  1:38 PM Aug 8th, 2008
• unfortunately it’s an inverted one 🙂
  1:39 PM Aug 8th, 2008
• -10 points because of overrun and errors for Lasse and Noah
  1:43 PM Aug 8th, 2008
• Michael and Emily got a +12
  1:46 PM Aug 8th, 2008
• the consultant is calculating the score for both pairs
  1:47 PM Aug 8th, 2008
• 38 grand total for lasse & noah
  1:47 PM Aug 8th, 2008
• 35 grand total for Michael and Emilty
  1:48 PM Aug 8th, 2008
• hence, Lasse and Noah won!
  1:48 PM Aug 8th, 2008
• prizes: beer, cutting plate, 2 books WOW!
  1:50 PM Aug 8th, 2008

Unfortunately this year I can’t attend Agile 2009 in Chicago, but if you have an opportunity to go there I can only recommend it. Please let me know if you are going to tweet live from it.

Twittering from Agile2008

FWIW, I’m twittering from Agile2008.

No Fluff, Just Stuff tour hit Toronto

Last weekend I went to the Greater Toronto Software Symposium, part of the No Fluff, Just Stuff tour. It is the first time that they hit Toronto and just to go straight to the point I think it will be a huge success in the years to come. Here are my impressions and my feedback about it.

TDD live demo in ruby

Marco Abis has published all the stuff related to the Second Italian Agile day. This means that there’s also the zip file of all the steps related to my session.

I have collected all the different versions of the code that I was developing during my session, I have cleared them a bit (ie: I have removed insignificant steps, typos, etc.) and I have written a small comment for each step. What I have obtained is a sequence of 49 steps, made by 42 live steps and 7 offline to complete the work. What’s interesting is that first file was saved at 3:40:48 PM, while the last file at 4:41:06 PM ==> it means 42 steps in 62 minutes. Steps have not all the same length of course, but I can assure you that there are always less than 3 minutes between one step and the next one.

Agile Day feedback

December Friday 16th we have had our second Italian Agile Day. It was a tough day for me, I had some flu and bad temperature the 2 days before. Luckily, some paracetamol and antibiotics helped me carry on until the end of the day.
I’m really satisfied by this year’s edition. Compared to 1 year ago, this year we have had less presentations, no parallel sessions, but more insight and more depth IMHO. I was particularly impressed by Ferrari Racing Development Team and Francesco Cirillo.