Showing your faults
It's nice to see a more experienced programmer get stuck - it helps remove the mystique. It unites us. It's not like kids applauding when someone drops and breaks a plate in the cafeteria - it's a sigh of relief to discover that other people have the same difficulties we do.
We spend a lot of our time coding in isolation. Particularly when we are beginning, our experience is that when we are stuck we seek out the advice of a teacher or more experienced colleague. Often they can look at the code and spot the problem or suggest a change that helps avoid the problem in the first place.
Seeing that someone you respect runs into trouble now and then is helpful. It reminds us that although we will know more, get better, and acquire more tricks and techniques, we will still make those mistakes that make us go Doh. I appreciate that Gosling takes the time now and then to share these "lack of success" stories with us. We can say "Even Gosling had to ..." the same way a mother stops her child from running out the door without breakfast saying "Michael Jordan eats his Wheaties."
In today's featured WeblogsJames Gosling reminds us of The first rule of debugging: If the bug isn't where you're looking, you're probably looking in the wrong place. This goes hand in hand with the experience that fixing a bug isn't nearly as difficult as locating and isolating it. In his blog entry, Gosling describes spending a great deal of time looking for an error in code that Atsuhiko Yamanaka checked in to add "security features to the ssh web site access facilities." James embarked on a "stupidly fruitless search for a problem in his perfect code. In the end it turned out to be totally elsewhere".
In the Also today section we link to two items on refactoring. The first is David Gallardo's piece Refactoring for everyone. In it, Gallardo presents code examples of some of the more important refactoring supported by the Eclipse IDE. He explains:
The combination of thorough testing and automated refactoring is especially powerful and has transformed this once mysterious art to a useful, everyday tool. This ability to change the structure of your code without altering its functionality, quickly and safely, in order to add functionality or improve its maintainability can dramatically affect the way you design and develop code, whether you incorporate it into a formal agile methodology or not.
Robert Cringely, on the other hand, isn't so sure. He rails against the overuse of Refactoring advising you to leave working code alone:
The key problem, as I wrote last week, is that refactoring means monkeying with working code. If the program isn’t working, you don’t refactor it. Refactoring is supposed to be IMPROVING code, not fixing it. By definition, you only refactor code that is already working, which where I come from is scary. Working code is a valuable asset since it is hard to get right (at least for me) and takes time. Touching working code is always a risk and so there should be a darned good reason for doing it. Adding features, worthwhile refactoring, or bug fixing are all possible good reasons. Tinkering with code or cleaning it up is not.
This bring us full circle, how much time can you save chasing bugs and maintaining code and adding functionality if the code base is clean? Cringely argues:
Does the 80-20 rule apply here, too? If you spend an hour refactoring some code, will you save more than an hour in future code maintenance? If not, then the refactoring is simply not justified on any level.
That's hard to argue. How could I ever prove that time was saved and if so, how much time was saved. Say I refactor five pieces of code (whatever that means) at an hour a piece and only one ends up being the time saver. Should I have only refactored that one?
As an analogy, consider buying a lottery ticket. Of course money spent buying a losing lottery ticket is always not justified. Money spent on a winning lottery ticket is justified. In the case of the lottery, we can prove that in the aggregate your expected value is a loss of money when you buy a ticket.
So with refactoring, proponents argue that in the large it is a practice that has a positive expected value. What do you think?
In other featured Weblogs, Simon Phipps recommends An Open Spirit.
Granted, Simon is biased, but his closing paragraph asks why port a lot of existing Java tools to the Mono project:
Why not instead support Geronimo ? What is the IP encumberance that makes Geronimo unsuitable? The history of the Apache project is that it has acted as a gadfly to Java, causing the (mostly unintended) process bugs to get sorted. I anticipate Geronimo having the same effect, 'outing' the bugs and getting them addressed. Supporting it will strengthen the openness of Java and help ensure a future for choice. My instinct tells me that getting developers working on C#/CLI projects to re-invent the Java wheel will not have the same effect.
In JXTA & Business - The catalog, Daniel Brookshier proposes a P2P catalog built using JXTA. He outlines many advantages of applying the technology to this problem and addresses some of the perceived shortcomings such as speed.
From the Java Today News Page, news editor Steve Mallett, has gathered the following News Headlines .
- WinLAF 0.3 Released
- WSRP Web Services for Remote Portlets Approved by OASIS
- Sun Releases J2EE 1.4 Source Code to Licensees
- JSR 147 - Workspace Versioning and Configuration Management, First Public Draft
- JavaHelp V2.0 Now Available
This blog is delivered weekdays as the Java Today RSS feed. Once this page is no longer featured as the front page of
href="http://today.java.net"> Java Today it will be archived at
http://today.java.net/today/archive/index_09152003.html. You can
access other past issues by changing the address appropriately.