PHP'ers:
Ben Ramsey
Brandon Savage
Cal Evans
Chris Shiflett
Eli White
Elizabeth Naramore
Joe LeBlanc
Justin Thorp
Mike Naberezny
Rasmus Lerdorf
Tony Bibbs
Zend Blogs
Zend DevZone
DC Social Media:
Aaron Brazell
Geoff Livingston
Jessie X
Ken Yeung
New Media Jim
Shashi B
Social Times
Technologists:
Jimmy Gardner
O'Reilly Radar
Scott Berkun
Steve McConnell
Business/mISV:
Bob Walsh
Eric Sink
Gavin Bowman
Guy Kawasaki
Joel Spolsky
Micah Baldwin
Paul Graham
Planet mISV
Past Projects:
CodeSnipers
HOBY
Judicial Watch
mobile Fox Affiliates
mobile FoxNews.com
MyDearJohnLetter
NRTW
techRepublican
Great Tools I use:
BaseCamp
Drupal
getClicky
Highrise
phpUnit
Qcodo
Subversion
web2Project
Zend Framework
This is not the home of dotProject. It is the home of CaseySoftware, LLC. Any dotProject support questions should be referred to their support forums.
When software developers talk about a project, concept, or just about anything else, we normally speak in reference to models. We use analogies, we make comparisons, we have even come up with the concept of Design Patterns just to improve communication. While making comparisons can speed communication, we must choose the right comparisons and acknowledge that no single comparison is going to perfectly describe all aspects of what we're doing. After all, if there was, why would you be doing it again?
I was reminded of this last week when I was at a family Christmas party and I heard:
Person A: That stuff is as slow as molases!
Person B: It *is* molases.
Person A: (pause) Oh.
As you can probably tell, the comment didn't add anything to the discussion. While the point wasn't to share an idea and/or convince someone else of a model, I found it painfully familiar to other discussions I have heard.
Software development is confusing to many people and black magic for many others. We have a responsibility to make good comparisons and analogies in order to translate for everyone else. Not only can we communicate with customers better, but it allows us to communicate with each other better.
Think about the models and analogies you're using and ask yourself these questions:
Do the comparisons make sense?
If you're talking about email, comparing it to a postcard makes sense for various reasons: it's cheap to send, it's essentially public for everyone to read, and there's little to no guarantee that it will get there in a timely manner.
Do they add anything to the conversation?
If you have a library which simply wraps a different library to give it a standard interface, don't call it a "wrapper". That doesn't mean anything and doesn't add anything. Call it the proper name - an Adapter - and compare it to a US to European electrical outlet adapter.
Where do they fail? and Why do they fail?
Software development is regularly compared to constructing buildings, tending crops, waterfalls, and a variety of other things. When you're working with non-physical pieces that can be manipulated at will and have a near-zero transportation cost, these models only work so far.
Can you use other comparisons to describe those areas?
To describe software development, none of the above descriptions capture it completely, but some capture different aspects. Constructing a building gets to the concept of building frameworks and fleshing out the application. Sculpting a statue gets to the concept of removing unneccessary pieces and simplicity. Evolutionary concepts get to the idea of "survival of the fittest". None of them perfect, all of them useful.
Thanks for reading and Happy New Year.
Post new comment