|
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.
| 
