reg learning proper level of thinking/communication for a softwareproject

Hello,
I am working as a software developer for quite sometime. While I am
reasonably proficient at coding, I am finding it hard to gain traction
in one area: when discussing with other teams about software
integration (integrating products from other teams into ours), I find
it sometimes hard to discuss at higher level of things of how
architecture should be, and I tend to want to get down into actual
lowlevel details in how to go about implementing. THis is causing a
pain because I walk out of meeting without absorbing what other people
agree upon. I know that part of problem is communicating at proper
level of detail and part is to understand not to go to too much level
of depth when project is in initial stages (think at system level and
come up with issues appropriate to that level instead of thinking at
too much level of detail). I want to know if I can read some books to
enhance my knowledge for second case (learning to think at system
level). I think experience will add its benefit here but a book will
sure help.
Thanks,
Sunil

sunil wrote:

> I am working as a software developer for quite sometime. While I am
> reasonably proficient at coding, I am finding it hard to gain traction
> in one area: when discussing with other teams about software
> integration (integrating products from other teams into ours), I find
> it sometimes hard to discuss at higher level of things of how
> architecture should be, and I tend to want to get down into actual
> lowlevel details in how to go about implementing. THis is causing a
> pain because I walk out of meeting without absorbing what other people
> agree upon. I know that part of problem is communicating at proper
> level of detail and part is to understand not to go to too much level
> of depth when project is in initial stages (think at system level and
> come up with issues appropriate to that level instead of thinking at
> too much level of detail). I want to know if I can read some books to
> enhance my knowledge for second case (learning to think at system
> level). I think experience will add its benefit here but a book will
> sure help.

How would your communications work if you had this situation?

- all code has wall-to-wall unit tests
- to write new code, you must write a failing test, first
- anyone can change any code at any time so long as all tests pass
- everyone practices deliberately refactoring the code, to improve it
- everyone integrates every tiny change - even one line
- the integration script checks out anyone elses changes
- the integration script runs all the unit tests
- the script refuses to integrate unless all tests pass
- everyone pair programs
- everyone frequently rotates pairs
- everyone rotates in and out of others' groups
- everyone deploys a new reversion daily, automatically
- the product managers generate a new version, weekly

In that high level of rigor, your root problem goes away - the meeting. You
already know where the architecture is, and you can guide that architecture very
effectively, without the overhead of relaying your guidance thru others. And
other people, to the extent they can improve the architecture, are also more
effective at expressing their guidance. The code receives the best of everyone's
abilities, nearly simultaneously.

Now, which if any of the items on my checklist are you all doing?

--
Phlip

Responding to Sunil...

> I am working as a software developer for quite sometime. While I am
> reasonably proficient at coding, I am finding it hard to gain traction
> in one area: when discussing with other teams about software
> integration (integrating products from other teams into ours), I find
> it sometimes hard to discuss at higher level of things of how
> architecture should be, and I tend to want to get down into actual
> lowlevel details in how to go about implementing. THis is causing a
> pain because I walk out of meeting without absorbing what other people
> agree upon. I know that part of problem is communicating at proper
> level of detail and part is to understand not to go to too much level
> of depth when project is in initial stages (think at system level and
> come up with issues appropriate to that level instead of thinking at
> too much level of detail). I want to know if I can read some books to
> enhance my knowledge for second case (learning to think at system
> level). I think experience will add its benefit here but a book will
> sure help.

Basically I think you are talking about the difference between Systems
Engineering and Software Development. Integration is done at a much
higher level of abstraction than the implementation of the things being
integrated.

The Systems Engineer has three basic duties. One is to provide large
scale structure for the system (i.e., subsystems). The second is to
allocate requirements (both customer and high level design) to those
subsystems and define the way they communicate (interfaces). The third
is to define what low level technologies (e.g., CORBA for
interoperability), policies (e.g., performance has top priority),
strategies (e.g., shared virtual memory for multitasking communication),
etc. need to be implemented.

Note that the SE just *specifies* things like technologies and
strategies; the SE just defines What must be implemented, not How. The
Software Developer actually designs and implements how they work within
a subsystem.

I suspect your problems around integration are primarily related to the
definition of subsystems and how they communicate. Ideally that should
be done in terms of problem space invariants because that will provide
stability for the large scale structure when they don't change. So the
specification of integration is really at a quite different, much more
generic level than subsystem design and that probably results in a
disconnect when you are thinking about low level implementation.

There is also an issue around design requirements. The SE has a grand
vision for how the systems works and how the components will play
together. That vision is reflected in high level design requirements
allocated to the individual subsystems. One potential disconnect is
separating customer requirements from design requirements. Another
potential issue is where high level design requirements end and low
level design requirements begin. From your perspective as an SD, a gap
can be just as bad as an overlap (over specification).

So I think what you need to do is figure out how a Systems Engineer
would think about integration. IOW, you need to learn something about
Systems Engineering. The category on "Application Partitioning" in my
blog provides a preliminary perspective, but that just scratches the
surface. I think you need to get a book or two on Systems Engineering.

However, before you do that you should determine which school of thought
the SEs in your shop belong to. Many SEs use an approach whose origins
is Structured Development from the '70s. The core paradigm for that
approach is functional decomposition, which is reflected in the use of
OMG's SysML as a design notation. That makes sense for hybrid systems
because hardware is usually designed hierarchically with VHDL so there
is an instant mapping, but it can be a problem on the software side
where there is an additional suite of requirements for maintainability
that drives the use of OO techniques.

The other SE approach is based on OO techniques where direct problem
space abstraction is used instead of functional decomposition. That
approach does a good job of mapping to OO software, but not such a good
job of mapping to hardware.

The point here is to determine which school the SEs (or System
Architects, or whatever) in your shop use and find SE books that reflect
that approach. IOW, you want to be speaking the right language when
interpreting what they are saying.


--
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH