This week we posted a video with Stephan Janssen.  Stephan is a great guy and an important voice in the Java and Flex communities. Check out the video here.

James and I finally posted the next video in our Drunk on Software series.  In this episode we talk with Adobe System’s Chet Haase about a bit of everything.  Enjoy!

http://www.drunkonsoftware.com/2008/12/08/episode-4-when-i-am-king/

I have been hearing really good things about Mate for a few months now.  I have been rebelling against dragging additional frameworks into Flex just for MVC for a while now (Flex and MVC /  Cairngorm).  I finally got a chance to spend some time coding with Mate on a flight back from San Fransico this weekend.  I think it looks promising.  I am still not sure the leverage is enormous, but the cost seems low.  It appears to provide a reasonable structure for Separation of Concerns and managing events, without requiring much additional code.  Hopefully, I will have some more time to do something more complex soon with it, but I think it may be the type of framework I have been wanting.

I was chatting at the office last week about code quality, and thought I would jot down some of the things we talked about.  I think it is fair to say that it is difficult to know when code is “good” and when it is “bad.”  There are of course obvious times when the coder was incompetent, or cut corners with little explanation.

Ignoring those types of issues, judging code is difficult because we do not understand the reality of when the code was written.  Was the code written with an extreme deadline?  Was it built with a clear expectation of being prototype code and then put into production by some aggressive manager?  Was the architecture changed multiple times without time to rewrite / refactor?

In addition to not understanding the actual circumstances around the time of original development, developing perfect code is expensive and there is a point where we all need to ship our imperfect code and move on.  Only a really rich, somewhat misguided, client would pay for the real amount of time to develop perfect code.  And of course, we have to understand that much of our feelings toward code come back to style and preference, and not everyone has the same approach to these items.

So, let’s all try and buck the tradition of bashing the last guy’s code, and when there are real issues that need to be addressed then please approach them gracefully.  Remember, someone will be following you soon too!

I am listening to the latest Java Posse podcast, a session from this years round-up titled, Don’t Repeat Yourself. In the discussion, Tor Norbye made the statement that, “programming is all trade-offs.”  This is a great point.  For what ever my strengths and weaknesses are as a developer, I have long believed that one of the main values I bring to each of my projects is a natural cost benefit analysis mechanism.  It seems that most anything is truly possible in software these days.  So, understanding the costs of each decision is one of the most important parts of building quality software.