I have been receiving several questions in my email, and I've been doing my best to answer (I cannot afford to neglect my job... yet ). I think that it would be more interesting to answer a few of these questions publicly, as I'm no expert and by answering in public others could point out my errors, and ultimately, we all would learn. Therefore, this post inaugurates a series to answer some computer science-related questions of the readers of this blog. You may send your questions to my email (jose at halcode.com). Of course, I can only answer those questions at my reach. Let's start with the following 3 questions, which I had received several days ago:

1. Hi, Jose. Please, could you expand on the reasons why adding people to a late software project makes it later? by José Rodríguez (Venezuela).

That statement is known as Brooks's Law, and it was coined by the renowned computer scientist and software engineer Frederick P. Brooks. Concretely, the original statement found in his 1975 classic The Mythical Man-Month is "adding manpower to a late software project makes it later". Basically, the idea is that adding more analysts, designers or programmers to a project running behind the original schedule will delay it even more.

Broadly speaking, the rationale of Brooks's law is related to knowledge management. First, when new personnel is added to the project, some resources have to be diverted into training or informing the newcomers about the project's status, vision and philosophy. That will delay the project. Further, when the number of people participating in a project increases, so does the number of communication paths. Thereby, more resources (including time) are required in order to distribute the information. Regarding this point, you may be interested in reading my entry on "Knowledge Sharing" in Software Design, Trials and Errors.

2. What is a Reentrant Routine? by Ricardo Orozco (Venezuela)

A routine or procedure P is reentrant (or pure code) if it can be "re-entered" after it is already in execution. Basically, it means that P can be executed two or more times simultaneously, or alternatively, that P can be safely executed concurrently. There are some conditions P must follow in order to be reentrant, and you may check them in the Wikipedia entry for reentrant functions.

Some programs necessarily have to be reentrant. For instance, device drivers. A device driver has to be reentrant because another interrupt may be raised while the driver is running. This means that reentrancy allows for code sharing. For example, if a program consists of 600 KB of code and 200 KB of data, and n users are simultaneously using the program, we would require n x 600 KB of physical memory for the code if the program is not reentrant. But if the code is reentrant we can share it among the n users, saving a lot of memory.

3. How to characterize nasal consonants acoustically? by Rajeev Ranjan (India)
   

A good answer to this question would require plenty of explanations. I suggest you to check on pages 487-514 of Acoustic Phonetics by Professor Kenneth Stevens. But I'll provide you with some hints, anyway.

Nasal consonants are sonorant phonemes, but they exhibit significant losses due to the nasal tract coupling. Further, nasal spectra is relatively very stable during the oral tract closure (there are minimum acoustic alterations). Typically, F1 is located near to 250 Hz, F2 is weak, and F3 is near to 2 kHz. Remember that for these phonemes the acoustic energy also transits the nasal cavities. Such nasal cavities have different frequency properties. But the oral tract, albeit closed, also alters the acoustic transfer function. This transfer function, for simple phonemes such as vowels, includes only poles. However, when the oral tract is closed, the acoustic transfer function also includes zeros. And that changes the output in a great deal. The location of the first spectral zero of nasal consonants depends on the point of oral closure (for instance, the point of closure for /m/ is more anterior than /n/'s).

Thank you very much for your questions, and for reading. I encourage you to send more questions to my email account. So long.