CSE403 Software Engineering, Autumn 1999

Gary Kimura


Lecture #14 Notes

More Real World Design and Project Management Examples


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