CSE403 Software Engineering,
Autumn 1999
Gary Kimura
Lecture #14 Notes
1)
Design and Group Management
a)
Today
we’ll look at some more design and management issues
b)
I
like the term group or people management because what it really is doing is
managing a group of people who are working together on a project
c)
In
terms of design we’ll look at some overall design issues and some personal
lessons
2)
Group management
a)
Good
group management is a big factor in doing a large multi-person project
b)
Management
works both ways (i.e., managing subordinates and managing your manager)
c)
When
you give someone the responsibility over a project then you’ve also given the
authority to make decisions for that project.
Another way of saying this is that “Responsibility implies authority”
d)
Pay
versus other rewards
e)
Group
rivalries both inter- and intra-company (for a large company) are a fact of
life. This doesn’t mean they are
necessarily always good or bad
i)
Good
because
(1)
Hopefully
the best engineered design wins
(2)
Some
people really enjoy and perform well under competition (e.g., 98 versus NT)
ii)
Bad
because
(1)
Waste
of resources
(2)
Hard
feelings and undercutting
3)
More real world design issues
a)
Having
a well understood and well communicated architecture is vital
i)
Consensus
on a design is not always practical
ii)
Architects
at various levels of the system are needed to formulate and communicate the
design to others on the team
b)
A
well designed API set helps define the division of modules, labor, and
necessary information hiding
c)
Modularization
and information hiding are abstractly good; but they do have a cost
i)
Performance
might be sacrificed by a clean design.
For example,
(1)
“Heavy
weight” procedure cost time and space, and identifying these cost is not always
easy. Even the number of parameters has
a cost. Using procedures cannot to be
avoided, but must be respected.
(2)
Internal data structures are often
conceptually different allocations but each allocation has a small overhead
cost
ii)
Using
well designed submodules can make debugging conceptually easier; however
experience shows that programmers often need to know fairly minute subcomponent
details to debug their new code
d)
Functional
module layout and temporal module organization go hand-in-hand
i)
A
clean design also needs a clean workspace
ii)
Modules
can be organized separating exported from local routines
iii)
Global
header files need to be well organized
iv)
Smart
editors make locating places where functions and structures are defined and
used easier
e)
Often
we need to sleep on the design
f)
As
with other engineering aspects the group must not become paralyzed trying to
settle design issues. An educated
decision is better than no decision.
g)
Experience
and education helps us all make better educated decisions
h)
Try
and anticipate changes. Here are some
NT design issues that have cropped up through the years. Not all of them are changeable or fixable.
i)
32
bit to 64 bit expansion
ii)
Big
and little endian support
iii)
Time
format without time zone information
iv)
String
format is a counted string limited to 64KB in length and with Unicode the
string length no longer equals character count.
v)
Memory
allocator changes