Philosophy

About us
Products
Services
Events
Contacts
Publications

Titus Corporation

Philosophy

 

Approach - Our approach to developing software is both agressive and reasoned. We practice what we preach by applying the same techniques we use to develop our products into whatever systems we build (or help our customers build). We also use our own products to build systems for you.

Requirements - Perhaps the most troublesome aspect of developing quality software is ensuring that requirements are fully implemented in code - and that when these requirements change, that they are reflected properly in the code. We use the USP Framework (one of our products) to assist in coordinating the related disciplines of Requirements, Analysis & Design, Configuration Management, Construction and Test.

Tool Selection - We believe that non-proprietary object-oriented programming languages and round-trip engineering are essential to the development of robust and maintainable systems.

Quality vs. Time - There is an undeniable inverse relationship between the quality of a product and the time it takes to build it (i.e., "Time To Market"). However, this trade-off is not always as extreme when techniques such as Component-Based Development (CBD) and the USP Framework are employed.

Architecture - We seek to emphasize architectural concepts that lead to scalable systems. This is accomplished by following well-known idioms and packaging patterns.

Management - We cannot expect managers who have never written real code to effectively manage those who have any more then we would expect a lay person to manage a surgeon. Carpenters have apprentices, doctors must suffer internship and school teachers must be "student teachers" first. No other industry operates in a less rigorous fashion, why should we?

Cowboys and Software Engineers - In many organizational settings, there is a cultural rift played out between the "Architect vs. the Programmer". The "software engineer/architect" heralds him/herself as one who is passionate about creating good software. The "cowboy/programmer" is the corporate "hero" - the one who stays up all night and makes a miracle happen. The truth is, we as developers need (less extreme) versions of both mentalities.

The heart of the matter is that one cannot claim to be an architect if they cannot write effective code - and one cannot claim to write quality code without applying sound architectural concepts. We strive to eliminate the differences between these two "camps" by challenging staff to "bone up" in the areas they personally feel less capable in, and by doing our best to ensure we aren't over-emphasizing either characteristic.