It's well known that software projects fail, by going over budget, producing a solution that is wrong, or by just not producing a working system at all. This has been well addressed and everyone has their own silver bullet to fix it (none of which work quite like they are promissed to). I'm not going to discuss these alleged fixes (mostly because being overrun by methodology partisans is not my idea of fun). I'm instead going to occassionally discuss a sign that your project is in trouble.

Today's sign is focusing more on presentation than the fundamental operation of the system. This tends to flow out of end users judging the system on what they can see, which can be compounded by non-technical project managers doing the same. Other causes include developers who tend to focus on what they prefer to work with, which is an unfortunately common scenario.

Applications need a certain level of presentation to be acceptable. This level will vary depending on the audience, you can generally get away with having your internal application be less polished that your public website or an application that you're trying to sell to a wide audience. In a custom application the cost of making it pretty can be more directly apparent to the client and there will be a limit to the amount you may spend on it. For general distribution a well presented application or website is assumed and you will be decreasing your potential customer base if you lack in this area.

My concern is when presentation of the application becomes all and serious bugs and missing functionality is neglected in order to increase the effort spent to make the application visually appealing. The presentation of the application is irrelevant if it cannot fulfill its function or is sufficiently unreliable or inaccurate that it is not worth using.

The following example is a composite taken from my experience with some details not directly relevant to my point changed to anonomise it.

Company X is building a web application to automate critical business functionality. This application will be used constantly by staff all across the country, failures could cause significant lost business and loss of reputation. Errors in the application could also cause significant losses to the company or expose them to liability.

The application has a number of significant bugs and is still missing functionality. Yet there is a period where changes are checked in constantly to improve the presentation of the application. This ties up some of the senior developers on the project who really should be addressing the issues with the application. The application looks good, but it can't perform all of its critical functions and those it can have many bugs that would be unacceptable in production.

Initially management sees the shiny web interface and thinks things are going well. However after a number of missed deadlines they are beginning to become concerned, by which point the problems are near-terminal. The architecture of the system has been allowed to slide sufficiently that the effort required to fix it and resolve the bugs in the system, let alone add the new functionality, has approached the point where it may be more cost effective to throw it away and start again. This is the kind of things that gets people fired.

Obviously a project shouldn't get to such a state in the first place, but this isn't a helful observation when it does happen. Seeing a significant and rising bug count and a development effort that focuses on presentation issues is a significant warning sign that your development effort has lost its way. If you detect this happening then you need to take immediate corrective action. This can be a painful decision and its seldom a popular one. In the long term failing to address the fundamental problems in your development simply compounds them and will be significantly more painful when things eventually collapse.