50 Axioms of Web Application Development

This is from my friend Cale Peeples. It's been passed around via email, so I decided to publish it. Looks like Cale did too. I've added to the list on the bottom. I didn't want to spoil Cale's prose.

1. If you choose your technology before your application you'll need to re-invent some wheels.
2. If you decide how your application will look before you decide  what it will do you're not building an application for users.
3. You need Personas, Workflows and Use-Cases.
4. Don't let your engineering team define the features.
5. Framework and Feature set can be different.
6. Hire a real project manager.
7. When real users can't be found, talk to Professional Services or Sales. Not marketing or Engineering.
8. Nobody thinks like users - except users.
9. Extra clicks aren't bad if the path is helpful.
10. Wizards are good once - make sure you build a tool that can use  them and turn them off.
11. People like MS Office, and it works.
12. Write proper contextual error messages.
13. Build multiple messaging systems.
14. Sometimes webapps need a training system.
15. AJAX won't save you.
16. AJAX won't scale.
17. Hire a proper DBA.
18. Fully addressable apps are better than not. (Multiple access points)
19. Make sure you have someone on your team that knows about session management.
20. Single Sign-on.
21. If your search is broken, fix that first. Then your filtering. Then your navigation.
22. Data grids are a pain in the ass. Everyone wants one and none of the pre-built ones are any good.
23. Nobody wants to Drag-and-fucking-Drop except for sales guys.
24. Spend as much time as you can with the team that is building you app - they will make it or break it
25. Group consensus will kill you and the project.
26. If anyone tells you they need an icon for something and they can't tell you what that something is - punch them in the eye.
27. Feature creep will happen - this is why you need to have a good relationship with the people building your app. (see #24)
28. Don't ignore your Log-in page, error pages, 404's or anything else.
29. If your app takes more then 2 seconds to do something and you can't make it faster, you need to add a status message, bar, throbber etc.
30. Separate From from Function in the beginning and you can work on them in parallel the whole time.
31. Keyboard controls are sweet as.
32. Users will want to print complex pages - let them and provide them with the right tools to do so. (I like pdfs)
33. If you're going to let your users customize you app, you have to provide support to them.
34. Inline help is awesome, but if you can't support it fully you're better off not having it.
35. Images will need to be localized - make sure your designers have done this before. You do not want to make a "submit" button for every language.
36. German has some very very long words and will ruin your carefully constructed layout.
37. Vertical scrolling isn't bad - Horizontal scrolling looks like a mistake. Always.
38. Your app should use the same language and abbreviations as your users.
39. Business logic doesn't always make sense, but it's what your users are accustomed too.
40. Don't put the "United States" at the bottom of the damn drop down list just to keep it in alphabetical order if 95% of your users will select it.
41. Auto format my telephone numbers, dates and zip/province codes for me. I don't care what the database looks like.
42. Metadata.
43. Prototype everything you can every-time you can.
44. Internal surveys will tell you nothing.
45. Jacob Nielsen and the "Tog" are tools but they are occasionally correct. Although frankly, they've done more harm than good.
46. The Five Hat Racks will save your ass. (Category, Time, Location, Alphabet and Continuum)
47. If you can't draw it on the whiteboard then write it down. If you can't do either you're a manager not a do-er.
48. You need to have a multiple phase and release plan.
49. Testing in the real world is time consuming, expensive and frustrating, but ignore it at your own risk. If you're committed to doing it, hire a professional.
50. Agile development is cool but it runs the risk of becoming too focused too fast and losing sight of the larger picture.
51. Don't read lists. Write your own.

Here are my additions...

1. Focus on one thing; the right thing, then kick that one thing's ass
2. Design for the worst case scenario. This means do everything possible to break the design, then design around that.
3. Bucket tests are great when you're trying to improve a feature, but for gods sake, know what you're trying to get out of it
4. Take risks
5. When in doubt, WWFD (What Would Flickr Do?) except when it comes to drop down navigation
6. Usabilty tests can scare the shit out of you, do them early and often
7. Test it on anyone you can find... even one person is better than nothing
8. Not every bug is a P1
9. User experience first, monetization second
10. Work with as small a team as you can possibly get away with
11. Don't sleep under your desk, nothing is worth not having a life