My Stuff
Front Page
Favorite Quotes

Vincent Foley-Bourgon
Sam Griffith
LeRoy Mattingly
Colin Putney
Matt Secoske
Sam Tesla
Andres Valloud

Leo Brodie
Avi Bryant
Alan Cooper
Steve Dekorte
Stephane Ducasse
Doug Engelbart
Eric Evans
Brian Foote
Martin Fowler
Paul Graham
Dan Ingalls
Alan Kay
John McCarthy
Steve McConnell
Peter Norvig
Niall Ross
Randall Smith
Gerald Jay Sussman
David Ungar
Rebecca Wirfs-Brock
...And So Many More...

My Amps
Corman Lisp
Dolphin Smalltalk
Cincom Smalltalk

05/01/2003 - 06/01/2003
06/01/2003 - 07/01/2003
07/01/2003 - 08/01/2003
08/01/2003 - 09/01/2003
09/01/2003 - 10/01/2003
10/01/2003 - 11/01/2003
11/01/2003 - 12/01/2003
12/01/2003 - 01/01/2004
01/01/2004 - 02/01/2004
02/01/2004 - 03/01/2004
03/01/2004 - 04/01/2004
04/01/2004 - 05/01/2004
05/01/2004 - 06/01/2004
06/01/2004 - 07/01/2004
07/01/2004 - 08/01/2004
08/01/2004 - 09/01/2004
09/01/2004 - 10/01/2004
10/01/2004 - 11/01/2004
11/01/2004 - 12/01/2004
12/01/2004 - 01/01/2005
01/01/2005 - 02/01/2005
02/01/2005 - 03/01/2005
03/01/2005 - 04/01/2005
04/01/2005 - 05/01/2005
05/01/2005 - 06/01/2005
06/01/2005 - 07/01/2005
07/01/2005 - 08/01/2005
08/01/2005 - 09/01/2005
09/01/2005 - 10/01/2005
10/01/2005 - 11/01/2005
11/01/2005 - 12/01/2005
12/01/2005 - 01/01/2006
01/01/2006 - 02/01/2006
02/01/2006 - 03/01/2006
03/01/2006 - 04/01/2006
04/01/2006 - 05/01/2006
05/01/2006 - 06/01/2006
06/01/2006 - 07/01/2006
07/01/2006 - 08/01/2006
08/01/2006 - 09/01/2006
09/01/2006 - 10/01/2006
10/01/2006 - 11/01/2006
11/01/2006 - 12/01/2006
12/01/2006 - 01/01/2007
01/01/2007 - 02/01/2007
02/01/2007 - 03/01/2007
03/01/2007 - 04/01/2007
04/01/2007 - 05/01/2007
05/01/2007 - 06/01/2007
06/01/2007 - 07/01/2007
07/01/2007 - 08/01/2007
08/01/2007 - 09/01/2007
09/01/2007 - 10/01/2007
10/01/2007 - 11/01/2007
11/01/2007 - 12/01/2007
12/01/2007 - 01/01/2008
01/01/2008 - 02/01/2008
02/01/2008 - 03/01/2008
03/01/2008 - 04/01/2008
04/01/2008 - 05/01/2008
05/01/2008 - 06/01/2008
06/01/2008 - 07/01/2008
07/01/2008 - 08/01/2008
08/01/2008 - 09/01/2008
10/01/2008 - 11/01/2008
01/01/2009 - 02/01/2009
09/01/2009 - 10/01/2009


Add this feed to a running copy of BottomFeeder

Thursday, September 28, 2006

XP Youth

Obie Fernandez had this to say about pair programming:
Truth is, pair programming is one of the only effective ways that a lot of us have ever witnessed keeping average developers from pissing away 95% of their productivity engaging in non-work such as reading and writing blogs, instant messaging, personal email, shopping online and otherwise wasting time on bullshit.

So, we need the XP youth to keep us inline? If I'm not doing my job, I should be fired. Period. End of story. We all can't be above average, but we all need mental breaks (I doubt most developers spend 95% of their time shopping online).

Pair programming has pluses and minuses. It takes a certain personality to be good at it. I've had very few good pairs in my career. Nothing can match the creativity of two minds locked in a common crusade. It's great. BUT, I have found it takes a person that can take constructive critism of their ideas, is vocal, loves programming, and the most important: listens. Your average developer if he's browsing the net for 95% of his time probably doens't "love" what he/she is doing. I found while pairing can give the illusion of productivity, it's easy for one part of pair to be asleep at the wheel to speak. If you don't love what you do, you will find ways to avoid doing it no matter what hurdles managers throw at you.

I love pairing with passionate yet humble programmers (the greatest minds I have met have been this way). But, I hate pairing with ego maniacs. I love short bursts where we colloborate intensely and then go program solo for a short while. Get back together and show each other what we did. Rinse, repeat. I find it keeps the creativity spark alive (because you can experiment without the sucritiny of another to verify if the idea is good) and the interaction rich. It allows the feeling of working together, as well as ownership of a piece of it.

Pairing should be something that is not mandatory. It should be up to the programmers. Anything forced is going to cause people to find ways around your dogmatic rules. It's human nature. XP should be agreed upon, not enforced.


Confession Time

"A wise man changes his mind, a fool never" - Spanish Proverb

Well, at least it makes me feel better right? Well, I have a confession to make. In the past, I have argued for the use of accessors on instance variables. I liked accessors because they looked the same in the code as a method call and the flexibility. But, several months ago, I tried writing code without accessors. I was shocked by what I found about myself. First, it was hard after programming with accessors for so long and it didn't feel natural. But, I got over that in the first month or so. Second, I noticed that I broke encapsulation of my objects less. In fact, if I felt the need to access an instance variable outside of my class, I questioned myself thoroughly and generally tried to find another way.

I thought I was writing good code, but I was making little sins that added up. Forcing myself to use accessors only when necessary caused my objects to be more self-contained. I started writing smaller objects. My code got way better. So good in fact, that I find myself on the other side of the accessors debate.

Yes, I now frown upon the use of accessors by default. It leads to data structures (not objects) and controllers (not objects). The funny thing is the road to breaking encapsulation is one paved with small sins along the way. Besides, with today's tools, it's easy to switch the accessors if needed.

Oh well, I had to get that off my chest.

  • Just wondering... why should a sender know the message being sent is an accessor? What difference does it make to the sender to know that?

    And in fact, 99.999% of the time it should not make any difference whatsoever.

    So how come senders care? Perhaps THAT is the issue.

    IMHO, if the thing is designed improperly, it is going to stay that way with or without accessors, with or without Smalltalk.

    By Blogger Andres, at 2:10 PM   

  • Yeah, well, DUH!

    Seriously, a sender should never care. The point was not to expose the accessors unless you need to. Take a Money object for example. Do you really care how the amount is calculated? It could be an Integer based on cents or a BigDecimal. It doesn't matter. I have found that keeping your object's internal under tight control gives better designs. You start writing smaller objects.

    I just believe that by not using accessors by default then I'm not polluting my object with needless noise. I'm also making a conscience decision when I do decide to expose an accessor. It makes me develop better. It's too easy sometimes to just call the accessor simply because it's there. I know you could think about calling it then, but sometimes in the heat of the moment, you forget it's an accessor.

    Staying away from accessors by default gets us away from procedural code.

    By Blogger Blaine, at 7:52 PM   

  • I think this illustrates the issue pretty well, but does not yet state it clearly.

    The problem is that developers usually write code in the first person --- "I send the message". Usually this is because of fear --- "objects, do as I say and otherwise stay frozen". With or without accessors, that is a problem already.

    In my experience, procedural code in environments like Smalltalk is a direct manifestation of fear, or at least an inability to let go of control.

    I use accessors for every instance variable. But I also put most of them in categories such as "private - accessing", and respect that by having other objects not use them from the outside. Typically, that leads to objects understanding useful messages such as doWhatYouHaveToWith:, instead of this:

    anObject instanceVariableA: such.
    anObject instanceVariableB: such.
    mov cx, word ptr [es:bx]
    mov dx, word ptr [es:bx+2]
    anObject run

    But... hey, just my opinion :).

    By Blogger Andres, at 9:21 PM   

  • Blaine - I've been trying a similar experiment, the bit that kept slapping me in the face was how to initialize instance variables from my class constructor.

    Having a private wide #initialize method was fine but its a nuisance typing it in (and maybe this is just a tool problem) vs. using the generate accessors option and then doing

    ^self new fistName: blah; lastName: blahblah; yourself.

    So I've been using categories. Of course now I should really extend my Lint checker to find calls to private from outside the calling hierachy, or maybe I should just write the darn CreateInitialze tool.


    By Blogger Tim, at 3:40 AM   

  • So, is your point that accessors should be used in moderation or not at all? I think, by your reply to Andres, that you are saying in moderation. I agree, although at times, it just feels good to setup everything and not worry about it later.

    If instead, you are saying just use the variable directly. Well... that just doesn't feel very good. Inside my object, I still use accessors quite frequently. The overhead is minimal and I find the solution more elegant and desirable.

    I understand your point and it is a good approach to disciplined design. I just can't help myself :)

    While variables provide an object with structure and substance, the dialogue breaths life into the system, making interactionsh with the object, not just possible, but beautiful and desired.

    By Anonymous Anonymous, at 11:27 PM   

Wednesday, September 27, 2006

Too Many Toys?

I sometimes wonder do developers have too many toys? In Java, we have a plethora of open source frameworks to choose from for our next or current project. There are so many options that it can literally make your head spin right off! I've been on several Java projects in my career and every single one of them has used a different technology stack. In fact at my new job, I didn't know a few of the frameworks that were being used at all. With all of these technology choices, it would seem our life should be a piece of cake, right? Well, guess what? It's not.

There's one thing that hasn't changed. Good design and thought. Frameworks are only amplifiers in this regard much like languages. They can make our life easier if we apply them to good sound design principles. But, I think that's what is missing in our field. Go to any Border's and Barnes and Noble bookstore. Hell, go to any coder's shop and what you will find are rows and rows of books on the latest "cool" frameworks and languages. It's all vocational. You might find a little section on design if that. And it's not like we don't have great books on design. Hell, I can list several and still have more to recommend! These are the books that will stay on my shelf long after the latest framework fad or language has gone to the legacy island of old technology. It amazes me how many developers are up on the latest technology, but have never read a book on design (or maybe just one).

It shocks me. Knowledge is our most treasured asset. I strive to understand the core concepts and to go beyond. I'm always trying to learn from anything I can find (even non-software books) if it can give me a glimmer of understanding more about our field. Sometimes, I think though, we get so caught up in the flavor of the month, that we neglect the knowledge that will survive after the fads are dead.

Do we have too many toys? We're spending all of our time playing with them and not learning the core concepts that's behind them. I think that's sad. I love solving hard problems, but I want to spend my learning the problem domain. I want to learn the business of my users so I can solve their problems in elegant ways. The world of business is one of the most fun beasts to tame. I don't get excited anymore about applying the latest technology to a problem, but by solving it period. The tools needed are in your head. The frameworks only amplify what is at the core. When push comes to shove, it's still takes thought to do a good design.

So, here's my solution: read one non-vocational technical book per year. Understand it. Become it. Or at least be able to argue why you hate it. I read more books about design that any other every year. It's time well spent and it only makes you a stronger developer. Rock on, brothers!

  • I can't resist to add a book to your recommended list. The one I like the most:

    By Blogger Dan Rozenfarb, at 1:17 PM   

  • How could I forget! Another classic in my opinion. Gosh. I'm going to have to create a list of great books ain't I? Too much great knowledge out there and there's still so much that I haven't even experienced! Life is too short!

    By Blogger Blaine, at 1:46 PM   

Wednesday, September 13, 2006

Design Patterns of 1972

Sam Griffith sent me a link to "Design Patterns of 1972". What a great read. It's a call to arms to take our languages further. Mark uses several pattern examples from computing past and shows how they were implemented later into programing languages so that they became eventually invisible. I loved the fact that he says that we shouldn't stop at design patterns, but figure out how to incorporate them into our language. I've long believed we are doomed to repeat past sins if we don't research the paths traveled before us. Just go read "Software Fundamentals: Collected Papers" by David L. Parnas and prepare to be shocked if you doubt what I say. Anyway, Mark's article is awesome and thanks goes to Sam for showing this to me!

Now, let's roll up our sleeves and take our industry further!


Sunday, September 10, 2006

I miss Zappa

I wish Zappa was still around. I always loved his wit (read his autobiography if you have a chance, it's classic). This exchange between him and a talk show host is too funny (via "Influence: The Pyschology of Persuasion" by Robert B. Cialdini).
PINE: I guess your long hair makes you a girl.
ZAPPA: I guess your wooden leg makes you a table.

Made me laugh. Time to fire up "Grand Wazoo".

  • Yes, most of us (would he were still here) should not try to match wits with Frank Zappa.

    BTW "Influence" is one of my favorite books. I'll have to try the Zappa book, thanks.

    By Blogger Patrick Logan, at 2:48 PM   

  • planeta Zappa
    Un planeta y un blog con el nombre de Frank Zappa (3834) Zappafrank Planet number 3834 has been named in honor of innovative rock musician Frank Zappa.

    By Blogger carloszerpa, at 9:49 PM   

Thursday, September 07, 2006

Working On The Railroad

My new job is going fantastic. I'm programming in Java and learning a ton of new frameworks. I'm becoming very impressed with Tapestry. And it's great to finally see Spring in action. The domain is challenging. This is the first time I've been in the shipping business so everything is new. Of course, business is business so there is some familiarity. I am having an absolute ball. Oh, did I mention I have a window seat? Well, I do!


Time And Money Library

I'm proud to announce that I am the project manager and a developer for the Time And Money Java Library. It's an exercise in Domain Driven Design. I'm having a lot of fun with great developers. ROCK!


Monday, September 04, 2006

Updated: Comment Unit Tests For Ruby

I finally got around to updating my Comment Unit Tests For Ruby just for the fun of it. It's more robust, has a better model, and it has tests. I can now put unit tests in the comments of my code. I started using it on a project that I have and I'm loving it!

Here's a simple example:
### >>> 3 + 4
### >>= 7

You can even use variables:
### >>> a='i'
### >>> b=' love '
### >>> c='michelle'
### >>> a + b + c
### >>= 'i love michelle'

And if they are part of the same comment, it will keep the variable bindings active, so you can do this:
### >>> a + ', robot will never die'
### >>= 'i, robot will never die'

And finally, if comparing two objects bores you, then you can create your own equality check like this (notice the >>>?):
### >>> a = 5
### >>> b = 4 + 1
### >>? a == b

Enjoy and Ruby on!


Saturday, September 02, 2006

Functional Programming Considered Harmful? Nonsense!

Luke Plant recently wrote a blog entry on "Why learning Haskell/Python makes you a worse programmer". He rants about how difficult it is to write in a functional way in C# (and Java as well). And ends with this quote:
The moral of the story: don't bother improving yourself, unless you have the freedom to improve your environment accordingly. That's rather depressing. Can anyone put a better spin on this and cheer me up?

After reading this article, I was reminded of an argument to remove objects and blocks from Smalltalk. Basically, the argument of closures versus objects is futile. They both have their place and strengths in design. But, without closures, you can use simple objects as a substitute.

Luke's article argues how hard it is to instill functional programminging in languages like C# and Java. I think while it is hard to use pure functional style in these languages, it's matter of changing the way you think about it. I find since I don't have blocks/closures in Java, I use more of a stream approach (think pipe/filter pattern). It's a little trickier in the iterator objects, but the users of the code have to write less and their code is easier. I used this technique to good effect in my Reflective Testing Framework. As for side-effect free programming, I think it's a good goal to try to attain. We have a thing called encapsulation which can localize the effects of change. It's all in the way we think about it.

So, the next time, you see a road block because Java or C# doesn't have some feature from one of your favorite dynamic or functional languages. Think about the goal of the feature and ways you can attain it. Sure, code is more succint in Ruby, Python, Haskell, Scheme, and a host of other languages, but for those of us in the trenches, we might not be able to use them. We're stuck with Java/C#/C++. Be creative and remember to always keep your code easy to understand.

  • Heh heh. I don't think anyone ever understood what I wrote--though that's probably nobody's fault but my own--except that it didn't help that Vassili immediately spoofed my message. The point I wanted to make was that blocks and methods have overlapping functionality, and that Smalltalk could conceivably be simpler (and thus be per capita more powerful) if you removed the overlap.

    So, my post wasn't really about removing Blocks from Smalltalk (despite the title--which is the only thing most people read).

    By Blogger David Farber, at 5:20 PM   

Web hosting by ICDSoft

Metalheads Against Racism
This page is powered by Blogger. Isn't yours?

My Weekly Top 20 Artists