This post comes courtesy of the bureau of patently obvious.

Lots of software projects I’ve worked on didn’t live up to the end-user’s expectations. Sadly, it’s all part of the job. Perhaps it a bigger part than it should be.

The most successful projects I’ve worked on were those where I actually visited an end-user, and said “hey, I can make that easier for you!” There have been cases where this involved flying across the country to actually watch someone using the software with my own two eyes. I wasn’t privy to the financial expense of these trips, but from a customer satisfaction perspective, it seemed well worth it.

The alternative is to have some sort of analyst sit down with a programmer, and that person creates a pile of documents that are dumped on a programmer’s desk.

Abstraction is a wonderful tool for coding. You’ve probably heard the old programming adage “there’s no problem that can’t be solved with another layer of abstraction!” But it doesn’t work when you introduce people into the equation.

Lots of fancy new software development processes have been invented to try to revolutionize software engineering, attempting to marginalize the venerable waterfall model. But in the end, it doesn’t take a cool, aggressively marketed name. You don’t need a cadre of consultants hocking books and services to convert you to the latest methodology. All you need is to get the programmers out of their cubicles, and sit them down with their own users once in a while.

This entry was posted on Wednesday, January 30th, 2008 at 2:17 pm and is filed under programming. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.