When discussing application design with programmers and analysts, the first question is invariably: “To do what?” This question leads to: “On which platform?” Then: “In which language?” Followed shortly by some variation of: “… and you want it when?”
The word “application” begs definition. An example of an application is tripping the shutter on a camera taking a photograph of a cosmic ray’s path across a cloud chamber. Here, the application needs to be real-time, as cosmic rays are not only naturally shy, they are moving at light speed. It mandates the use of a very low-level machine language such as Assembly and an operating system capable of handling real-time interrupts. Using a Content Management System (CMS) for an Internet web site is also an application, albeit, at a much higher level. It doesn’t have to be real-time, and when written using an appropriate platform independent high level language, it can be an effective answer to the given task. Once the problem is defined, then the number of possible solutions are reduced.
There are a number of platforms – both hardware and software – available in nearly countless combinations. A Unix-based operating system on an Intel machine is vastly different from a Mac machine running Mac OS X. Running a MS virtual machine under Linux with a SPARC64 chip is a simple example of a hybrid platform, which can be problematic for several reasons.
The platform often determines the language used, although, from a low-level machine-language point of view, the CPU – the actual chip, not the box with all the fans – is going to determine which dialect of Assembly is required, how interrupts, registers, and addresses are managed, and other similarly unique characteristics of the chip. In a very high level environment such as a CMS, the design of the CMS will dictate the configuration required. PHP and MySQL is the usual combination seen in Open Source environments, however, it most certainly is not the only option.
It’s a well-known computer programmer’s maxim that 90% of the development of a system takes 10% of the time; the remaining 10% takes 90% of the time. Time is always an issue with every client. The expectation is that any project – regardless of complexity – will be a “plug it in and turn it on” application. It’s also the case that non-programmer managers tend to be less than clear on what their expectations are for the final application. This is why an analyst makes the big money. Far too often, what the user says they want is not what they need. The fundamentals of application design are dependant on the specific requirements.
