On Tue, Nov 9, 2010 at 9:14 AM, Grant <emailgr...@gmail.com> wrote: >> Read the OP again. He wants to obsfuscate the code to make it >> unreadable for the people he's hiring to work on it. >> >> It would be simpler and cheaper to hire developers who don't >> understand programming language in question, computers, programming in >> general, or even english. >> >> Then don't let them access any computers that have the source code. >> >> You'll get better results that way -- far fewer bugs will be >> introduced. > > The idea isn't to make the code unreadable. Obviously anyone working > on it needs to be able to read and understand it. > > This idea was brought on while reading a Wikipedia page about modular > programming: > > "Theoretically, a modularized software project will be more easily > assembled by large teams, since no team members are creating the whole > system, or even need to know about the system as a whole. They can > focus just on the assigned smaller task." > > http://en.wikipedia.org/wiki/Modular_programming > > I don't mind system administration but I don't want to be a programmer > any more. I'd like to hire programmers to work in the manner > described above. They would each work on modules and not know about > the system as a whole. How can something like this be implemented? > > - Grant
Get ready to pay a lot more for the documentation and testing portions of your costs. If you write a clear spec for the modular block that the programmer is developing or maintaining then they can follow that during implementation. However, how do they test their code if they don't understand the environment that it's being used in? 1) Write test programs that call the block they developed or maintained. Ensure those test programs exercise _ALL_ the functions of the block in all possible permutations with all possible initial states that the module will see during it's life in the larger product. That's a very difficult problem to _prove_ you've done. I have worked on chip designs with hundreds of millions of transistors. In a sense every transistor is a line of code somewhere and it's simply very difficult to prove you've ever tested everything. I promise you that the processor in your computer has bugs in the hardware. They are there. Once in awhile you'll hit on and your PC will crash. No processor is 'perfect'. 2) Pay the developer to 'Instrument' your module so that every time it's called it saves some info that can be used to backtrace what has been happening. When a problem arises have a way to read and understand the implementation. This can slow down the performance of the system terribly. Keeping the software developers completely in the mushroom barn is (possibly) a pretty expensive thing to try and do. Hope this helps, Mark
