Technical Web 2.0 Startup Basics and Software Quality Improvements

A lot of people have great ideas for new web -platforms/-software but simply lack the knowledge about an engineering approach to software development. This article addresses those companies/startups (seen as software buyers->customers), as well as software developers. So please don´t get confused when i´m trying to bring examples for both of those groups.

When you start a software project, you need to ensure your services are better in comparison to others. From a startup/customer point of view this can be a new web 2.0 niche, a nice interface or a new community. As a developer making an offer, what counts first is a faster time to market or just simply being cheaper.

Such arguments might be eligible, but they can crumble and stab your project to death, if the underlying software/development basis is not following strong conventions. Such conventions ensure two mostly overlooked arguments: „Softwarequality and Development Workflows

But what does that mean? The non-technical customer just uses a nice frontend and does not have a clue why he should pay more attention to those technical related questions. Well in the first place this might be right, but in the long run (and successful projects run long) each of the following is indispensable.

I´ve seen a couple of unsuccessful projects so far. On some i lost the pitch because of my pricing, on others i was just a spectator. What they mostly had in common, was their lack of software engineering basics. Please don´t misunderstand me, i don´t want to precociously raise my finger. It also took me a while to adapt the following techniques and i want to share them because they have proven their usefulness.

Be aware that i´m getting a little technical here and there, so you might want to open a second tab to google some words. This topic could fill a book, so don’t be to hard on me if i forget something or keep things shorter.

Use a Version Control System

Every person involved in a project needs a version control for their files.

What?? Yes, be it excel, photoshop or sourcecode files everything must go into a central version control database.
Why?? Ever received ten emails with a new version and of course inconsistent names? A version control database acts a single point of access for all project related files. The only question you´ll ask in the future is „Did you checked it in/out?“. You can go back to every version any time, put the blame on somebody and sleep better with the central backup on your mind.
Subversion, followed by cvs, is the most popular system and has proven its stability on many projects around the globe. You´ll find clients for all operating systems and also popular coding enviroments (eclipse) . The one i like best is TortoisSVN. Installing a subversion server and getting accommodated with a client like Tortoise takes you between 5 min and an hour (depending on your skills and teacher)!

Use a Ticketsystem

Everybody tends to forget certain things. A ticketsystem acts as your ToDo-brain and is absolutely inevitable for the project controlling. It lets you estimate timeperiods (set milestones) depending on how much work there still is to do. You can control your project members, retain bugs and when you go live it can serve as a customer feedback system.

Wide spread ones are trac, fogBugz or Mantis but you´ll also find

Use automated Tests

When it comes to testing one tends to think of „I clicked this through while coding, so it works“. Well yeah it probably works right, but can you click every single function/region of your software before every release or update? Definitely not, so one must use automated tests. I come from a php background and wasn’t aware of such until i started with RubyonRails. In Ruby and other languages you have a kind of a Testing-Culture which php is completely lacking. This is kind of scary since testing frameworks for php are available namely simpletest or phpunit.

Another good and simple approach to testing is selenium, which as a firefox plugins even enables normal users to perform automated tests. I´m not going to dive deeper into testing or even test driven development, just remember „Automated tests let you sleep better!“

Use an automated deployment workflow

Deploying/delivering a (web) software can involve checkout from a version control system, file transfers (to your webspace), database updates, automated tests, packing source files, rollback on errors or restarting server processes. Manually handling those steps can be pretty painstaking and of course you´ll tend to forget a step or the stepping order. The automation of those tasks is not trivial but there are tools like ANT or the great Capistrano to help you out. Another point is the time it takes to handle all deployment steps manually. You can easily spend half a day on deploying and another one on rolling it all back, because of some error which occured (if you did not test it good enough).

Comment the Code

Commenting source code is probably the most basic guideline a developer should follow. Ever had the situation where you spent an hour to find out what you wrote half a year ago? Or what about debugging someone elses code?

But also a customer should insist on code comments. What if you coder gets hit by a truck?

Another great reason for comments and the use of a common commenting language/markup is the automated creation of a software documentation. Tools to handle such are javaDoc, phpDocumentor or rdoc and you´ll also find them for other languages.

Develop Codeing Guidelines

This is not a task to be done by a customer, but he should at least ask for the existence of them. Such guidelines should refer to naming schemes for files, database tables/columns, functions and classes. Further they should cover code layout related specifications like indenting, bracket styles, or commenting.

The whole aim here is to bring consistency and beauty into the code which helps the developer to faster read and understand the program.

Use common (OpenSource) Frameworks

By „common“ i refer to „standardized“ and vastly spread pieces of code. Using Frameworks sets one ahead, because the abstraction layer saves code, time and prevents inventing the wheel twice.

To customers this means they can rely on a certain stability in terms of code quality and/or support, but more important they are less dependent on the developer. Why less dependent? Imagine a situation where you switch your coder and afterwards pay another programmer to clean this mess up. It is not only difficult to find a descent coder for this task, but also one who is willing to stick his noose into unknown spaghetti code. The solution will always be pretty expensive and you´ll probably end up with a refactoring using a framework.

Frameworks exist for every coding language and in a web project you´ll probably end up using a couple of them. I´ll just name a few in the following example:

  • Model/View/Controller(MVC) framework like cakePHP, Ruby on Rails, django for the main intelligence
  • prototype or jQuery for the javascript part
  • YAML for the CSS

A good programmer might not agree with me on this, and if there are strong coding guidelines, a deep documentation and a good application layout he might be right. But this does not reflect the software market reality. Further its is very unlikely that even a good programmer knows the deep details of each of the languages he is using, so a framework empowers him to achieve his tasks with less pain.

Don´t mix languages

Each language in a web project serves for a special porpuse. CSS for the looks, html for the structure, javascript for the funk and ruby for the main intelligence. Possible mixing of those languages can occur via html with inline css definitions, html with inline javascript, javascript creation via ruby or php.

The complete division of css and html is meanwhile pretty widespread, but the mix of javascript with html/php/ruby/.. is quite scary. Yes i know most developers only slowly dive into the secrets of js and frameworks like Ruby on Rails seem to take the pain out of implementing javascript. This is how i got started, when i hated javascript. But trust me you will dive into big ass problems when there are browser based bugs, custom animations you need, xss-attacks, speed issues or simply browsers without javascript.
I won’t dive into the javascript discussion deeper, instead just give a few statements which apply to other language divisions too:

  • better maintainability
  • better debugging
  • better profiling
  • you can hire a language expert and he does not need to know the other languages
  • you can switch a language implementation with ease f.ex. mobile Browser stylesheet, special javascript for an iPhone
  • higher code quality through separate testing f.ex. independently test ruby code, javascript or css

This was a whole bunch of information but i hope you took your time to go through each point. If you did, you now have some basics to ensure quality which serves all parties involved in a software project.

To sum it up:

  • as a customers you get better software and achieve greater control.
  • as a developer you can ask higher prices at lower costs due to higher quality.

2 Comments to Technical Web 2.0 Startup Basics and Software Quality Improvements

  1. niles's Gravatar niles
    17.01.2008 at 21:31

    Lots of great points. I’d also add that hosting is an important thing to consider, we had a horrible time getting started and ended up switching 3 times. We’re now with Slicehost and couldn’t be happier.

  2. 06.11.2007 at 19:20

    I fully agree with this summary. It’s sad that this things are often neglected because people want to save time in their projects. But in fact, they loose time and get poor quality.

  1. By on 18.01.2008 at 2:17
  2. By on 25.12.2007 at 23:45