Roy Schestowitz <newsgroups@xxxxxxxxxxxxxxx> writes:
> __/ [ BearItAll ] on Monday 09 October 2006 13:28 \__
>
>> Peter Hayes wrote:
>>
>>> Surely switching staff around like that isn't very efficient. They won't
>>> be up to speed on their new project, or is the code so compartmentalised
>>> that they can work on one snippet without understanding the context?
>>>
>>> -
>>
>> That is how MS do it, or at least they did up to maybe two years ago (last
>> time I was in touch with a mate who worked for them). Individuals and small
>> teams get a tiny amount to write, not necessarily told what the end product
>> is.
>>
>> That can work if the pieces are very self contained, for example if the
>> programmer did the serial comms classes or the human interface or some
>> other self contained area. But the pieces can apparently be much smaller
>> than that.
>>
>> It is only to stop programmers being able to do naughty things, which is
>> understandable, but it also means that it can be very ineficient in both
>> bloat and functionally. Programmers adding something to a class or function
>> of their own because they are unaware that in the same module when finished
>> that little function will available.
>>
>> The module approach I think is better when the job is large enough to split
>> for teams or individuals. Not necesarily self contained parts, but
>> modualized such that they is clear distinction between the parts, like lego
>> bricks.
>
> ...And all that unlike, for example, Open Source projects that are jointly
> combined to form a complex system of interchangeable parts, e.g. embed Xorg
> in BSD or Linux, use GNOME or KDE, LILO or GRUB...
As usual, Roy has totally missed the point. Roy is talking software system
components, whereas the OP was about programming "black box" modules
within such components.
But getting away from Roy's mistake and concentrating on the actual
matter a hand : Allowing too much access is a VERY bad thing :
programmers do naughty things and leverage optimizations that they
should not know about. When that optimization is then corrupted by the
owner, the reliant systems break. This is a bad thing.
Here's a hint lads : its why "private" exists in C++.
You publish what they need and nothing more. When you publish these
needs correctly then the benefits are manyfold since the programmer
utilising this documented API is (generally) secured against future changes.
>
> Protocols and modularity are the key to maintaining complex systems. The days
> of a small and monolithic Windows 1.0 are long gone, so it's time to
> compromise old strategies. *smile*
>
> Best wishes,
>
> Roy
--
QOTD:
"The marines and I have something in common; we're both looking for
a few good men!"
|
|
