Am 10.11.2010 06:56, schrieb Grant Edwards: > On 2010-11-09, Florian Philipp <li...@f_philipp.fastmail.net> wrote: > >> Well, there are two ways to go here: > >> 1. Modularize what you have. Give every developer only the source he >> is supposed to work on and binary interfaces (libs + header files >> for C/C++) and documentation for everything else. >> >> Then the devs will be able to run the software but no one will >> have all the source code. >> >> 2. Do not give working code to anyone. Define specs, test cases, >> prototypes and mock-ups. Then tell your devs to develop against these. >> >> When they have finished their modules (classes, units, whatever), >> it is your job to integrate these modules and see whether they >> work together as expected. If they don't, improve your specs and >> tests and give the code back to the devs for another iteration. >> >> I favor the second approach, especially as there are tools available >> to help you and it is safer against reverse-engineering. > > Both of these approaches are going to involve a lot of overhead (the > second more so that the first). I would _guess_ than approach 2 will > add at least 50-100% overhead. IOW, there's a pretty good chance that > writing the whole thing yourself would take less of your time than > designing, specifying, coordinating, integrating, testing and managing > approach 2. [...]
Sure. But it will be fun! ;) ... Just kidding. Unless specifications, inline interface documentation (doxygen, javadoc) and unit tests were already planned or even done (kudos if you actually do this while developing), you are probably right concerning the overhead. Of course it all depends on your development environment. When you get into the embedded, real-time, high-performance, high-security or high-redundancy realm, specifications etc. tend to become less overhead in comparison to actual coding and algorithmic effort. There are reasons why in some environments it is even affordable to create two independent implementations and then choose the better one. I highly doubt that we are actually talking about such software here, though. Regards, Florian Philipp
signature.asc
Description: OpenPGP digital signature
