Originally Published 2007-09-05 20:00:43
I've recently stepped up my software development duties for clients, as you may or may not have gleamed from my posting infrequency and slightly geekier posts of late.
I've also been exploring the technical requirements for a bigger project while getting tapped on the virtual shoulder on a regular basis with web development questions. This led to the articulation of something that, as a software and support guy, comes as second nature, but seems to escape so many whom I speak to.
Your Web Site is a Software Application.
That means that the rules of software development apply. It means that where it makes sense to apply processes associated with software manufacturing, you should wholeheartedly do so. And it means that if all you've ever done is blog about how poor you are, you probably ought to change your mindset before going out and trying to do much with web-based businesses other than blogging.
If you're using the web to extend your offline business, you don't need to think about software. It's perfectly ok to use a word processor to place a virtual business card on the web and place the URL on your business card. If you're a writer, then use tools like blogger and wordpress. If you're a broker of used goods, then yes, craigslist and ebay are web tools you should be using. If you need to do something more complicated that increases the value of your business through custom software, that's easy! Hire me.
All of this being said, if you want to ignore my rant and forge ahead anyway, here are some basics you need to know about software development.
- You need to think about your business before even considering your application. Software people -- usually with a title like "Product Manager" -- call this a Roadmap. The application you want to develop is serving a purpose, right? Well, like any investment, the costs associated with the application need to be weighed against the reward, both potential (optimistic) and likely (realistic). Is there a better place you should be spending your time and money? More importantly, are you interested in a given feature, application, or business simply because you've fallen in love with the idea? Don't do it. The three shower rule applies.
- You need to document your functional requirements before you start writing code. If you happen to be doing the development, then maybe you can take some of shortcuts here, but that amounts to shorthand notation, not skipping this step. For instance, consider a user management application. You know, those things you use every day when you need to login to something. Great, so you need some place to store the user and password, you need a form that accepts these inputs, and you need a way of providing feedback like "Sorry, bad password, stop trying to hack into your boyfriend's account." Anything else? No? How about security concerns? How do you reset a password? How do you register a new user? What about when a user name is already taken? What about password requirements, like length or a rule against using dictionary words? The point is this: until you start making a list (at least... what we software guys call "use cases" would be even better), you'll forget lots of stuff that needs to be in there. Make your list first, and you won't find yourself rewriting code you should have constructed properly the first time. Or worse, paying your $100 an hour IT guy to do it twice. Oh, and yes, there's an acronym for this one: "FRD".
- You need to capture your technical details. Just as I've described above with your features, making a list of your technical decisions -- both in terms of architecture (e.g, the server operating system, the development tools used, how data is stored/cached/handled) and your details, like the type of data you need to maintain in your database, will save you a great deal of heartache later. On bigger projects, both your FRD (functional requirements document) and TRD (technical requirements document) go through several iterations before any development begins. (Aside from, perhaps, some user interface design for inclusion any these documents, which happens often with web applications, because a skilled developer can do web UI mock-ups faster than a designer can create mock-ups in Photoshop.)
- You need a guide, young padawan. It doesn't have to be me. I'm admittedly pretty expensive. That being said, I'll happily answer simple questions from any reader and would be delighted to critique your business plan off-the-cuff. If you want a formal evaluation or some actual development work, of course, the first thing I'll ask for is if you've been through the first three points above. :-)
On 2007-09-06 19:20:36 Thomas (Browder) said:
Look for an email in the next few weeks, im going to connect you to Kenneth D. for a wall to bounce ideas off of.
On 2007-09-09 12:20:16 Abbotsford Real Estate said:
Yea, that's right. Web skills are very imp now a days for Realtors.
On 2008-03-25 05:33:12 Mandar said:
Yes indeed all software development rules are applicable to website development as well. One need to be thoughtful when it comes to website development. Your website should be capable of handling future changes and it should tell users in the first go as what it is all about. This is more in web 2.0.