Monday, March 27, 2006

Is Web 2.0 At A "Tipping Point"?

For now, this is just a link to an interesting piece:
Web 2.0 At A Tipping Point

tags: AJAX, Web 2.0, hype

Sunday, March 26, 2006

AJAX Patterns And Best Practices

I just wanted to let you know that my review for "AJAX Patterns And Best Practices" has been posted at You can use the following URL to see the review: .

Sunday, March 05, 2006

Hamburger Helper for IT

Project (pro-jekt) noun: A task that has a limited time frame to delivery and too little time or money to guarantee delivery.
Web projects are chronically under-resourced: too little time, too few people, too little cash, too many requirements-- sometimes all of the above. You don't have enough resources but you still need to cross the finish line with one or more projects. How can you extend your resources? Let me put on my David Letterman wig and count Top Ten ways to extend your IT resources:

1. Open Source: Open Source software (OSS) is not neccessarily free, but much of it is. There are plenty of places to scour for OSS applications and code:, Codewalkers, HotScripts. Some (read much) of OSS is not business ready: OSS is often coded by people with all of the personality and inter-human relationships of salamanders.
2. Release Your Stuff as Open Source: If you have slaved away on an application, release it as Open Source. Build the application to be modular. Release all of the documentation you can. Encourage others to contribute new modules and bug fixes. By letting the software out, you can use the OSS community to mature the software with just the odd paddle from your developers. If you are low on time, make that well known on your downloads page: mediocre support will harm its business readiness, but if you had enough time, you wouldn't need this approach as a resource extension tactic.
3. Creative Common: Clients I have had in the past are willing to ante up for coding but choke when it comes to the content: text and graphics. In a mirror to the Open Source movement, the Creative Commons Licensing terms have emerged. All forms of creative content is issued under these terms. The terms are not fixed. They range from very loose (e.g. take it!-- take it!) to very tight (e.g. you won't have the RIAA knocking down your door, but you can't have the content you see). Inside of that large range is material you get and use for your site. It's likely that the text has to come from the client in some fashion, so this isn't the big win there. But applications like Flickr and Krazy Dad's Color Picker are hugely important tools that problem to be Corbis killers. While you could pay Corbis hundreds of dollars (and thereby put some pennies in Corbis' owner's pockets (Microsoft)), you can download real images from real people for free. Give them attribution on a credits page. On a graphics intensive site where your client didn't give you a graphic budget, this is an ideal way to extend your budget.
4. Schools: A lot of schools (colleges, high schools, IT colleges, etc.) have IT students itching to do real work. If you've gone into a school setting you know what I'm talking about: anti-septic, theoretical projects that take dozens of hours to complete. Then the project is graded and tossed. Students who work on real projects get the chance to a) encounter real world problems; b) do work they can later reference. Students will need more handholding than staff. In other words, you cannot put the fear of God into them (ie. fire them), you can only fail them. Students may also get the project them go and play hackey-sack for six weeks (I have seen it happen firsthand). Locally, Camosun College offers a Capstone project: IT projects carried out by senior students. For the cost of a registration fee (e.g. $200) you can have a team of two to five students put 10-20 hrs./week/student into a four month project. For $200 you can get 700 hrs.+ of IT development (Beat that, Indian IT outsourcers!). This is ideal for important projects you wouldn't do on your own, that-- if they failed-- won't torpedo your business.
5. Planning: Go back to 1990 and talk to software developers. Tell them that they can produce an application and then distribute it to users. Then users can come back with revisions. Some of the users won't be able to run the application, but they still try and want your application to change to match their server. Some the applications like this will cost money to procure. Many won't. Oh, and you have to leave a machine turned on or none of the users will get to use this software. Software development for the web is like assembling and painting a car while in motion. Planning is key in software development and doubly so in web development. Just because you can change the software after it's been released doesn't mean you should. Apply the measure twice, cut once approach to web development.
6. Lean, Mean Code: In a recent exercise, I looked at a standing design where the page consisted of 145KB of material in HTML and graphics. Through the use of CSS, I was able to drop that to 45KB. That tripled load speed (great for the users), but extended across the site, this could cut your bandiwdth bills. If you have so many dollars available, making a big savings on bandwidth could open up dollars for other parts of your operation.
7. Enter Contests: This may sound a little stupid (that's what I do best). When you want to accomplish a coding goal, there may be a contest out there for you. Last year, Amazon and Microsoft hosted a contest for those who wanted to tie the Microsoft platform into Amazon web services. What if your intended application ran parallel to a contest category? By making code that could serve two purposes, you could take a bath on the development costs of your project and roll the dice that the codebase could be adapted into a contest winner.
8. Co-branding: Use someone else's content. There are sites out there that offer up their content for your site. There are tools that can output their content on your site. (e.g. using TopXML). Even though they own the content and they likely slip in a plug for themselves, you give the eyeballs something for your site.
9. Host Your Material Offsite: Between above named sources like Flickr,,, Blogger and many others, you could hand your processing and bandwidth bills to a third party. You will have to live under their terms and conditions, but that may be alright. In addition to spreading the risk, these sites have promotional tools to promote the content on their sites. That could push users back to your site: a nice bonus for saving some cash.
10. Tailor Operating Systems and Languages: At first, this was two categories: "More Operating Systems" and "Fewer Operating Systems." If your sysadmins are strong in server deployment, comfortable in Linux and Microsoft but weak on application development: deploy a Windows and a Linux box. Then install platform specific applications as they are required. By having both operating systems, you can run almost everything available. Look at the opposite situation: your Perl guru has to white knuckle it through server upgrades and can't spell "Microsoft." If you don't have the skillsets, you need to wind back the variety and focus on a match of skills to products. If you don't, a little understood application will bite you at the worst of times.

tags: IT, budgets, open source, resource extension

Saturday, March 04, 2006

Web Cost Estimation

In almost every web development job, I have hit a point where someone asks: "How can we estimate project delivery times?" This brings forth two questions: How do you estimate project delivery? And, how is it that all of these places can't estimate this by themselves already?
Truth is: a development team can survive a good many years before the lack of estimation accuracy brings about a crisis. I have exploited the rule of thumb as have most developers. The downside: it means you have to do the estimation and rather than use a vetted third party means of estimation with a reasonable degree of accuracy. What if you don't have a rule of thumb? What if you're a project manager or someone looking to commission software from a developer?
I did some digging after picking up a book on project analysis. The cornerstone of the concept was "Function Point Analysis" and process called, COCOMO. Definable aspects of an application form up as function points: SQL code, functions in the application, output, buttons-- the works. By adding up these function points and factoring development experience and team size, one can come to an estimation for development time. Great! Unfortunately, the process of estimation is difficult. Add in the fact that web projects are chronically underfunded and sped through: function point analysis is prohibitive. Many of these use SLOC (simple lines of code). That's like knowing development time by looking back from completion. Planning and charting the development can yield function points and that can convert into a base SLOC figure. I thought: "Someone must have tried to make a web friendly tool for function point analysis." Someone has: Donald J. Reifer. I found an article of his from the Nov/Dec 2000 issue of IEEE Software entitled, "Web Development: Estimating Quick-to-Market Software" I gave it a read. It was a little vague: high on numbers, low on easy to apply formulae. I am sounding critical, but estimation has to be a footnote in the development process-- like the fuel in the rockets for the Apollo program-- critical but not the focus of the project. Reifer updated his article in 2002:
I did a little more digging and found that there is a Cocomo Suite for software estimation:
In addition, I found an online tool for estimation (you will want to read up on the Cocomo process before proceeding with use of the tool):

When time allows: I plan of doing up the function point numbers for a string of simple project elements: function building, login script, shopping carts, catalogs, discussion forums. Stay tuned!