As a quick follow up to my previous post, Nokogiri works fine on Solaris 10 as long as you link to the most current version of Libxml2 (2.6.31). Our problem was that, although I had installed the newest binaries, Nokogiri was linking to a previous version (2.6.10). Once we updated the link, by changing the LD_LOAD_PATH environment variable, everything worked great.
At work I have been playing around with Webrat to see if it can speed up our acceptance tests. We have been using Selenium, but the tests are taking far too long to run (somewhere around 40 minutes or so, rough guess). And the majority of the tests are not testing JavaScript or AJAX.
In the tests that I did, Webrat worked amazing with a huge speed increase. One test went from 134 seconds down to 2.5 seconds. The glitch is that Webrat is designed to be used with a Ruby web app–Rails, Merb, Sinatra, etc–and we want it to test a Java app running in Tomcat. Thankfully, this is fairly easy to do. You just need to set the mode to Mechanize and add a few lines to include Webrat::Methods and Webrat::Matchers into RSpec.
The problem we ran into was when we tried to run the tests on our Solaris box. Nokogiri is only returning the doctype and comment parts of the fetched HTML. Running the following in IRB only returns the doctype:
>> require 'mechanize'
>> require nokogiri'
>> a = WWW::Mechanize.new
>> r = a.get("http://www.google.com")
>> s = Nokogiri::HTML(r.content.to_s)
>> puts s
=> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
On Ubuntu and my MacBook Pro, this prints out the entire HTML, under Solaris, it only prints out the Doctype. I have raised a ticket with Nokogiri, but am wondering if anyone else has experienced this? The only difference between Solaris and our Ubuntu dev boxes is the version of Ruby, 1.8.6 p0 and 1.8.6 p111 respectively.
Siva Jagadeesan has posted an interesting article titled, “Fresher and Experienced Developers – Friends or Enemies ?” In the article he lists some of the advantages and problems of pairing freshers with experienced devs. He touches on many of the problems I have with pairing and does a much better job expressing some of my frustrations then I did.
I think I fall somewhere in between a fresher and an experienced developer, but I can definitely relate to all the problems listed. It is amazing how your morale suffers after 5 days watching someone else code cause you don’t know enough to contribute.
I have a problem with the solutions Siva gives though because they all seem to be aimed at the fresher. It takes two to have a problem and as such would like to offer up some advice to the experienced dev:
Also, one thing I think we miss is that fresher is both someone new to programming, e.g., someone just out of university, but also to someone new to the code base.
One thing I have been thinking about lately is who owns, or should know about, tech tasks. The team I am on right now, we need to justify every tech task we do with business and if business value for that task cannot be found then it doesn’t get done.
For some reason, I really don’t like this approach and for the first time, I have read a blog that expresses what I have not been able to as of yet. John Pither calls this tech leakage and explains it as such:
If we can see the dev team as an animal in the jungle (and so forth we have other ‘animals’ such as QA teams, BA teams, Project Managers etc), then ‘dev team leakage’ refers to the cutting open of such a large and volatile jungle beast and of letting it’s gooey entrails slide out and slither amongst the wider natural setting of which the poor animal finds itself.
Yep. Basically it’s about breaking encapsulation. In the case of a dev team, there are many inner workings that need not be externalised to the outside world.
As graphic as this analogy is, I really like it (okay, I have a morbid sense of humour). Tech tasks should belong to the dev team and simply be a part of how we do our day to day jobs. I find that I spend far too much time explaining why I am doing a particular refactoring to a BA or business because the team does not own these tasks. In addition, far too many tasks never get done because we cannot justify them with business value.
One consequence of this anti-pattern is that nothing really comes out of retrospectives. Yes, do them every week, however, every action we create must first be justified with business and given some business value before we are able to carry it out. This means that we never have the chance to clean house and carry out those dev tasks that we should be doing as a part of our jobs.
One practice that I have observed that seems wrong to me is re-estimating cards after they have been completed. The dev pair completes the story card and the BA comes over and asks them to re-estimate the card based on the implementation.
From the BA’s point of view, s/he is asking for the re-estimation for planing purposes. The reason given is so they can accurately plan out the stories for the next iteration. On this same project, there is also a lot of talk about correctly estimating cards. To me, this completely misses the point of estimating cards.
Story card estimation is a best guess of either the complexity, the story card size, or the ideal days needed to implement the card. That is all. This means that the estimations are inherently wrong. The point though is that they will be consistently wrong and over time, with the addition of velocity, the amount of work a team can get done will be correct.
If a team consistently underestimates, then the first iteration they will do more cards then they committed to. The velocity will show this and can be corrected the next iteration. So the first iteration they commit to doing 12 points and they actually do 15. The next iteration, simply select 15 points worth of story cards. Rinse and repeat.
By asking devs to re-estimate cards once they are completed you are breaking the corrective effect that velocity has on the process. The points on the cards carry less meaning because they have been adjusted after the fact. This means you now need to add a correcting feature into the teams velocity.
The team committed to doing 12 points and completed 15 points, but two of the cards they originally committed to doing were actually 1s and not 3s so did they in fact do 15 points or 19 points? So which cards for the next iteration are going to be re-estimated down and which cards will go up? Does this mean that the team should be doing 15 or 20 points for the next iteration?
My guess for the re-estimation requests is that the BAs do not trust the process. They do not believe that velocity will naturally add the needed correction. So instead, they try to do it themselves. In addition, on this particular project, I also think that business is trying to add to many features during a single iteration and the scope is just too large.
I think there is a time and place for re-estimating a story card, but after the card has been played it not one of them. If, before playing a card, more information becomes available that directly reflects the implementation of a card, that card should be re-estimated. This might include the outcome of a spike or the introduction of a new technology or a change in the development team for instance. The point is that this happens before a card is played, not after.
What do others think, can a story card’s estimate be updated after it has been played?
I have been trying to learn Agile software development for the past several years and there are several things I don’t quite understand and I’m hoping people can enlighten me.
This one I think I might understand to a degree. I agree with the idea that comments can very quickly get outdated and far removed from the code that they are suppose to comment. I also understand that if you write clean code then “what” comments are unnecessary. The thing I don’t understand is why this means that we should actively go through a code base and delete all comments? Or why we as developers should deride code that contains comments?
I personally think there is a place for “why” comments in a code base. I come across an odd bit of code, an odd business rule implementation, should I have to go and find the user story to find out why that particular odd decision was made? Or should I have a unit test explaining it: shouldDoThisBecauseIn1973BusinessMadeAOneOffDealWith...(). Where is the right place for this information to be captured? I would think that a story card would travel farther away from the code even faster then a comment.
This is probably my biggest pet peeve about Agile and the thing I really don’t understand. Why is design evil? We seem to have this idea that doing up front design before starting a story is not allowed. You cannot be doing XP if you do design, “design is waterfallish, we have organically grown code here.”
Personally, I think that in order to have well designed, clean, layered code, you need to do some design up front and you need some kind of architectural model to which your organically grown code adheres to. Otherwise, instead of lasagne, you get ravioli.
I have already stated that I don’t really know how to pair and this is an outcome of that. I have heard of shops were if you are not pairing you are not coding. Heaven forbid that either you or your pair are ever sick. Are there no kinds of coding jobs that can be done by one person? Is there no benefit or place for a single programming sitting quietly in a room with the door closed focusing on a problem? What about all those studies that have been done about flow and the fact that open offices promote sickness and disease? What about a little privacy during the working day?
This is the thing I don’t understand the most. Why is it that for many people and many shops, Agile principles become rules and the only way to do things? I have met people and worked in shops were they have Agile all figured out and any deviation is heresy. If you are doing Agile this one way, then you are unprofessional and a very bad programming. I always though that principles were just that principles, guidelines, starting points, rules of thumb. Things to be discussed, to be examined, and possibly bent or even broken when the situation calls for.
Isn’t one of the prime tenants of Agile the idea that we should analyze what we are currently doing and make it better. Doesn’t this mean things need to change? Or does it mean we are not disciplined enough in our adherence to one true path of Agile?