Postings On Web Development
-
posted 26 days ago by graemenelson
I just signed up for Portland Startup Weekend, which will be taking place May 23-25.
If you are interested, I would recommend signing up soon. The event is likely to sell out.
This should be an excellent chance to meet others who are interested in software development and entrepreneurship.
-
posted 2 months ago by graemenelson
In my previous article, staying focus on the main goal of the site is paramount. It keeps the site cohesive and development on track. So how do you determine the goal of the main site? Well, you might not know exactly. You might have an idea of what you want the site to do, but we don’t have it nailed down. This is where feedback comes.
In some of my previous web development jobs, months were spent developing a requirement document that outlined what the site was suppose to do. Then another several months were spent developing the site based on the specification. This hardly ever worked. The main reason being is that the user of the site was never given a chance to provide their feedback. Instead, you had several folks from management to developers making assumptions about the user. There’s nothing wrong with making some initial assumptions about the users of a site. However, you want to get something out in front of the user as soon as possible to determine if those assumptions are correct.
Once you get feedback from the user, you can turn around and make those necessary changes to the site and get it back out in front of the users again. This process, known as an iterative process or release early release often, should continue for the duration of the project.
Another good read on this subject is The Hardest Lessons for Startups To Learn by Paul Graham.
-
posted 2 months ago by graemenelson
Over the course of my web development career, I’ve had the opportunity to work in many environments from major corporations to small businesses. What I have learned over the years, is that developing websites based on a list of features doesn’t work.
There are a few problems with developing based on a list of features:
- Features creep in when releases slip off schedule.
- Features usually come from site stakeholders and not users.
- The site becomes unmanageable.
The problem with developing based on a list of features for a particular release, is that eventually a release gets off schedule. Depending on how far the release slips off schedule, features for the next release may creep in due to business needs. I’ve seen a two week release schedule slip for six months, all the while more and more features are getting added. How would that ever work?
Which features get added are usually based on business priorities and not user priorities. I don’t know how many times I heard the phrase, “we need feature x, because our competition has feature x.” Little thought was given to why the competition has feature x and whether it would be something that would benefit their users.
Features tend to get added but never removed. This causes the site to loose it’s cohesiveness. What once was a manageable site, has now ballooned into a mess of features. Which usually leads to someone saying, “the site is unmanageable, and we need a complete rewrite.”
A website should have the user’s primary goal in mind, when new features are being considered. New features should only be approved if they help the user complete their goal.
A good read on this subject is Getting Real by 37signals.