Information Technology Reference
In-Depth Information
. It includes expected tech-
nical aspects of development along with its management aspects. Both
are important. For example, a lack of good communication within a team
can cause many, if not more problems in software delivery than perhaps
some technical aspect of a selected programming language.
This is an extended definition of
engineering
in
SEE covers all aspects of delivery. It goes beyond building the deliverable,
to cover its release, implementation, marketing, enhancements, support,
staffing, financials, and others. Execution deals with all non-engineering
activities from conception to delivery. (We place the engineering manage-
ment-related activities within the
Execution
layer of SEE.)
Many topics list what is required to be done to achieve some goal.
The problem is that the sum total of all that is said to be required to be
done turns out to be more suitable for an ideal world rather than the
constrained real-world environment in which one operates. As authors
we have tried to avoid falling too often into that ideal world advisory trap.
SEE also offers an opportunity to solve problems by looking at the
larger picture. If a problem cannot be solved technically, it could perhaps
be solved as a combination of technical and business solutions. For
example, many projects fail because the requirements are not properly
specified. Instead of trying to ensure perfect requirements, which we are
not sure is possible for any nontrivial situation, alternate approaches could
be put in place that will ensure reasonably reliable and functional systems.
Such an approach would require a combination of technical and mana-
gerial methods. For example, the product roadmap could be better under-
stood, which would help recognize where the anticipated changes are
likely to come; the architecture could be made (more) flexible based on
that; change control systems can be put in place that minimize the cost
of changes, considering the nature of the relationships and the environ-
ments in which the work is being done. Our SEE approach is an organizing
influence that will help one approach the problem of poor or changing
requirements as a systemic problem that requires a solution spread across
engineering and management.
One point we would like to touch on is that one should have fun in
what one is doing. As organizations grow larger, as business pressures
dominate, software creation becomes a job just like any other. Our
unscientific survey shows that there are many in the software industry
who are not having fun creating software. Perhaps it is part of the growing-
up process. If so, our prescription is to try to bring the fun back. It is a
necessary component of the creative act and SEE and other suggestions
notwithstanding, there is no substitute for it. Wait, you say, you are
confusing the creative spark with the managerial drudgery of converting
the creative spark to reality. No, we are not getting confused. The nature
engineering
