ACPI is a complete design disaster in every way. But we're kind of stuck with it.

Organization, planning, and documentation relate to the concept of 'coupling' in software design. If part of a computer program depends on the internal details of another part, the two parts are tightly coupled. If the two parts talk to each other through a well-defined interface that hides the internal structure of each part, the coupling is loose. When changes are required, tight coupling means that changes in one part may require matching changes in the other part, which will in turn affect other parts of the program. Loose coupling allows you to change one part without having to change the other part. This saves a huge amount of effort and leads to a better product. To make loose coupling work, you must define and document the interfaces between different parts of the program.

The real problem with THROWAWAY CODE comes when it isn't thrown away.

The best way to have a really great idea is to have a thousand ideas.

ANSI C is basically the language for gods. The language for somebody who wants to control everything, right? You can keep your scripting languages, your toy stuff...

Architecture is about decisions that are hard to change later.

Today's mathematical culture suffers from a style of publication, in which the results and the reasoning justifying them are published quite explicitly but in which all the pondering is rigorously suppressed, as if the need to ponder were a vulgar infirmity about which we don't talk in civilized company.

Hence, it should not surprise us that many of the established superprogrammers are freaks in some sense of the word: they look funny; they wear funny clothes; they refuse to work regular hours; they don't get along with normal people; and so forth.

The word "essay" comes from the French verb "essayer", which means "to try". An essay, in the original sense, is something you write to try to figure something out. This happens in software too. I think some of the best programs were essays, in the sense that the authors didn't know when they started exactly what they were trying to write.

[Writing an OS] can be overwhelming and you can burn youself out. Don't be afraid to admit you don't know something and put it to one side. When the time comes you'll know it and you'll be able to spend the time on the problem that it needs.

I worked 22 years in the industry, and I noticed that operating systems get cancer with age.

And don't EVER make the mistake that you can design something better than what you get from ruthless massively parallel trial-and-error with a feedback cycle. That's giving your intelligence _much_ too much credit.

The field is young. The subject domain is vast and difficult to catalog. The goal (creating high-quality software in an efficient, predictable manner) is lofty. But new sciences always flail around with qualitative, short-lived results in their early years. The newness of a field does not mean it is less important or less worthy of our best study. The newness of software engineering, to the contrary, means it is ripe with opportunities for seminal discoveries.

I have seen most dramatic results since I began urging [incremental development] on the project builders in my Software Engineering Laboratory class.

The morale effects are startling. Enthusiasm jumps when there is a running system, even a simple one. Efforts redouble when the first picture from a new graphics software system appears on the screen,even if it is only a rectangle. One always has, at every stage in the process, a working system. I find that teams can grow much more complex entities in four months than they can build.

I would generally agree that microkernels are probably the wave of the future. However, it is in my opinion easier to implement a monolithic kernel. It is also easier for it to turn into a mess in a hurry as it is modified.

Ignore everyone who tells you kernel hacking is hard, special or different. It's a large program, and bug fixing or driver tweaking can be a best starting point. It is however not magic, nor written in a secret language that only deep initiates with beards can read.

Play with it, try things, break it horribly and enjoy yourself. I started on the networking code because it didn't work very well. Everything I knew about TCP/IP I had downloaded the same day I started hacking the net code. My first attempts were not pretty but it was *fun*.

Verum ipsum factum (Understanding arises through making)