I’m doing a short “tour” together with two other speakers, Janne Lundberg from Atlas Copco Tools and Joakim Pilborg from KnowIT Technology Management. The theme of the tour is of course lean and agile and I’m talking about “Agile in the Large”, one of my favourite topics. Here are the slides that I show.
Removing duplication is maybe the simplest and most important fight against code smells there is. And for many cases it is fairly easy if you are using something with reasonable refactoring support like Eclipse. Just mark one instance, extract method/expression, replace second instance with call. Done!
But there is not only duplication, but also near duplication. And I find that, for me, there is much more mental resistance to get to grips with this type. What you should do, and I try (at least for a brief moment), is to make the two sections of the code *exactly* identical first. Then the duplication is just an instance of the above case, and just as easy to fix.
But sometimes I just can’t see how to change them to be exactly the same. I need some glasses. And actually it shouldn’t be so hard to help me out here, but so far I have failed to find that help.
I want to be able to mark two regions in my editor, ask it to mark anything that is different. There are one million diff-tools that works on two (or more!) files, repositories or directories. Why is there no region diff in Eclipse?
My talks from Agila Sverige 2009 (“Agile Sweden”) is now up on Vimeo, in fact all the lightning talks are. There are some good ones there. I’m embedding my two talks here. (Swedish only, sorry!)
For each new school of thinking models of that thinking are built, believed, proposed and adopted but also interpreted literaly. So on the note of my last post I’d like to quote George Box, “All models are wrong, some can be useful.” I try to live by this quote when I teach and coach. Believing in models as a true depiction of the real world are not only fundamentally wrong but also leads to fundamentalism or versusitis.
I found a wonderful definition of properties of a model which you might consider benchmarking your favorit model against, be it Scrum, XP, CMMI, Lean, Kanban, RUP or the process models of your own company.
I just found an excellent description, and name, for a “disease” that I hope I’m not afflicted by. You can see the effects of it in many places, particularly in development and engineering environments. I think many instances of Agile initiatives gone wrong can be traced back to someone with the disease. This article by Scott W. Ambler describes it in detail.
There has been a very active discussion on the LinkedIn Agile group on the topic of “Surely waterfall methodlogy is no more but who is secretly still using it? Come on, admit to it!!!“.
Interestingly enough, there were a number of people “admitting” to using waterfall 😉
My first comment in that discussion went on the lines of Agile and Waterfall not being two well-defined methods, but instead are strong simplifications based in two very different viewpoints. Waterfall being based in the thinking that we should think the whole thing through before starting, drawing and deciding on a detailed plan, write complete, reviewed & approved specifications before doing any implementation, and so on.
Agile on the other hand is based in the adaptive thinking. The best way to get to the goal is to start the journey. And ensuring that we get feedback along the way.
I would presume that all development organisations are doing something in between, at least I have not seen one doing “true” waterfall or “true” agile (in this sense, at least).
In the discussion, however, there where multiple comments along the lines that “once we get our first release out we can go agile, until then however we must think things through, so we’re sticking with waterfall”, or “in our environment demands on <insert requirement here> is so high that we cannot use agile”.
To me these arguments express a misconception of agile which I meet now and again. The misconception is that Waterfall is the “standard model” and if there are some particular circumstances you are “allowed to become” or “might benefit from” Agile.
I think the reasoning is backwards. There is no way that thinking everything through before starting can be better than starting out to get quick feedback. Unless your cost of adopting and adjusting based on that feedback is very costly. Agile, and Lean, techniques are very much about reducing this cost. It is the avoidance of this cost by reducing it that is Agile, and by avoiding it by avoiding the adjustment that is Waterfall.
So the only way to reason is to start with an Agile viewpoint, embrace the feedback and the adjustment that we can make based on it. That will bring us the best product to the market with the best possible cost/functionality/quality ration. If there are reasons why the cost of this adjustment is prohibitively high, look for ways to lower it, e.g. by adopting some of the Agile or Lean techniques. If that is impossible, move the problem towards a more “early decision”. But make sure that only influences the things which are prohibitively costly to act on the feedback.
I strongly believe that the viewpoint that Agile have is going to be, will have to be, the way all developing organisations will have to take in the future. The “Agile viewpoint” brings so much business benefits that companies not adopting it will not exist. There is no longer a price per hour competition, its about maximizing business value per invested dollar or euro.
Yesterday I held a 1 hour+ presentation/discussion for the Management Team of a large organisation. They met up at Vidbynäs Castle to discuss and find inspiration for their next steps into the future. I was invited to talk about Agile, of course.
There was a lot of good questions and I liked the audience very much. I hope I made some points valuable enough for them to bring back to their own part of the organisation. It is difficult to sift out the important points from the million things you want to say, but these are the slides I showed.
On a side note it was not summer as in the photograph, it was the first snow “storm” this winter with 15 cm of snow. The 200 km drive (one way) was, hmm, interesting…
I stumbled across Objectmentors website and noticed that they did help their customers with “Legacy Systems Design”. My customers have no need for help in that area, they are doing this just fine by themselves 😉
I read Uncle Bobs blog about him recording a Katacast of Prime Factor kata in Ruby, with music. (His main point, and my own when I speak about TDD and katas, is of course that to become a professional you really need to take your practicing seriously, only then can you excel!)
I recommend a read for any of you coders out there. Then you can visit the Katacast website for some more examples.
Strangely, this much resembled what me and Andreas did at XP2009 on the session that Emilie Bache organised, although without music. I coded and Andreas commented. We had decided on trying for the complete Bowling Kata in Java with Eclipse so we had to do exactly what Uncle Bob said he had to do, practice, practice, practice and optimize, to fit it into the 20 minute slot we got.
Again, like Uncle Bob said, it was great fun! I very much enjoy working these things with Andreas, we seem to complement each other well.
I’m now on the train from Copenhagen to Malmö. This was not planned. Again the flight from Budapest as delayed. This time, again, enough to make me miss my connection at Kastrup. So about every other flight from Budapest is more than 30 minutes late. Maybe they need to fix the root cause…
But this post will be about the way the airline and airport personell handled the situation. Or didn’t…
The flight was scheduled to leave at 17:45. We boarded and as usual we had to wait for something for about 30 minutes. Since there is about 3 hours for transfer in Copenhagen this is often not a problem, so I was calm.
Then they announced a further delay, due to some mixup at the Schengeln boarder. (Schengeln is a EU-regulation easing the requirements on passports etc. for members from countries agreeing to the regulations.)
After another 20 minutes we where asked to disembark, including all handbaggage. There were two busses outside collecting all passangers. The first filled up and then waited for the other to fill up.
The busses drove us about 100 meters to the nearest gate where we waited for 15 minutes in the busses. We were then let out and led through a security check after which everybody had to wait in a small area for about 1,5 hours. Now, I was starting to suspect that not even 3 hours would help. I would probably miss my connection.
There were no speaker announcements or officials stepping forward, only police, customs, airline and airport personell running around and speaking Hungarian to each other.
Finally, we were rounded up and led to the exit. Outside of which there were two busses of course. The first filling up, and then waiting while the other filled up, before driving the 100 meters to the aircraft. There we waited for another 15 minutes in the busses, before boarding, this time only through the front entrance.
The boarding took extra long time, mostly because people did not return to their original seats, probably because they thought they could get off substantibly faster from another seat. This caused many changes of seats during the boarding.
So the aggravation, and the delay, was worsened by personell, and passengers, not keeping the flow.
Finally, after a delay of 3 hours we took off. Before performing the usual security demonstration the stewardess asked if we wanted to know what had happened! Maybe she, and the other officials, would have had less unhappy passengers if they had thought about telling us that much earlier.
It turned out that the mixup was that some people coming from non-Schengeln countries managed to skip security checks. So they had to close down the whole airport and empty all pending aircrafts to make sure that there was no threats. So while we were in the terminal waiting they had checked through the complete plane.
Knowing that the delay was about threats and security would most definitely had made passengers accepting the procedure more readily, instead of just being told what to do.
Powered by Qumana