Things you should never do

Joel Spolksy has a great series of posts about the netscape project moving from version 4 to version 6 and the major mistakes they made along the way.

Among my favorite from the articles:

There's a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:

It’s harder to read code than to write it.

Winston Churchill Quote

Constant effort, not strength nor intelligence, is what reveals our potential.

XAML Power Toys

XAML powwer toys can "quickly create a form complete with bindings if desired" from a selected class.

http://karlshifflett.wordpress.com/2008/08/31/xaml-power-toys/

Instant Message In Style

Digsby messaging client provides instant messaging in style.

I have used many IM services over the years. I started with AIM and ICQ, moved to GTalk and MSN about 4 years ago, and now have been spending a lot of time on facebook's in browser chat client.

For the last 4 years I have been trying to find a really good chat client that actually works with all my services. I used trillian for a long time, but got frustrated that I had to pay for it. Then about a year ago I started using meebo. Meebo has always seemed weird... gooing to a website to chat.

Today I have found the answer to my problems. Digsby is a IM client for Windows, Mac, and Linux. It supports every service I mentioned(Including facebook and twitter!) So far I am absolutly blown away by this application. It docks nicly in the corner of the screen, handles away messages across services, does local logging of message history, and the user interface looks great.

Hit the jump for screenshots of the application.

Prototype VS Production Code

I have always enjoyed projects where the concept of prototype code is carried out in a good manor. I personally have little to no problem throwing away code that is deemed "prototype code" even if it was not intended to be a prototype. I like to ask myself a few questions about a project or feature to help me understand if what i have developed or am about to develop is indeed a prototype.

1) Do I posses enough knowledge about the feature or product to produce a well thought out high quality design? Would something concrete help me explain my lack of understanding?

2) What is the likely hood that what I produce with the knowledge at hand will be a worthwhile contribution to the product?

3) Are we sure that we will develop this using the proposed dependencies? Are we likely to add or remove a dependency or third part component?

4) How technically feasible is the task? Would a simple proof of concept boost my confidence?

5) Does the implementation feel like it is clean, broken out into appropriate units of work? How easy was it to test? Are my tests short and easy to maintain?

6) Have i given the design consideration? Am I shooting from the hip?

A quote from the book "Code Complete" identifies a very good definition of what prototype code is. It challenged me to continually evaluate my behaviors and ask myself if I am turning prototype code into production code.

"A final risk of prototyping arises when developers do not treat the code as throwaway
code. I have found that it is not possible for people to write the absolute minimum
amount of code to answer a question if they believe that the code will eventually end
up in the production system. They end up implementing the system instead of proto-
typing. By adopting the attitude that once the question is answered the code will be
thrown away, you can minimize this risk. One way to avoid this problem is to create
prototypes in a different technology than the production code. You could prototype a
Java design in Python or mock up a user interface in Microsoft PowerPoint. If you do
create prototypes using the production technology, a practical standard that can help
is requiring that class names or package names for prototype code be prefixed with
prototype. That at least makes a programmer think twice before trying to extend pro-
totype code (Stephens 2003)."

Design Is a Wicked Problem

I have found in my career over and over that whenever you have a complex problem the first pass at design is rarely the correct. Every time you start a complex project and design a user interface prototype it changes several times before a usable design seems to emerge. Usually at the end of a project you look back at the initial design and laugh!

Inevitably a good design usually happens through showing the customer the design and working through the problems and gaining understanding through communication and reviewing the user interface with the customer.

I stumbled upon this quote today that accurately describes what I have learned.

This paradox implies, essentially, that you have to solve the problem once in order to clearly define it and then solve it again to create a solution that works. This process has been motherhood and apple pie in software development for decades (Peters and Tripp 1976).

Server Room in the womans bathroom???

This WTF post is hillarious. I will never say a negative word about a server room unless it's in the handicap stall!

http://thedailywtf.com/Articles/The-Stalled-Server-Room.aspx