-
Get a monthly update on best practices for delivering successful software.
Who values your product and do you value them?
We have reached the most critical point on a project I'm working on. After a few months we think we know enough about the domain and application to build a product road map that will take us to the first public release. The proof of concept is complete. The design team has created a remarkable, genera changing product. Additionally, the system is designed around real users we have been able to talk to and get feedback from. We have put together an unbelievably good development team and built a backlog of stories with estimates. We have been here before. Putting together a design and backlog of stories is something we have done countless times...
The easy part is over. Now the hard part begins.
Our research and user feedback tells us we have multiple potentialcustomer groups we can build the system for. On one hand this is great news. We have a number of potential markets to choose from. On the other, we don't have an infinite amount of time and money to build it for all of these groups. We have to commit and go all in with one group. Right now, these are just some of the questions we are asking ourselves now:
- What customer group do we value the most?
- What features do they value the most?
- How expensive is it to build the ultimate product for each group?
- What is the minimum viable product we can build for each group?
- Which group is most likely to give feedback and partner with us to help refine our product?
- How much feedback is this group likely to give you?
- Are we missing some market window by passing on one group v.s. another?
This is a critical point in the product's design. Whichever user group we choose will be our customers. Or another way of saying it: They will be our ONLY customers. Other customer groups aren't likely to be interested because we aren't building any features for them yet.
When designing a product do you consider what customer groups you are including and excluding? Are you going to be happy with that choice for the foreseeable future?
What’s the value of Agile out of the box?
I often meet peers who ask what Agile practices Pathfinder utilizes. From the outside we pretty much use all of XP’s practices. However, if you take a deeper look we do some things a little differently (especially how to use and calculate velocity). For Agile purists, one might question if we are really doing Agile. They would claim changing practices is slippery slope. For example, a team will start altering Agile practices to create a “home grown” version only to find they are using only some practices and not seeing the benefits they hoped for. I feel questioning if we are really doing Agile based on exactly what practices one uses shows how familiar and mature one is with Agile principals. A better question would be to ask why we changed them. Agile is not meant to be a methodology, but a set of principals. In my opinion, using things like Velocity to estimate whether a team will finish a project within a certain time frame is a hack at best. This always was hard to explain to customers. While I was reading Leading Lean Software Development I discovered something that helps. The Poppendieck’s point out that the engineering practices of Agile (TDD, collective code ownership, etc…) are solid and not likely to change. But, the project management practices implement a system on top of another system - a hack.
Once you have sufficient experience managing projects with Agile practices you should feel comfortable adapting those practices to your own teams and projects. As long as you are still following Agile principals this is okay. In general, this is what’s going on in smaller companies. Having coached a number of large organizations transitioning to Agile I can say this isn’t how they look at things. The problems start when you adapt the practices, but try to deliver all projects in an identical manner. This makes sense for waterfall-like delivery methods. But, when an organization comes up with its own version of “Agile” it can only work for the subset of projects it is tested on. Rolling this out to the entire organization as “the way” to deliver projects from them on is a failure pattern. The principals are lost and so is the adaptability of the organization. The time spent to move over to agile is immediately wasted.
Photo Credit:
kevindooley
under a Creative Commons Attribution License
Review: Leading Lean Software Development
In Leading Lean Software Development, Mary and Tom Poppendieck present a handbook for how to run a software development group, top to bottom. I intended for this to be a simple review of concepts known to me for years, but the book offered much more. The book’s jacket describes it better than I can: They “show software leaders and team members exactly how to drive high-value change throughout a software organization—and make it stick.” If you are completely new to agile and lean you the book might move a little fast for you. If this is the case, I suggest you spend some quick time getting agile and lean 101 elsewhere first.
If you walk away with one concept after reading this book it should be to believe that success comes from people. The best companies focus on developing problem solving skills and local decision making. These companies favor adaptability over efficiency. These companies make money to survive rather than simply surviving to make money.
The book starts out by defining the concept of frames, “the unspoken mental constructs that shape our perspectives and control our behavior in ways we rarely notice.” A useful way to look at software development. I was happy to see their description of Agile as evolutionary rather than revolutionary. This is why when you explain the set of Agile practices to those with extensive experience they usually nod their heads and say they are already doing them. I have been telling people that Agile is a collection of best practices that good software shops have been using for years. Now I have a reference to support this.
Software craftsmen should read chapter 2 about technical excellence. The chapter goes through each engineering practices, explains it such that a non-practitioner can understand and gives examples. After they are done they should make their manager’s read it, then their managers.
Conclusion
I wish this book had been written 5 years ago. It would have saved me considerable effort and time trying to define what a well run software organization looks like. Your mileage my vary, but I will say that I intend to keep this on my bookshelf right next to Managing The Professional Service Firm.
Topics: agile, Agile Development, Best Practices
Your SDLC or Your Product – You Decide
…or the telephone game
Last weekend I was watching a movie with my kids. In the movie there was a chain of monkeys that needed to pass on the message from one character to one on the other side of the chain. The message went something like, “Don’t throw us over the wall. There must be another way. We will all be killed.” As it went through the chain and the receiver heard, “Throw us over the wall. It’s the only way. Banana.” The scenario seems ridiculous, but its roughly equivalent to how many companies approach software product design. Often times companies don’t realize they are creating a product at all. They think they are just running a project and focus only on delivery of that project as if it is the only artifact of their work.
The problem stems from the fact that when organizations reach a sufficiently large size they must focus on consistency of delivery and efficiently using people’s time. For large organizations this is part of the mix that makes up their competitive advantage. However, the sheer size and number of moving parts required to enable clocklike consistent delivery leads to the most knowledgeable people about the customer never directly speak to the people responsible for building the product. Or translated into a traditional SDLC, the definition/high level design team isn’t communicating with the build team. In my experience they are usually two different groups of people. I’ll give you an example:
A while back, I was leading a software development team creating a product to be used by all 170,000 of my customer’s employees on a daily basis. They happened to have a team of user experience designers and wanted to take on the “big picture” part of the design themselves. This company could afford the best and the brightest talent - and was able to attract them. Individually the folks on this team were talented and knew their craft well. I actually learned a lot just from my brief time with them. However, once we got the design in hand it was obvious that the usability team’s artifacts weren’t going to work for the project. They didn’t meet the end user’s needs nor were they implementable within the time we had available for the project. The client’s design team literately spent months of time showing users lo-fi prototypes, running focus groups, and understanding usage statistics from similar applications. But, the simplicity the end users craved didn’t match the complexity of the business rules required. Upon further investigation the customer’s design team never was given a business level view of the problem to be solved. We tried to merge the business requirements with good usability, but ultimately the franken-design didn’t work. We had to throw out the big picture design and use them as ”guidelines” instead. Clearly it was a waste of talent and a haphazard way to build a product.
In hindsight the design team should have been presented the complex business rules so that their design could incorporate them from the beginning. However, the customer’s SDLC only allowed the design team to be engaged in the definition/high design phase of the project. Once we got to the design phase they were hard to find. By the time we got into the build phase the development team was simply a distraction from other work for these designers. A better model would have kept the designers on the project as each piece is built. I’m not suggesting full dedication to the team – 40 hours a week. That would be nice, but that’s not likely possible in most organizations. I’m suggesting a small time commitment over a long period of time.
Most of the time projects are actually building products. If you are building a product, but focusing SDLC metrics and efficiency, keep in mind that your phases are likely making walls around teams and causing ineffective communication between them. As Matt from 37Signals points out, “Inefficiencies are what make you special.”
Getting a team over the fear of daily scrums
If my previous post about the value of agile meetings over traditional status meetings got you interested, I want to share a common pattern of behavior I often see from teams trying scrums for the first time. Hopefully you can avoid these and save yourself some time.
For new teams to Agile the statuses given in scrums are generally … well … lies. “Yep, on time. No obstacles.” I was once told by a colleague that, “You can’t hide on an Agile team.” This is true. However, this kind of exposure can be extremely uncomfortable for individuals to get used to. In traditional software teams people aren’t used to their peers asking them direct questions and paying close attention to their progress.
Continue reading »
Wireframing with incomplete requirements
The value of wireframing even with incomplete information
The task of wireframing in application development, as I've come to know it, should begin after user research has been performed, and a complete set of requirements gathered. But what happens when, for whatever reason, you just don't have access to user research, or a full set of requirements? What if all you have are some rather unspecific, vague notions of what the user should and should not be able to do? Is wireframing at this juncture useful? I say yes. With incomplete or even almost non existent information about target users and or requirements, wireframes can still be a valuable tool in the interface designers toolkit.
The key to a wireframe's usefulness is that it is a visual document. Presumably it will be presented to one or more product stakeholders, and they will have the opportunity to review it and comment. Having something visual to respond to is one of the easiest ways to generate ideas, and identify incomplete specifications. A good assumption is that if a product's requirements are incomplete, someone at the wireframe review will notice the gap by responding in the context of the visual presentation. "Where is the Cancel button? Oh...not in the requirements? Well it's obvious that on this screen the user will need to be able to cancel, so we have to add that as a requirement."
In this way, a wireframe can be an ever evolving document, which begins by starting the requirements conversation. Of course ultimately, just prior to feature development, the wireframe should have all of the necessary specifics so that the developers can use it as a guide (along with the relevant user stories).
Agile Development and Play: Understanding the Value
My Addiction
I'm addicted to TED talks. There have been many nights where I've stayed up way too late watching them. For those who are unaware, TED is a yearly conference where world leaders and thinkers gather to share their ideas and spread their passions and work. I'm someone who gets fired up listening to outher people's passions. I love hearing about what gets other people excited, what makes them tick, what makes them want to share with the world.
One of the more interesting talks I've listened to recently is by Tim Brown at the Serious Play conference of 2008. Tim talks about how the elements of play can improve creativity and productivity in our workplace and life. I found the lessons learned from this talk something that can be very directly applied to software development, and taking some of these nuggets of teaching can help me be a better thinker and worker.
Agile 2009: A reminder of why each team needs leadership
Last week I presented at Agile 2009 a workshop for those new to Agile entitled: The Agile Game: An Experiential Workshop. I love this workshop because it allows those new to Agile to experience the rhythm of an agile project in action and learn first hand many of the practices in a non-threatening, non-technical, and fun way. I have used this workshop for clients a number of times and it works. The feedback from this session was overwhelmingly positive too. Comments such as, “Fun game, good to demonstrate how teams do and don’t work together” and “Very, very, practical way to get concept through” are always great to see.
Recently I had been wondering if Project Management was a questionable career choice. I have spent the last couple of years surrounded by talented individuals who seemed to be able to work fine without me. The test is always when the project manager (me) goes on vacation. Has the team fallen apart? Are they forgetting all of the practices they were doing? Is stuff getting delivered to clients? I was finding that I had a backlog of chores when I came back, but overall things were still humming along.
Building a High Performance Agile Team: Assume You Will Be a One Hit Wonder
One thing about agile teams is that they constantly strive to get better. In my experience an Agile team takes 2-4 iterations to work through the forming stage. By iteration 10 or so the team is past forming and storming and is well into norming. At this stage the team is often moving fast enough or better than expected for the business’ needs. Now the team faces a dilemma: How to become a high performance team and why.
If you don’t keep improving and innovating your competitors will. However, there is another reason to keep improving that is often missed. The current success might be temporary or an anomaly.
Don’t fall into the trap of a one hit wonder.
Want to go viral?
This last weekend, my wife was sitting at the computer and laughing. I asked what was so funny, and she showed me a youtube video by Sons of Maxwell, a band from Halifax, Nova Scotia, called “United Breaks Guitars.” The song tells the story of how United Airlines broke the lead singer’s guitar, and the 12 month saga of trying to get reimbursement:
The video does not have a lot of production value, but its got humor, harmony, cheesy mustaches and sombreros. And it’s gotten over 2.6 million views over the last six days. Not bad for a band whose previous top video got about 25 thousand.
What does all of this have to do with software development?
Some of the same things that make the video a runaway success will help you in developing software that’s a runaway success:
- Solve your own problems. They’re their own target audience. They know the subject, what’s important, and what’s not. own subject. They know they’re not alone, so lots of other people have this problem. They’re passionate and that’s the best way to get others to feel passionate about it too. As it turns out, their problem is shared by millions, and their solution literally strikes a chord with millions.
- Be yourself. If they had been lawyers, they might have looked to start a class action lawsuit. But they’re a band that plays whimsical, fun country music, and so they made a song about it. They’re talented, not pretentious, and the song is catchy.
- What’s the big idea? It’s pretty simple - United breaks guitars, and they don’t care. The song has a simple vision, and it takes sides.
- Have an enemy. Pretty self explanatory in this case, but it’s equally applicable to software: “One bonus you get from having an enemy is a very clear marketing message. People are stoked by conflict. And they also understand a product by comparing it to others. With a chosen enemy, you're feeding people a story they want to hear. Not only will they understand your product better and faster, they'll take sides. And that's a sure-fire way to get attention and ignite passion.”*
- Essentials only. The video production qualities are low, the marketing budget was probably nil, but the song is funny, the tune is catchy, the harmonies are sweet, and the message is dead on.
None of this is a guarantee of success, but it sure helps.
Sounds a lot like Getting Real, doesn’t it?
* Have an Enemy, in Getting Real by 37 Signals.
Topics: Best Practices, viral marketing
We don’t have time for all of these meetings!
The majority of people who develop software utilizing agile practices find that they spend much less time in meetings than they did before they discovered Agile thinking. However, time and time again teams that I have coached hear about Scrums (stand-ups) and half-day iteration planning meetings quickly exclaim, “We don’t have time for all of those meetings. What’s wrong with our weekly status meeting?” Frankly, a lot.
This meeting phobia, in my experience, stems from the fact that people aren’t accustomed to using communication as a tool in order to solve problems, build good architecture, and complete work. Secondly, they likely scarred by meetings that meander and are longer than they are useful.
Continue reading »
Ten Keys to Successful Software Development: #10: Tools and Infrastructure
After last month's post on the five deadly sins of software development, I thought it would be good to write about how you can overcome those sins (present in every project) to successfully develop software. The list we use internally roughly parallels that of the Standish Chaos reports, and I've illustrated it with the patterns we use, as well as some antipatterns we've seen and experienced.
#10 on the list is Tools and Infrastructure:
Pattern: We use standard tools for our software development process. For example, every project uses a source code repository, we do continuous integration (hudson) and enforce test coverage as part of every build. Every project uses our wiki for in process definition and documentation. The tools have the benefit of being easy to use, of making communication between team members and clients easy and transparent. They have the benefit of enforcing/reinforcing what we consider important in our method (like test driven development, continuous integration, just in time specification and continuous feedback) and getting out of the way where too much structure is a hindrance.
The Five Deadly Sins of Software Development
There's a list of deadly sins out there for just about anything related to information technology. Some have seven items, some have five, some even have nine. I haven't seen one with 21 deadly sins yet, but I won't be surprised if I do. Some focus on IT departments, some on unused software, some on agile software development, and quite a few on whatever they're trying to sell you.
We've seen a lot in our ten years of developing software at Pathfinder, and the list that rings truest is the shortest and pithiest, from the Standish Group:
- Ambition
- Arrogance
- Ignorance
- Fraudulence
- Abstinence
Each of these is best illustrated by example:
Continue reading »
Tech Terms that Drive Business People Crazy
Most designers and developers today are familiar with the concept of Personas for describing the users of a system. In fact, you can use the same concept for how you talk to business people - the consumers of your services. Put yourself in their shoes, and your services will be better received.
One of the things that drives business people crazy when talking to tech people are the terms they use. Here are a few to avoid, and what might work instead:
800 on Your Math SAT, Software Development and Bugs
Why don't more people get a perfect score on the math portion of the SAT? I mean its dead simple -- just simple arithmetic. And there are plenty of bright young things that understand the problems cold.
I can understand stubbing your toe on the verbal; after all, there may be a word in the test that you just don't know or remember. But the math? There aren't more than a half dozen problems, and though the numbers may change, the concepts don't. So why don't more people get a perfect 800 on their math portion?
I ask this question every time someone asks me why there are bugs in software.
Topics: Agile Development, Best Practices
Launch: Pathfinder Newsletter
Subscribe via RSS
Categories
Topics
.NET
.NET Browser Control
.Net Development
2d cad
2d physics
3d
3D GPS
3d mapping
3D physics
37signals
Acceptance Tests
Accessibility
ActionMailer
actionscript
activerecord
acts_as_ferret
Add new tag
Adium
ADO.NET Entity Framework
Adobe
adobe acrobat
Adobe AIR
adobe flex
Adobe Illustrator
Advertising
aggregation
agile
Agile Development
agile iteration
agile thinking
AIR
Ajax
Ajax Applications
Ajax Bookmarking
Ajax Components
Ajax Development
Ajax Examples
Ajax Experience
Ajax Frameworks
Ajax history management
Ajax Intervention
Ajax libraries
Ajax library
AJAX Obfuscation
Ajax Performance
Ajax Products
Ajax toolkit
Ajax Tools
Ajax Widgets
A list apart
Amazon
Amazon CDN
Amazon Web Services
amf
Analysis
Android
animation
annotation
Announcement
Announcements
antennae
Antipatterns
Apache
Apollo
App Engine SDK
apple
apple tablet
Application Architecture
Application Development
ap store
architecture
art
AS3
ask a UI guy
ASP.NET
ASP.NET
assembla
asterisk
Asynchronous Processing
authorization
awards
axiis
Azure
Back Button
backups
bandwidth
bandwidth profiling
Barnes & Noble
Barriers to Entry
Beans
beer
Benchmarking
Best Practices
BitmapData.draw
BJAX
blackberry
Blaze Advisor
blender
blog
blogging
blog widgets
book review
Books
Borders
braindump
browser
Browsers
Bugs
Business
Business Concepts
Business Reasons for Ajax
Business Rules Engines
C#
c# documentation ndoc sandcastle
caching
campfire
Canvas
capistrano
career
Case Studies
CFO
change management
Charles
charting
checklist
chess
Chesspresso
Chicago
chicagoruby
chirb windycityrails
Chrome
Chrome OS
CI
CIO
Claude Shannon
Closure Tools
Cloud Computing
CloudFront
CMS
COBOL
Cocoa
code
code art
Code Generation
code generator
Code Style
Color
COMET
Competitive Strategy
Compilers
Compressor
Computer Science
Conference
Confluence
Consistency
Content Management
continuous integration
converget appliances
core animation
CRM
cruise
CruiseControl
CSS
cucumber
Custom Application Development
Custom Flex Component
dashboard
Data Mapper
data services integration
data visualization
date
datetime
Davlik
Degrafa
deployment
deprec
Design
design documentation
Design Patterns
design thinking
Desktop
desktop application development
Desktop RIA
Desktop Software
developer
Developer's Notebook
development
DHTML
Diagnose
Divide and Conquer
documentation
Dojo
Domain Knowledge
don norman
Drawing
Drools
drupal
dynamic languages
ease of use
EC2
Echo2
Echo3
Editorial
elections
enterprise iphone development
Entrepreneur
erb
ERP
error handling
Estimating
estimation
Ethnographic Research
events
everyblock
Evolution
Excel
externalinterface
Ext JS
Extreme Programming
eye tracking
Facebook
factory
failure
Fake Agile
Feedback Loop
ferret
FileReference
Firebug
Firefox
Firefox Extensions
fixed bid
fixture replacement
fixturereplacement
fixtures
Flare
Flash
Flash and Air
flash awards
Flash Catalyst
flash player
flash player 10
Flash Player optimization
Flash Remoting
Flex
Flex, Flash and Air
Flex3
flex 3
flex code generator
flex css
flex development
flexmock
Flex optimization
flex skins
flexunit
flex widgets
Flickr
Flock
Flow
Fluent
forms
Frameworks
FriendFeed
front end
front end development
fulltext search
functional
functional specs
Games
Gang of Four
Gauge Component
GDI+
gem
getting things done
ghost
GigaOm
GIS applications
Git
github
gitignore
Golf
Google
Google Analytics
Google Analytics for Flash
Google Analytics for Flex
google android
Google App Engine
Google calendar
Google Closure Tools
google docs
Google Gadgets
Google Gears
google maps
Google Web Toolkit
Google X Prize
GORM
government
g phone
Grails
Graphics
graphing
Greasemonkey
Griffon
Griffon Plugin Development
Groovy
GStreamer
GTD
Gwittir
GWT
GWT 2.0
GWT Layouts
GWT Rich Internet Apps
h.264
haml
hardware
Healthcare
heuristic evaluation
Hibernate
high-performance teams
hosting
HTML
Hudson
Hype
IBM
IDE
Ideation
IE
IE6
IE7
IE8
IE detection
iGoogle
Illustrator
illustrator cs3
ILog
ILOG JRules
imacros
importing graphics to flex
Information Architecture
information visualization
infrastructure
Innovation
Instructional Design
Interaction Design
interaction patterns design
Internship
Interview
iPad
ipad development
iPhone
iPhone Development
iphone framework
iPhone SDK
iPod
ipod touch
irb
iteration
IT M
IT Mill Toolkit
iTunes
jakob nielson
Java
javafx
Javascript
JavaScript frameworks
Javascript Libraries
Java Web Start
JBoss Rules
Jess
Jetty
JIT
jmeter
jnlp
job
Jobs
jQuery
JSF
JSON
JSP
JSR-94
JsUnit
JVM
JWS
Kanban
keynote
Kindle
kiosk
laptop
Lazlo
Lean
Legacy Systems
leopard
lightweight
LinkedIn
LINQ
LINUX
log4j
logging
Logical Model and Conceptual Model
Low Pro
Mac
Maintainability
Malware
Manufacturing
mapping
marketing
Marketplace
Mash Note
Mashups
math
measurement
Meebo
metal
metaprogramming
MetaWidget
Methodology
Microformats
microsite
Microsoft
midVentures25
migrations
minimalism
Mobile
mobile platform
Mocha
Mock
mocking
mock objects
modeling
mod_rails
monitoring
Mootools
mortgage calculation
mouse
mouse scroll
mouse wheel
Mozilla
Music
MVC
MySql
natural key
neal ford
Netbook
NetNewsWire
networking
NewNet
news
newspapers
new york times
nfjs
NHibernate
nokia
notebook
NSURLProtocol
obj-c
Object-Oriented
Objective-C
Object Relation Mapping (ORM)
ocmock
Office
Om Malik
OmniGraffle
online spreadsheets
OOAD
OOP
opengl
Open Screen
OpenSocial
Open Source
opensource
Opera
Oracle
OReilly
origami
ORM
os
osx
OS X
Packer
pagination
pairing
Pair Programming
palm
papervision3d
Pathfinder Development
Pathfinder Events
Pathfinder General
Patterns
pdf
pdf application development
Peer Creation
Performance
Personas
PGN
Photoshop
PHP
Phusion Passenger
physics
physics engines
planning
play at work
plugin
plugins
portableapps
pragmatic
prawn
Predictions
preloader
presentation
primary key
privacy
process Web/Tech
Product Definition
Product Design
production environments
Production Support
productive programer
productivity
product launch
product management
product manager
Product Strategy
Progressive Enhancement
project concept
Project Manage
project management
Project Website
Prototype
Prototyping
PureMVC
Pure MVC
purpose
purpose built devices
PV3D
pyro
QA
qooxdoo
Radiant CMS
rails
railscasts
rails controllers
rails development
Rails Environment Tests
rails gem
rails polymorphic
railsrx
rails testing
randori
Really Simple History
Refactor
refactoring
References
regex
regular expressions
reporting
Requirements
Requirements
Alice Toth
requirements definition
Requirements Visualization
resesign
Restlet
RETE
Review
rfp
ria
Rich Interactions
rich internet applicaiton
rich internet applications
risk management
Robert Fogel
ROI
rspec
ruby
rubyamf
Ruby on Rails
Ruby on Rails Internship
Ruby on Rails testing role
ruport
S3
SaaS
Safari
San Francisco
Scalability
Scenarios
Scriptaculous
Scrum
SDLC
Search
Secretariat
Security
Selenium
SeleniumIDE
Semantic web
SEO
Server Side
service oriented architecture
shoulda
Silverlight
simplicity
Sketch
skins
SOA
soapUI
Social Networking
Software
software arhcitecture
software design
software develoment
Software Development Best Practices
Software Engineering
Software Maintenance
Software Processes
software product strategy
Songbird
SpiderMonkey
Sprajax
Spreadsheets
Spring Framework
StageScaleMode
Standards
standish
starting projects
Startups
static typing
Stencils
Steve Jobs
STI
storytelling
Story Telling
strategy
Stress
Structured Design
Struts
Subclassing
sun
surrogate key
Susan Boyle
Swing
tablet
tabs
tag
taglib
Tamarin
Tank Engine
Task Flows
Task Switching
tdd
teams
teamwork
Technical Debt
telephony
Tellurium
Test
test::unit
Test Driven Development
Testing
tether
textmate
The Ajax Experience
throttling
Tilt Component
time
timezone
Tools
touch
touch screen
touch screen kiosk
TraceMonkey
Training
Trends
Tumblr
Tutorial
Tutorials
Twitter
ubuntu
UI
UIViewController
uml
unit testing
Unit Tests
unity3d
Upgrade
Usability
Usability Testing
user centric design
user driven agile
user experience design
User Experience Design
user groups
user interface
User Interface Standards
User Modeling
User Research
uxd
Vaadin
value
velocity
Venture Capital
Video
viral marketing
Vision
visual analytics
visual design
visual documentation
Visualization
VLC
VML
vmware
Volta
Waaler Surfaces
wapcaplet
waterfall
watij
watir
web
Web/Tech
Web 2.0
web app
Web Applications
Web Design
Web Development
web forms
web hosting
Web Infrastructure
Webkit
Weblogs
Web Services
WebSockets
Web Standards
WebTest
Widgets
will_paginate
Window Forms Development
Windows
windows development
windows mobile
WinForms
Wireframes
WordPress
workflow
work life balance
xcode
XML
XML Metadata
xp
XUL
Yahoo Map AS3 API
YUI
Zeigarnik
Zeigarnik Effect
ZendAMF
ZK
Archives
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
Blogroll
Recent
- Teamicide
- Who values your product and do you value them?
- Optimizing has_role? in acl9
- Pathfinder’s Mike Laurence wins Hack-a-thon for iPhone app
- Pathfinder sponsors the midVentures25
- Pathfinder sponsoring Day of Mobile in Chicago
- Refactoring versus Rewriting
- Storytelling in Design
- Remembered: Claude Shannon
- mort_calc gem: Rails Mortgage Calculation Gem