Posted by jon on May 28, 2008
One thing that is widely known already, but deserves to be restated for everyone that thinks they understand it is that the quick and dirty, seemingly meaningless decisions that you make when you first start designing/building a website are going to be greatly magnified throughout the life of the company. I run into little things constantly that I wish I’d just thought through a bit more carefully in our early stages that would’ve been a quick fix originally that are now an annoying problem to resolve because it’s grown overtime.
I think there is a delicate balance, especially in the earliest stages of an application, between speed and just getting something out the door (there definitely is such a thing as over-analyzing a problem) and thinking the problem through and looking at the long term perspective to prevent a series of “gotchas” in the future. I certainly still haven’t mastered this balance, but what I am learning is a couple of (now obvious) clues as to what should be more thoroughly thought out and what should just be cranked out and refined as time goes on. So what are the clues?
- Anything involving the database should be thought out very carefully…and then thought out again. Changing the database schema after you’ve grown a bit is certainly possible, but is a nightmare of a thing to do. The application often ties so tightly to the database architecture that even relatively minor changes can be a major pain to implement down the line.
- Core processes (anything done many, many times on your site) should get a bit of extra foresight as well. Anything that happens constantly will generate large amounts of data which is always hard to fix in the future. Also, if it’s not well thought out you’ll probably run into scaling issues and the like down the line – a little time spent early on can save you from a nasty bottleneck 6 months later.
- Data collection and standardization definitely should get some extra cycles. Exactly how you store url’s (to normalize for inconsistencies) for example is something that is much easier to solve once, carefully, than to have to modify several times to ensure accuracy down the line. Any time you end up collecting large quantities of data, you want to be 110% sure you figure out the way you want to store it (including what it will be down the line). Having to modify large collections of data multiple times is murder on your server and extremely risky (playing with data always is). Save yourself the stress and figure this out from the get go.
- In contrast, the UI of the site is something that should be cranked out relatively quickly. I’m sure some will disagree with me on this point, but what I’ve found over and over again is that what we think is the best way is never really the best way. The UI is something that should be constantly tweaked and iterated over to give the user the best experience possible. It’s very, very hard to plan out the best possible UI on day one, but your users will help you figure this out along the way. Let them, and don’t waste all your time on this up front since you’re just going to change it every 1-3 months anyways.
- Formatting and copy (text) of the site/product should be done extremely quickly early on. Obviously you want to make your product usable from the beginning, and appropriate, understandable text is important to that, but this is so frighteningly easy to change that it’s just not worth all your focus up front. Instead, make sure it’s clear enough that it’s usable and then build off of the feedback of your user base a couple months in to clean it up and refine it.
So a quick summary would be that anything involving data, the database, or a core process should be handled with great care, but things like copy text and UI should be handled more iteratively instead. When phrased like this it seems completely obvious, right? Yet somehow in the moment it just doesn’t seem this cut and dry. Hopefully this will help someone else out there to make sure they spend their time on the right early decisions and prevent some headaches down the line.
Posted by jon on May 20, 2008
Just a quick mod_rewrite tip for everyone out there. I spent a little time today working on some rewrite rules for an upcoming feature on IntenseDebate. I didn’t realize before today, however, that query parameters are not part of the expression matching in mod_rewrite. That is, http://www.domain.com/url/param1/param2?abc=123, will stop matching after param2 in this case. When you think about it, this makes a lot of sense really…unfortunately I didn’t realize this until I spent a good 30-45 minutes in frustration wondering what was wrong with my regular expression. If you do want to do something with the query parameters you can access them by using the variable %{QUERY_STRING} in your script.
Hopefully this helps someone else out there.