Here is a nice little ad for Apple about why the “37signals guys use Macs for all their development work”:http://www.apple.com/education/whymac/compsci/video.html. It’s a commercial, but it’s also for Apple so I had to post it.
It took less than 24 hours for the “first security vulnerability to be found in IE7″:http://geeksaresexy.blogspot.com/2006/10/first-security-flaw-signalled-in-ie7.html. For a product that has been out in the wild as a publicly available beta for as along as IE7 was, you would think it would last a little longer before a hole was found, but apparently not. I think I will wait a little bit before installing it.
Empathy Box has an excellent article titled, “5 Principles For Programming“:http://empathybox.com/archives/8. It lays out the following principles that programmers should following when working on applications:
* Fail Fast
* Write Less Code (and Don’t Repeat Yourself)
* Computer Programs Are For People
* Do The Right Thing
* Reduce State
* Know Your Stuff
This is an excellent article and should be read by anyone involved in the art of programming.
The point that I personally like best is the third one: Computer Programs are for People. I have seen this pop up in another post recently (I just can’t remember where). Although the following quote is only cited in the article, I still really like it and it will definitely shape the way that I program from now on.
bq. We want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute.
The quote is attributed to the book “The Structure and Interpretation of Computer Programs.”:http://www.amazon.ca/gp/product/0262011530/ref=pd_rvi_gw_1/701-2518291-1669962?ie=UTF8 This is one of the books suggested on “Kathy Sierra’s blog”:http://headrush.typepad.com/creating_passionate_users/2006/10/the_book_i_wish.html and one that I have added to my reading list.
Something that I have been thinking about over the last two day is what is the correct method for documenting, as in Javadocs, Interfaces and their implementations? Generally, what I have been doing is putting the bulk of the Javadoc comments in the Interface and then either copy/pasting the comments into the implementation or creating a smaller comment. However, I can’t see how either of these methods is correct.
I know Eclipse uses a special little annotation-like thingy to tell you to go look at the docs for the Interface, but I am not sure if this is standard as it clearly states that it is not a Javadoc.
I guess the idea is that the Interface holds a general comment about what the method should do while the implementation should contain details of what the implemented method actually does. On the surface, this seems obvious. But what happens when you only have one implementing class? Should you still try and come up with a general comment for the Interface and a specific one for the implementing class?
Anyone have any ideas on the best way of commenting Interfaces versus Implementations?
Robert L. Glass has written a short article on developer.* that lists some “surprising discoveries about project success and failure”:http://www.developerdotstar.com/mag/articles/software_success_failure.html. The points that I found interesting were
bq. Most projects that had no schedule were successful
Although I am not sure how you judge success on a project with no schedule?
bq. The choice of requirements methodology does not matter; UML was “no help”
This one I find interesting only because at work we have put a very high importance on the use of UML and Big Up-front Design. Personally, this is something that I am beginning to question. However, I do think it has a place when you are trying to create software with co-op students and a very inexperienced team of developers.
bq. Requirements are needed for project success, but not necessarily early in the project
I guess all those Agilists are right 
bq. The vision for the project (its business goals) must be shared among all project personnel, especially the project manager
This point was listed under the heading “Predictable”. And I would definitely agree with it. The project I am currently working on, everyone, from senior management all the way down to the developers, have a different view of what the project should be, how it should be created, and what it should do. This does not make for a very healthy environment. In fact, I would call it downright hostile at time.
If you check out the article, also check out the comments for some insights from the trenches.
Kathy Sierra has asked readers to list the “fiction and non-fiction book they feel everyone else should read”:http://headrush.typepad.com/creating_passionate_users/2006/10/the_book_i_wish.html. With over 90 comments, the list is getting a little long to read through. I don’t really have any books to add, but I did fing several that I am adding to my book list:
* “Linked: How Everything Is Connected to Everything Else and What It Means”:http://www.amazon.com/Linked-Everything-Connected-What-Means/dp/0452284392
* “Godel, Escher, Bach: An Eternal Golden Braid”:http://www.amazon.com/G%F6del-Escher-Bach-Eternal-Golden/dp/0465026567
* “Structure and Interpretation of Computer Programs - 2nd Edition”:http://www.amazon.com/Structure-Interpretation-Computer-Programs-Engineering/dp/0262011530
* “Innumeracy: Mathematical Illiteracy and Its Consequences”:http://www.amazon.com/Innumeracy-Mathematical-Illiteracy-Its-Consequences/dp/0809058405
* “Complexity: The Emerging Science at the Edge of Order and Chaos”:http://www.amazon.com/Complexity-Emerging-Science-Order-Chaos/dp/0671872346
For any Canadians that may read this site, have a happy Thanksgiving tomorrow and may your turkey be well basted. We really do have a lot to be thankful for living in this country.
