web notes - a blog

Based on the assumption that the project has an adequate budget established by careful estimation and communication with the client, the following tracking can be used to determine the cost.

Track everything.

First, all the indirect fixed costs - rent, power, phone, water, taxes. For any given day, a certain amount of money is spent regardless of activity. Know this number.

Next, the direct fixed costs - server, Internet access.

Management should be tracked at the project level. Any meeting held to discuss a project should be billed, by all parties, to that project. That does not mean the client will be billed. It ensures that the cost of the project is accurate.

Direct labor costs must be carefully tracked. If it is related to the project, it must be tracked. Reporting must be specific enough to allow management to determine where the money was spent and why. Unauthorized charges must not be allowed.

Indirect labor cost must also be identified. For example, an email problem for the client. This must be billed as support. The same is true for training. These are hours spent assisting the customer that do not help complete the project.

Marketing should be identified as such, and reported - either with the project or the client.

A company that can’t manage a fixed price contract profitably will not succeed on an hourly billing system either. Instead of losing money, they will lose clients.

Clients need to know how much they will pay for a product or service, how long it will take to do the work, and they should be protected from mismanagement, mistakes, and scope creep - whether they caused them or not. A fixed price contract must be clearly detailed for both the provider and recipient, and then both parties must adhere to the agreement. It is much more difficult to ensure a project with hourly billing actually delivers what was sold, because the provider’s goal is to get paid for work - whether it is in the customer’s best interest or not.

This isn’t to say the providers are exclusively self-serving, but that they need to pay for the work done. If a client calls with a request that really should not be granted - the provider is likely to say ‘it is their money’. On a fixed price contract, a good provider will probably say, ‘that’s outside of the scope, it will cost extra’. The same is true for time - if a task exceeds the time allocated, but the client is still paying, the provider may continue to pursue it, although the deadline may slip.

If the client doesn’t understand the requirements well enough, they should clarify them or a subset, to allow a manageable project.

Maintenance is well-suited for hourly contracts, retainers or allowances, which allow the client to purchase enough service to address their needs, and then pay hourly for additional work.

The point is: if you have a well-defined set of requirements, and a company refuses to offer you a fixed-price contract, you should definitely talk to more companies.

An hourly contract is a financial vehicle that says, “we can do it, just give us money,” but doesn’t agree to ever finish it.

These three factors - quality, time, and cost are the same for software as any other product or service. In most cases, two out of three will be favorable (meaning high quality, done quickly, for a low cost). On many projects, quality and fast are not achievable, for any price, unless the team can quickly find and integrate good components.

To address this, a prototype may be developed quickly to demonstrate a concept, but the risk there is that the prototype will become the end product. That’s fine if the prototype is robust enough to work.

I think the best strategy for building a system where you need all three is to focus on the foundation or architecture, limit the functionality, and use that to build on. It takes money to make money, someone will have to be paid to develop the system. If you abandon quality in favor of time and reduced cost, you may attract enough interest to fund a new system, but you risk being labeled as a low quality provider, or being saddled with code that is difficult to work with.

Research and development prior to production engineering is almost always worth it. It can be skipped if you have alot of experience.

Often, regardless of the plan, version 1.0 of a system is almost entirely discarded and replaced eventually. This is an argument in favor of a rapidly developed prototype that looks okay and functions reasonably well, but is deliberately intended only for short term use. Another approach is to focus on the system architecture more heavily so that version 1.0 may be discarded, but the underlying architecture remains. This may be a better long term plan.

Web software seems to have about a 3 year lifespan. The technology is changing so fast, and the way people use the web is changing so fast, that even an excellent site needs to be built with an eye toward adapting to future requirements.

*** This post and link superseded by the ‘color map’ blog (see above) ***

The link provides a set of instructions and code which allow you to read the CSS files from a target application, then read CSS files from an existing site, and map the colors from the existing site into the target application, using sed.

This is brute force design, it would be very valuable for rapidly skinning an application to help a potential client visualize your application delivering their site.

The success of the approach is affected by the colors of both designs, this is a very simple method, the number of colors will impact how well they map.

The basic idea is to convert the colors from RGB into HSV, then reorder the HSV code into VSH - so the brightness takes precedence. In this case, it is assumed that the lightest colors will map to each other. Hue is virtually disregarded by its position.

The mechanics of the process are functioning as I wanted them to, although I haven’t tested it with live sites.

It also creates a shell script to generate image files of the colors, using ImageMagick, which is interesting but not actually used.

Requisite knowledge: Linux, PHP, bash, sed, regular expressions helpful.

I tried to put the text from the above link in the blog, but it didn’t work. Too many bizarre character strings.

This is the second half of the prior post - how to find out what version of PHP are running on your server. Use curl with the -I (uppercase i) option, followed by the domain name to get the HTTP headers. There are many options you can use with curl, and the server can be configured to suppress some of this information for improved security - so if you don’t get the results you need, refer to the man pages and try again.

HTTP/1.1 200 OK
Date: Fri, 21 Mar 2008 23:11:07 GMT
Server: Apache/1.3.41 (Unix) mod_jk/1.2.23 mod_deflate/1.0.21 mod_fastcgi/2.4.2 PHP/5.2.3 mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.4.8 FrontPage/5.0.2.2634a mod_ssl/2.8.31 OpenSSL/0.9.7a
X-Powered-By: PHP/4.4.8
Content-Type: text/html

Another approach is to create one file, ver.php, and link to it called ver.php5. It should contain the following:

echo phpversion();

Request both URLs through a browser to see what version is used to deliver them.