Figure B, on the other hand, shows a project which seemingly starts off slow because of the significant amount of time spent on defining requirements, laying out design standards, and establishing procedures for reporting, change requests, testing, documentation, etc. In other words, time is spent on Process.

FIGURE B


Here is a project with Process. Roll over picture for a larger image.

However, through careful planning and management of the project, and through the very use of Process, the amount of time spent on "non-productive" activities soon declines. Meanwhile, thanks to all that Process, you've managed to avoid the trap of having to fix a large number of avoidable bugs and reworking poorly written code. As an added bonus, this attention to Process on your initial project will give all your subsequent projects a jump-start by providing much of the foundation of re-usable standards and procedures.

If all this sounds like common sense, the reality is that developers are often under great pressure to "look busy," which often prevents a project from resembling Figure B.

One of the biggest challenges for developers who understand this reality is communicating it to their clients who want to "see results" immediately, especially when those clients have little experience overseeing software projects. The sad truth is that a shockingly high percentage of projects end up over budget and behind schedule, failing to deliver the desired functionality because of this problem. I have yet to meet a developer who is without at least one such horror story in his or her past.

The IT Factory Process
So how do IT Factory's tools help avoid this trap? One way to think of it would be to imagine all the Notes development best practices you've ever seen or read about integrated into a single, unified database architecture and made available through a user-friendly dialog-driven interface that allows for rapid implementation of standardized--yet customizable and upgradeable--Notes applications.

To achieve this, many common techniques employed by Notes developers (and more than a few advanced ones) have been re-engineered and re-packaged to maximize their flexibility and robustness. For example, the use of configuration documents (sometimes called keyword or control documents) is probably the most common technique for increasing the flexibility and user-customizability of a Notes database. Unfortunately, this functionality has been implemented almost as many different ways as there are Notes developers, with some implementations leaving something to be desired.

IT Factory's architecture includes a very sophisticated and standardized implementation of configuration document functionality, which provides capabilities that exceed even those of the most complex custom applications that I've seen or built myself. The IT Factory implementation is so well engineered that it even addresses one of the inherent weaknesses typical of this functionality, namely the performance hit from using DBLookups in keyword field formulas. To get around this problem, IT Factory utilizes database profile documents, which are a standard capability of Notes but poorly understood by all but the most senior Notes developers. The good news is that it isn't really necessary to understand profile documents to take advantage of their inherent performance benefits.