user experience
I've long believed that the design of your software has a profound impact on how users behave within your software. But there are two sides to this story: * Encouraging the "right" things by making those things intentionally easy to do. * Discouraging the "wrong" things
user experience
When it comes to user interface design, I'm no guru, but I do have one golden rule that I always try to follow: Make the right thing easy to do and the wrong thing awkward to do. The things you want users to do should be straightforward and
software development
Every software project I've ever worked on has accrued technical debt [http://martinfowler.com/bliki/TechnicalDebt.html] over time: > Technical Debt is a wonderful metaphor developed by Ward Cunningham [http://www.c2.com/cgi/wiki?TechnicalDebt] to help us think about this problem. In this metaphor, doing
design patterns
The introduction to Head First Design Patterns exhorts us not to reinvent the wheel: You're not alone. At any given moment, somewhere in the world someone struggles with the same software design problems you have. You know you don't want to reinvent the wheel (or worse,
software development
Some developers love to gold plate their software. There are various shades of .. er, gold, I guess, but it's usually considered wasteful to fritter away time gold plating old code in the face of new features that need to be implemented, or old bugs that could be squashed.
software development
This classic Eric Lippert post [http://blogs.msdn.com/ericlippert/archive/2003/10/28/53298.aspx] describes, in excruciating, painful detail, exactly how much work it takes to add a single ChangeLightBulbWindowHandleEx function to a codebase at Microsoft: > One dev to spend five minutes implementing ChangeLightBulbWindowHandleEx.One program manager
software development
Mark Minasi is mad as hell, and he's not going to take it any more. In his online book The Software Conspiracy, he examines in great detail the paradox I struggled with yesterday-- new features are used to sell software, but they're also the primary reason
programming concepts
Reginald Braithwaite's favorite interview question is an offbeat one: sketch out a software design to referee the game Monopoly.* I think it's a valid design exercise which neatly skirts the puzzle question trap. But more importantly, it's fun. Interviews are a terror for the
interview questions
Here's a not-so-gentle reminder from David Pickett that some programming interview questions [http://blogs.msdn.com/davidlem/archive/2006/05/16/598696.aspx] – in this case, "how would you write a routine to copy a file?" – are, well, stupid [http://exold.com/article/stupid-interview-questions]*: > Q.
usability
I'm currently re-reading the book About Face. I hadn't revisited this book since I bought the original version way back in 1995. The update, which was published in 2003, is a significant overhaul – and frankly much better than the original. Adding the second author, Robert Reimann,
ui/ux design
Ever wonder how you could possibly find something in that complex, ten-tabbed options dialog? How about a search function on the options dialog, as featured in Quest's Toad for SQL Server [http://www.quest.com/toad_for_sql_server/index.asp]: Aside from the fact that it'
software development concepts
I'm beginning to wonder if the book Head First Design Patterns would be better titled Ass Backwards Design Patterns. Here are some quotes from pages 594 and 595 of this 629 page book: First of all, when you design, solve things in the simplest way possible. Your goal