Software engineers

"For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of go to statements in the programs they produce. More recently I discovered why the use of the go to statement has such disastrous effects, and I became convinced that the go to statement should be abolished from all "higher level" programming languages."

"Our intellectual powers are rather geared to master static relations and ... our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible."

"Testing shows the presence, not the absence of bugs"

"A convincing demonstration of correctness being impossible as long as the mechanism is regarded as a black box, our only hope lies in not regarding the mechanism as a black box."

"When we take the position that it is not only the programmer's responsibility to produce a correct program but also to demonstrate its correctness in a convincing manner, then the above remarks have a profound influence on the programmer's activity: the object he has to produce must be usefully structured."

"The art of programming is the art of organizing complexity, of mastering multitude and avoiding its bastard chaos as effectively as possible."

"Program testing can be used to show the presence of bugs, but never to show their absence!"

"The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague."

"Another two years later, in 1957, I married and Dutch marriage rites require you to state your profession and I stated that I was a programmer. But the municipal authorities of the town of Amsterdam did not accept it on the grounds that there was no such profession. And, believe it or not, but under the heading "profession" my marriage act shows the ridiculous entry "theoretical physicist"!"

"Automatic computers have now been with us for a quarter of a century. They have had a great impact on our society in their capacity of tools, but in that capacity their influence will be but a ripple on the surface of our culture, compared with the much more profound influence they will have in their capacity of intellectual challenge without precedent in the cultural history of mankind."

"After having programmed for some three years, I had a discussion with A. van Wijngaarden, who was then my boss at the Mathematical Center in Amsterdam, a discussion for which I shall remain grateful to him as long as I live. The point was that I was supposed to study theoretical physics at the University of Leiden simultaneously, and as I found the two activities harder and harder to combine, I had to make up my mind, either to stop programming and become a real, respectable theoretical physicist, or to carry my study of physics to a formal completion only, with a minimum of effort, and to become....., yes what? A programmer? But was that a respectable profession? For after all, what was programming? Where was the sound body of knowledge that could support it as an intellectually respectable discipline? I remember quite vividly how I envied my hardware colleagues, who, when asked about their professional competence, could at least point out that they knew everything about vacuum tubes, amplifiers and the rest, whereas I felt that, when faced with that question, I would stand empty-handed. Full of misgivings I knocked on van Wijngaarden's office door, asking him whether I could "speak to him for a moment"; when I left his office a number of hours later, I was another person. For after having listened to my problems patiently, he agreed that up till that moment there was not much of a programming discipline, but then he went on to explain quietly that automatic computers were here to stay, that we were just at the beginning and could not I be one of the persons called to make programming a respectable discipline in the years to come? This was a turning point in my life and I completed my study of physics formally as quickly as I could. One moral of the above story is, of course, that we must be very careful when we give advice to younger people; sometimes they follow it!"

"Please don't fall into the trap of believing that I am terribly dogmatic about [the go to statement]. I have the uncomfortable feeling that others are making a religion out of it, as if the conceptual problems of programming could be solved by a simple trick, by a simple form of coding discipline!"

"Don't blame me for the fact that competent programming, as I view it as an intellectual possibility, will be too difficult for "the average programmer" — you must not fall into the trap of rejecting a surgical technique because it is beyond the capabilities of the barber in his shop around the corner."

"Are you quite sure that all those bells and whistles, all those wonderful facilities of your so-called "powerful" programming languages belong to the solution set rather than to the problem set?"

"Some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate "the ease of programming" with the ease of making undetected mistakes."

"Several people have told me that my inability to suffer fools gladly is one of my main weaknesses."

"Write a paper promising salvation, make it a 'structured' something or a 'virtual' something, or 'abstract', 'distributed' or 'higher-order' or 'applicative' and you can almost be certain of having started a new cult."

"For me, the first challenge for computing science is to discover how to maintain order in a finite, but very large, discrete universe that is intricately intertwined. And a second, but not less important challenge is how to mould what you have achieved in solving the first problem, into a teachable discipline: it does not suffice to hone your own intellect (that will join you in your grave), you must teach others how to hone theirs. The more you concentrate on these two challenges, the clearer you will see that they are only two sides of the same coin: teaching yourself is discovering what is teachable."

"As a result of a long sequence of coincidences I entered the programming profession officially on the first spring morning of 1952, and as far as I have been able to trace, I was the first Dutchman to do so in my country."

"We must be very careful when we give advice to younger people: sometimes they follow it!"

"We must not forget that it is not our [computing scientists'] business to make programs, it is our business to design classes of computations that will display a desired behaviour."

"The major cause [of the software crisis] is that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem. In this sense the electronic industry has not solved a single problem, it has only created them, it has created the problem of using its products."

"FORTRAN's tragic fate has been its wide acceptance, mentally chaining thousands and thousands of programmers to our past mistakes."

"LISP has been jokingly described as "the most intelligent way to misuse a computer". I think that description a great compliment because it transmits the full flavor of liberation: it has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts."

"When FORTRAN has been called an infantile disorder, full PL/1, with its growth characteristics of a dangerous tumor, could turn out to be a fatal disease."

"Using PL/1 must be like flying a plane with 7000 buttons, switches and handles to manipulate in the cockpit."

"If you want more effective programmers, you will discover that they should not waste their time debugging, they should not introduce the bugs to start with."

"Program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence."

"The effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programmer."

"The purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise."

"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense."

"APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums."

"FORTRAN, 'the infantile disorder', by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use."

"In the good old days physicists repeated each other's experiments, just to be sure. Today they stick to FORTRAN, so that they can share each other's programs, bugs included."

"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."

"Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer."

"Simplicity is prerequisite for reliability."

"Programming is one of the most difficult branches of applied mathematics; the poorer mathematicians had better remain pure mathematicians."

"We can found no scientific discipline, nor a hearty profession, on the technical mistakes of the Department of Defense and, mainly, one computer manufacturer."

"About the use of language: it is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead."

"Thank goodness we don't have only serious problems, but ridiculous ones as well."

"[Though computer science is a fairly new discipline, it is predominantly based on the Cartesian world view. As Edsgar W. Dijkstra has pointed out] A scientific discipline emerges with the - usually rather slow! - discovery of which aspects can be meaningfully 'studied in isolation for the sake of their own consistency."

"How do we convince people that in programming simplicity and clarity —in short: what mathematicians call "elegance"— are not a dispensable luxury, but a crucial matter that decides between success and failure?"

"I think of the company advertising "Thought Processors" or the college pretending that learning BASIC suffices or at least helps, whereas the teaching of BASIC should be rated as a criminal offence: it mutilates the mind beyond recovery."

"The question of whether Machines Can Think... is about as relevant as the question of whether Submarines Can Swim."

"Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better."

"Probably I am very naive, but I also think I prefer to remain so, at least for the time being and perhaps for the rest of my life."

"A confusion of even longer standing came from the fact that the unprepared included the electronic engineers that were supposed to design, build and maintain the machines. The job was actually beyond the electronic technology of the day, and, as a result, the question of how to get and keep the physical equipment more or less in working condition became in the early days the all-overriding concern. As a result, the topic became – primarily in the USA – prematurely known as 'computer science' – which, actually, is like referring to surgery as 'knife science' – and it was firmly implanted in people's minds that computing science is about machines and their peripheral equipment. Quod non [Latin: "Which is not true"]. We now know that electronic technology has no more to contribute to computing than the physical equipment. We now know that programmable computer is no more and no less than an extremely handy device for realizing any conceivable mechanism without changing a single wire, and that the core challenge for computing science is hence a conceptual one, viz., what (abstract) mechanisms we can conceive without getting lost in the complexities of our own making."

"When we had no computers, we had no programming problem either. When we had a few computers, we had a mild programming problem. Confronted with machines a million times as powerful, we are faced with a gigantic programming problem."

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger."

"As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. (...) Software engineering has accepted as its charter "How to program if you cannot."

"The problems of the real world are primarily those you are left with when you refuse to apply their effective solutions."

"When I came back from Munich, it was September, and I was Professor of Mathematics at the Eindhoven University of Technology. Later I learned that I had been the Department's third choice, after two numerical analysts had turned the invitation down; the decision to invite me had not been an easy one, on the one hand because I had not really studied mathematics, and on the other hand because of my sandals, my beard and my "arrogance" (whatever that may be)."

"In the wake of the Cultural Revolution and now of the recession I observe a mounting pressure to co-operate and to promote "teamwork". For its anti-individualistic streak, such a drive is of course highly suspect; some people may not be so sensitive to it, but having seen the Hitlerjugend in action suffices for the rest of your life to be very wary of "team spirit". Very."

"I mean, if 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself "Dijkstra would not have liked this", well, that would be enough immortality for me."

"A picture may be worth a thousand words, a formula is worth a thousand pictures."

"It is time to unmask the computing community as a Secret Society for the Creation and Preservation of Artificial Complexity."

"Elegance is not a dispensable luxury but a quality that decides between success and failure."

"Industry suffers from the managerial dogma that for the sake of stability and continuity, the company should be independent of the competence of individual employees. Hence industry rejects any methodological proposal that can be viewed as making intellectual demands on its work force. Since in the US the influence of industry is more pervasive than elsewhere, the above dogma hurts American computing science most. The moral of this sad part of the story is that as long as computing science is not allowed to save the computer industry, we had better see to it that the computer industry does not kill computing science."

"May, in spite of all distractions generated by technology, all of you succeed in turning information into knowledge, knowledge into understanding, and understanding into wisdom."

"The required techniques of effective reasoning are pretty formal, but as long as programming is done by people that don't master them, the software crisis will remain with us and will be considered an incurable disease. And you know what incurable diseases do: they invite the quacks and charlatans in, who in this case take the form of Software Engineering gurus."

"It is not the task of the University to offer what society asks for, but to give what society needs."

"There are very different programming styles. I tend to see them as Mozart versus Beethoven. When Mozart started to write, the composition was finished. He wrote the manuscript and it was 'aus einem Guss' (from one cast). In beautiful handwriting, too. Beethoven was a doubter and a struggler who started writing before he finished the composition and then glued corrections onto the page. In one place he did this nine times. When they peeled them, the last version proved identical to the first one."

"What is the shortest way to travel from Rotterdam to Groningen, in general: from given city to given city. It is the algorithm for the shortest path, which I designed in about twenty minutes. One morning I was shopping in Amsterdam with my young fiancée, and tired, we sat down on the café terrace to drink a cup of coffee and I was just thinking about whether I could do this, and I then designed the algorithm for the shortest path. As I said, it was a twenty-minute invention. In fact, it was published in '59, three years late. The publication is still readable, it is, in fact, quite nice. One of the reasons that it is so nice was that I designed it without pencil and paper. I learned later that one of the advantages of designing without pencil and paper is that you are almost forced to avoid all avoidable complexities. Eventually that algorithm became, to my great amazement, one of the cornerstones of my fame."

"In short, I suggest that the programmer should continue to understand what he is doing, that his growing product remains firmly within his intellectual grip. It is my sad experience that this suggestion is repulsive to the average experienced programmer, who clearly derives a major part of his professional excitement from not quite understanding what he is doing. In this streamlined age, one of our most undernourished psychological needs is the craving for Black Magic and apparently the automatic computer can satisfy this need for the professional software engineer, who is secretly enthralled by the gigantic risks he takes in his daring irresponsibility. For his frustrations I have no remedy......"

"This is generally true: any sizeable piece of program, or even a complete program package, is only a useful tool that can be used in a reliable fashion, provided that the documentation pertinent for the user is much shorter than the program text. If any machine or system requires a very thick manual, its usefulness becomes for that very circumstance subject to doubt!"

"The precious gift that this Turing Award acknowledges is Dijkstra's style: his approach to programming as a high, intellectual challenge; his eloquent insistence and practical demonstration that programs should be composed correct, not just debugged into correctness; and his illuminating perception of problems at the foundations of program design."

"A revolution is taking place in the way we write programs and teach programming, because we are beginning to understand the associated mental processes more deeply. It is impossible to read the recent [E. W. Dijkstra, O.-J. Dahl, and C. A. R. Hoare] book Structured Programming, without having it change your life. The reason for this revolution and its future prospects have been aptly described by E.W. Dijkstra in his 1972 Turing Award Lecture, The Humble Programmer."

"The working vocabulary of programmers everywhere is studded with words originated or forcefully promulgated by E. W. Dijkstra—display, deadly embrace, semaphore, go-to-less programming, structured programming. But his influence on programming is more pervasive than any glossary can possibly indicate."

"Edsger W. Dijkstra's 1969 "Structured Programming" article precipitated a decade of intense focus on programming techniques that has fundamentally altered human expectations and achievements in software development. Before this decade of intense focus, programming was regarded as a private, puzzle-solving activity of writing computer instructions to work as a program. After this decade, programming could be regarded as a public, mathematics-based activity of restructuring specifications into programs. Before, the challenge was in getting programs to run at all, and then in getting them further debugged to do the right things. After, programs could be expected to both run and do the right things with little or no debugging. Before, it was common wisdom that no sizable program could be error-free. After, many sizable programs have run a year or more with no errors detected. These expectations and achievements are not universal because of the inertia of industrial practices. But they are well-enough established to herald fundamental change in software development."

"The difference between a computer programmer and a computer scientist is a job-title thing. Edsgar Dijkstra wants proudly to be called a "computer programmer," although he hasn't touched a computer now for some years. (...) His great strength is that he is uncompromising. It would make him physically ill to think of programming in C++."

"You probably know that arrogance, in computer science, is measured in nanodijkstras."

"...I also discovered books of two great computer scientists from whose work I learned the scientific foundation of my trade: Donald Knuth and Edsger Dijkstra. Knuth taught me the answers. Dijkstra taught me the questions. Time and time again I come back to their works for new insights."

"The first classic is one of the great works in computer programming: E. W. Dijkstra, Cooperating Sequential Processes (1965). Here Dijkstra lays the conceptual foundation for abstract concurrent programming."

"The Edsger W. Dijkstra Prize in Distributed Computing is named for Edsger Wybe Dijkstra (1930-2002), a pioneer in the area of distributed computing. His foundational work on concurrency primitives (such as the semaphore), concurrency problems (such as mutual exclusion and deadlock), reasoning about concurrent systems, and self-stabilization comprises one of the most important supports upon which the field of distributed computing is built. No other individual has had a larger influence on research in principles of distributed computing. The prize is given for outstanding papers on the principles of distributed computing, whose significance and impact on the theory and/or practice of distributed computing have been evident for at least a decade."

"Most experienced IT professionals will agree that developing and adhering to a standard architecture is key to the success of large-scale software development. Computer pioneer Edsger Dijkstra validated this notion when he developed THE operating system in 1968. Since then, layered architectures have proved their viability in technological domains, such as hardware and networking. Layering has proved itself in the operating system domain; however, the same benefits are available when applied to e-commerce or to thin client–oriented applications. Layered architectures have become essential in supporting the iterative development process by promoting reusability, scalability, and maintainability."

"Edsger Dijkstra, one of the giants of our field and a passionate believer in the mathematical view of programs and programming (...) Over the previous quarter-century, he had formulated many of the great intellectual challenges of the field as programming—the goto statement, structured programming, concurrent processes, semaphores, deadlocks, recursive programming in Algol, and deriving correct programs."

"Of great influence to Pascal was Structured Programming, put forth by E. W. Dijkstra. This method of proceeding in a design would obliviously be greatly encouraged by the use of a Structured Language, a language with a set of constructs that could freely be combined and nested. The textual structure of a program should directly reflect its flow of control."

"In 1965 Dijkstra wrote his famous Notes on Structured Programming and declared programming as a discipline in contrast to a craft. Also in 1965 Hoare published an important paper about data structuring. These ideas had a profound influence on new programming language, in particular Pascal. Languages are the vehicles in which these ideas were to be expressed. Structured programming became supported by a structured programming language."

"The notion of the concurrent program as a means for writing parallel programs without regard for the underlying hardware was first introduced by Edsger Dijkstra (1968). Moti Ben-Ari (1982) elegantly summed up Dijkstra's idea in three sentences: 'Concurrent programming is the name given to programming notation and techniques for expressing potential parallelism and solving the resulting synchronization and communication problems. Implementation of parallelism is a topic in computer systems (hardware and software) that is essentially independent of concurrent programming. Concurrent programming is important because it provides an abstract setting in which to study parallelism without getting bogged down in the implementation details.'"

"The revolution in views of programming started by Dijkstra's iconoclasm led to a movement known as structured programming, which advocated a systematic, rational approach to program construction. Structured programming is the basis for all that has been done since in programming methodology, including object-oriented programming. As the first book on the topic [Structured Programming by Dijkstra, Ole-Johan Dahl, and Tony Hoare] shows, structured programming is about much more than control structures and the goto. Its principal message is that programming should be considered a scientific discipline based on mathematical rigor."

"Since the early work of E.W. Dijkstra (1965), who introduced the mutual exclusion problem, the concept of a process, the semaphore object, the notion of a weakest precondition, and guarded commands (among many other contributions), synchronization is no longer a catalog of tricks but a domain of computing science with its own concepts, mechanisms, and techniques whose results can be applied in many domains. This means that process synchronization has to be a major topic of any computer science curriculum."

"Although Dijkstra will always be remembered for structured programming, and for his style and approach, he also invented many other of the standard ideas of programming. If you are struggling with multi-threaded programming you may have encountered the semaphore, and the idea of the "deadly embrace". These, and more, are the result of Dijkstra's work on concurrent programming. He showed how this particularly difficult area of programming could be made relatively safe."

"While concurrent program execution had been considered for years, the computer science of concurrency began with Edsger Dijkstra's seminal 1965 paper that introduced the mutual exclusion problem. (...) The first scientific examination of fault tolerance was Dijkstra's seminal 1974 paper on self-stabilization. (...) The ensuing decades have seen a huge growth of interest in concurrency—particularly in distributed systems. Looking back at the origins of the field, what stands out is the fundamental role played by Edsger Dijkstra, to whom this history is dedicated."

"We generally trace the idea of building computer systems in layers back to a 1967 paper that the Dutch computer scientist Edsger Dijkstra gave to a joint IEEE Computer Society/ACM conference. Prior to this paper, engineers had struggled with the problem of how to organize software. If you look at early examples of programs, and you can find many in the electronic library of the Computer Society, you will find that most code of that era is complicated, difficult to read, hard to modify, and challenging to reuse. In his 1967 paper, Dijkstra described how software could be constructed in layers and gave an example of a simple operating system that used five layers. He admitted that this system might not be a realistic test of his ideas but he argued that the "larger the project, the more essential the structuring!" The idea of using layers to control complexity has become a mainstay of software architecture. We see it in many forms and apply it to many problems. We see it in the hierarchy of classes in object-oriented programming and in the structure of Service-Oriented Architecture (SOA). SOA is a relatively recent application of layering in computer science. It was articulated in 2007 as a means of controlling complexity in business systems, especially distributed systems that make substantial use of the Internet. Like Dijkstra's plan for system development, its layering system is called the SOA Solution Stack or S3. The S3's nine layers are: 1) operational systems, 2) service components, 3) services, 4) business processes, 5) consumer actions, 6) system integration, 7) quality control and assurance, 8) information architecture, and 9) system governance and policies."

"Computer Science is no more about computers than astronomy is about telescopes."

"Go To statement considered harmful"

"I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones."

"Do you pine for the nice days of minix-1.1, when men were men and wrote their own device drivers?"

"Well, with a subject like this, I'm afraid I'll have to reply. Apologies to minix-users who have heard enough about linux anyway. I'd like to be able to just "ignore the bait", but … time for some serious flamefesting!"

"Your job is being a professor and researcher: That's one hell of a good excuse for some of the brain-damages of Minix."

"Portability is for people who cannot write new programs."

"Well, I probably won't get too good grades even without you: I had an argument (completely unrelated – not even pertaining to OS's) with the person here at the university that teaches OS design. I wonder when I'll learn :)"

"No. That's it. The cool name, that is. We worked very hard on creating a name that would appeal to the majority of people, and it certainly paid off: thousands of people are using linux just to be able to say "OS/2? Hah. I've got Linux. What a cool name". 386BSD made the mistake of putting a lot of numbers and weird abbreviations into the name, and is scaring away a lot of people just because it sounds too technical."

"Dijkstra probably hates me."

"When you say "I wrote a program that crashed Windows", people just stare at you blankly and say "Hey, I got those with the system, *for free*""

"If you need more than 3 levels of indentation, you're screwed anyway, and should fix your program."

"You know you're brilliant, but maybe you'd like to understand what you did 2 weeks from now."

"An infinite number of monkeys typing into GNU Emacs would never make a good program."

"It's a bird … it's a plane … no, it's KernelMan, faster than a speeding bullet, to your rescue. Doing new kernel versions in under 5 seconds flat …"

"Some people have told me they don't think a fat penguin really embodies the grace of Linux, which just tells me they have never seen an angry penguin charging at them in excess of 100 mph. They'd be a lot more careful about what they say if they had."

"See, you not only have to be a good coder to create a system like Linux, you have to be a sneaky bastard too ;-)"

"Only wimps use tape backup: real men just upload their important stuff on ftp, and let the rest of the world mirror it ;)"

"If you still don't like it, that's OK: that's why I'm boss. I simply know better than you do."

"…the Linux philosophy is "laugh in the face of danger". Oops. Wrong one. "Do it yourself". That's it."

"The main reason there are no raw devices [in Linux] is that I personally think that raw devices are a stupid idea."

"Making Linux GPL'd was definitely the best thing I ever did."

"(In answer to the question: In the extreme case, if it was just you doing all the code, and the rest of the world quietly used it, would it make sense to give it away free? Unless you're particularly grateful for other free things you've got off the Net, would the answer be No?":)"

""Regression testing"? What's that? If it compiles, it is good; if it boots up, it is perfect."

"My name is Linus Torvalds and I am your god."

"If Microsoft ever does applications for Linux it means I've won."

"I was thrown out of fourth grade because I couldn't write my own name, and it's been all downhill from there."

"I'd like to say that I knew this would happen, that it's all part of the plan for world domination."

"Note that nobody reads every post in linux-kernel. In fact, nobody who expects to have time left over to actually do any real kernel work will read even half. Except Alan Cox, but he's actually not human, but about a thousand gnomes working in under-ground caves in Swansea. None of the individual gnomes read all the postings either, they just work together really well."

"Talk is cheap. Show me the code."

"I'm a bastard. I have absolutely no clue why people can ever think otherwise. Yet they do. People think I'm a nice guy, and the fact is that I'm a scheming, conniving bastard who doesn't care for any hurt feelings or lost hours of work, if it just results in what I consider to be a better system. And I'm not just saying that. I'm really not a very nice person. I can say "I don't care" with a straight face, and really mean it."

"Once you realize that documentation should be laughed at, peed upon, put on fire, and just ridiculed in general, THEN, and only then, have you reached the level where you can safely read it and try to use it to actually implement a driver."

"To kind of explain what Linux is, you have to explain what an operating system is. And the thing about an operating system is that you're never ever supposed to see it. Because nobody really uses an operating system; people use programs on their computer. And the only mission in life of an operating system is to help those programs run. So an operating system never does anything on its own; it's only waiting for the programs to ask for certain resources, or ask for a certain file on the disk, or ask to connect to the outside world. And then the operating system steps in and tries to make it easy for people to write programs."

"Yeah. And as Linus once said: most numerical problems today in pure CPU cycles are actually 3D games. … It's not "incorrect" to say that you want the result faster, even if that result doesn't match your theoretical models."

"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people."

"Hey, that's not a bug, that's a FEATURE! You know what the most complex piece of engineering known to man in the whole solar system is? Guess what – it's not Linux, it's not Solaris, and it's not your car. It's you. And me. And think about how you and me actually came about – not through any complex design. Right. "Sheer luck". Well, sheer luck, AND:"

"I allege that SCO is full of it."

"They are smoking crack."

"Those that can, do. Those that can't, complain."

"Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect."

"Modern PCs are horrible. ACPI is a complete design disaster in every way. But we're kind of stuck with it. If any Intel people are listening to this and you had anything to do with ACPI, shoot yourself now, before you reproduce."

"There are literally several levels of SCO being wrong. And even if we were to live in that alternate universe where SCO would be right, they'd still be wrong."

"Nobody should start to undertake a large project. You start with a small trivial project, and you should never expect it to get large. If you do, you'll just overdesign and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the sheer size of the work you envision. So start small, and think about the details. Don't think about some big picture and fancy design. If it doesn't solve some fairly immediate need, it's almost certainly over-designed. And don't expect people to jump in and help you. That's not how these things work. You need to get something half-way useful first, and then others will say "hey, that almost works for me", and they'll get involved in the project."

"Anybody who tells me I can't use a program because it's not open source, go suck on rms. I'm not interested. 99% of that I run tends to be open source, but that's my choice, dammit."

"The NIH syndrome (Not Invented Here) is a disease."

"A lot of people still like Solaris, but I'm in active competition with them, and so I hope they die."

"2.6.: still a stable kernel, but accept bigger changes leading up to it (timeframe: a month or two)."

"It was such a relief to program in user mode for a change. Not having to care about the small stuff is wonderful."

"Don't bother. Bram doesn't know what he's talking about."

"Which mindset is right? Mine, of course. People who disagree with me are by definition crazy. (Until I change my mind, when they can suddenly become upstanding citizens. I'm flexible, and not black-and-white.)"

"I chose 1000 originally partly as a way to make sure that people that assumed HZ was 100 would get a swift kick in the pants."

"I'm always right. This time I'm just even more right than usual."

"The fact that ACPI was designed by a group of monkeys high on LSD, and is some of the worst designs in the industry obviously makes running it at any point pretty damn ugly."

"I personally just encourage people to switch to KDE."

"Now, most of you are probably going to be totally bored out of your minds on Christmas day, and here's the perfect distraction. Test 2.6.15-rc7. All the stores will be closed, and there's really nothing better to do in between meals."

"For example, the GPLv2 in no way limits your use of the software. If you're a mad scientist, you can use GPLv2'd software for your evil plans to take over the world ("Sharks with lasers on their heads!!"), and the GPLv2 just says that you have to give source code back. And that's OK by me. I like sharks with lasers. I just want the mad scientists of the world to pay me back in kind. I made source code available to them, they have to make their changes to it available to me. After that, they can fry me with their shark-mounted lasers all they want."

"I claim that Mach people (and apparently FreeBSD) are incompetent idiots."

"I like colorized diffs, but let's face it, those particular color choices will make most people decide to pick out their eyes with a fondue fork."

"…git actually has a simple design, with stable and reasonably well-documented data structures. In fact, I'm a huge proponent of designing your code around the data, rather than the other way around, and I think it's one of the reasons git has been fairly successful […] I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships."

"EFI is this other Intel brain-damage (the first one being ACPI)."

"I think people can generally trust me, but they can trust me exactly because they know they don't have to."

"… even if the Hurd didn't depend on Linux code (and as far as I know, it does, but since I think they have their design heads firmly up their *sses anyway with that whole microkernel thing, I've never felt it was worth my time even looking at their code), I don't believe a religiously motivated development community can ever generate as good code except by pure chance."

"I'm a huge believer in evolution (not in the sense that "it happened" – anybody who doesn't believe that is either uninformed or crazy, but in the sense "the processes of evolution are really fundamental, and should probably be at least thought about in pretty much any context")."

"Gcc is crap."

"Friends don't let friends use [gcc] "-W"."

"It's one of those rare "perfect" kernels. So if it doesn't happen to compile with your config (or it does compile, but then does unspeakable acts of perversion with your pet dachshund), you can rest easy knowing that it's all your own damn fault, and you should just fix your evil ways."

"Me, I just don't care about proprietary software. It's not "evil" or "immoral," it just doesn't matter. I think that Open Source can do better, and I'm willing to put my money where my mouth is by working on Open Source, but it's not a crusade – it's just a superior way of working together and generating code."

"Nobody actually creates perfect code the first time around, except me. But there's only one of me."

"If you have ever done any security work – and it did not involve the concept of "network of trust" – it wasn't security work, it was – masturbation. I don't know what you were doing. But trust me, it's the only way you can do security, it's the only way you can do development."

"So the whole "We have a list and we're not telling you" should tell you something. Don't you think that if Microsoft actually had some really foolproof patent, they'd just tell us and go, "nyaah, nyaah, nyaah!"?"

"I don't ask for money. I don't ask for sexual favors. I don't ask for access to the hardware you design and sell. I just ask for the thing I gave you: source code that I can use myself."

"I'm an egotistical bastard, and I name all my projects after myself. First Linux, now git."

"You try to claim that the GPLv3 causes "More developers", and that, my idiotic penpal, is just crazy talk that you made up."

"I have an ego the size of a small planet, but I'm not _always_ right [...]."

"Is "I hope you all die a painful death" too strong?"

"C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it."

"C++ is in that inconvenient spot where it doesn't help make things simple enough to be truly usable for prototyping or simple GUI programming, and yet isn't the lean system programming language that C is that actively encourages you to use simple and direct constructs."

"It has nothing to do with dinosaurs. Good taste doesn't go out of style"

"Yes, I realize that there's a lot of insane people out there. However, we generally don't do kernel design decisions based on them. But we can pat the insane users on the head and say "we won't guarantee it works, but if you eat your prozac, and don't bother us, go do your stupid things"."

"Controlling a laser with Linux is crazy, but everyone in this room is crazy in his own way. So if you want to use Linux to control an industrial welding laser, I have no problem with your using PREEMPT_RT."

"I think Leopard is a much better system [than Windows Vista] … but OS X in some ways is actually worse than Windows to program for. Their file system is complete and utter crap, which is scary."

"And what's the Internet without the rick-roll?"

"Security people are often the black-and-white kind of people that I can't stand. I think the OpenBSD crowd is a bunch of masturbating monkeys, in that they make such a big deal about concentrating on security to the point where they pretty much admit that nothing else matters to them."

"It's what I call "mental masturbation", when you engage is some pointless intellectual exercise that has no possible meaning."

"Sometimes "pi = 3.14" is (a) infinitely faster than the "correct" answer and (b) the difference between the "correct" and the "wrong" answer is meaningless. And this is why I get upset when somebody dismisses performance issues based on "correctness". The thing is, some specious value of "correctness" is often irrelevant because it doesn't matter. While performance almost always matters. And I absolutely detest the fact that people so often dismiss performance concerns so readily."

"Real quality means making sure that people are proud of the code they write, that they're involved and taking it personally."

"The fact is, there aren't just two sides to any issue, there's almost always a range of responses, and "it depends" is almost always the right answer in any big question."

"Your problem has nothing to do with git, and everything to do with emacs. And then you have the gall to talk about "Unix design" and not gumming programs together, when you yourself use the most gummed-up piece of absolute sh*t there is!"

"The thing that has always disturbed me about O_DIRECT is that the whole interface is just stupid, and was probably designed by a deranged monkey on some serious mind-controlling substances [*]."

"Your code is shit."

"Crying that it's an application bug is like crying over the speed of light: you should deal with reality, not what you wish reality was."

"I may make jokes about Microsoft at times, but at the same time, I think the Microsoft hatred is a disease."

"There are "extremists" in the free software world, but that's one major reason why I don't call what I do "free software" any more. I don't want to be associated with the people for whom it's about exclusion and hatred."

"Your argument is shit."

"Every time I see some piece of medical research saying that caffeine is good for you, I high-five myself. Because I'm going to live forever."

"Standards are paper. I use paper to wipe my butt every day. That's how much that paper is worth."

"Toto, I don't think we're talking white-socks-and-sandals any more."

"This whole ARM thing is a f*cking pain in the ass."

"Why don't we write code that just works? Or absent a "just works" set of patches, why don't we revert to code that has years of testing? This kind of "I broke things, so now I will jiggle things randomly until they unbreak" is not acceptable. [...] Don't just make random changes. There really are only two acceptable models of development: "think and analyze" or "years and years of testing on thousands of machines". Those two really do work."

"So here's a plea: if you have anything to do with security in a distro, and think that my kids (replace "my kids" with "sales people on the road" if you think your main customers are businesses) need to have the root password to access some wireless network, or to be able to print out a paper, or to change the date-and-time settings, please just kill yourself now. The world will be a better place."

"We're not masturbating around with some research project. We never were. Even when Linux was young, the whole and only point was to make a *usable* system. It's why it's not some crazy drug-induced microkernel or other random crazy thing."

"Of course, I'd also suggest that whoever was the genius who thought it was a good idea to read things ONE F*CKING BYTE AT A TIME with system calls for each byte should be retroactively aborted. Who the f*ck does idiotic things like that? How did they not die as babies, considering that they were likely too stupid to find a tit to suck on?"

"People say that you should not micro-optimize; but, if what you love is micro-optimization, that's what you should do."

"I started Linux as a desktop operating system. And it's the only area where Linux hasn't completely taken over. That just annoys the hell out of me."

"Nvidia has been the single worst company we've ever dealt with. So, Nvidia, fuck you!"

"I wish everybody was as nice as I am."

"I tend to call myself an anti-visionary because to me, what is much more important than vision is execution. I've always quoted Edison saying that genius is 99% perspiration and 1% inspiration [...]."

"I like offending people, because I think people who get offended should be offended."

"[In response to Good job. More public indecency, less TSA, that's what I say."

"Somebody is trying to kill all the kernel developers."

"[...] I really hate big laptops. I can't understand people who lug around 15" (or 17"!) monsters. The right weight for a laptop is 1kg, no more."

"Obsessing about things is important, and things really do matter, but if you can't let go of them, you'll end up crazy."

"I'm not sentimental. Good riddance."

"WE DO NOT BREAK USERSPACE!"

"I realize that lawyers are brought up (probably from small children) to think that "technically true" is what matters, but when you make public PR statements, they should be more than "technically" true. They should be honest. There's a big f*cking difference."

"Microsoft isn't evil, they just make really crappy operating systems."

"But this is definitely another of those "This is our most desperate hour. Help me, Al-biwan Ke-Viro, you're my only hope" issues. Al? Please don't make me wear that golden bikini."

"I hope I won't end up having to hunt you all down and kill you in your sleep."

"Whoever came up with "hold the shift key for eight seconds to turn on 'your keyboard is buggered' mode" should be shot."

"There aren't enough swear-words in the English language, so now I'll have to call you perkeleen vittupää just to express my disgust and frustration with this crap."

"That's the spirit. Greg has taught you well. You have controlled your fear. Now, release your anger. Only your hatred can destroy me. Come to the dark side, Sarah. We have cookies."

"Because if you want me to "act professional", I can tell you that I'm not interested. I'm sitting in my home office wearing a bathrobe. The same way I'm not going to start wearing ties, I'm *also* not going to buy into the fake politeness, the lying, the office politics and backstabbing, the passive aggressiveness, and the buzzwords. Because THAT is what "acting professionally" results in: people resort to all kinds of really nasty things because they are forced to act out their normal urges in unnatural ways."

"XML is crap. Really. There are no excuses. XML is nasty to parse for humans, and it's a disaster to parse even for computers. There's just no reason for that horrible crap to exist."

"Lookie here, your compiler does some absolutely insane things with the spilling, including spilling a *constant*. For chrissake, that compiler shouldn't have been allowed to graduate from kindergarten. We're talking "sloth that was dropped on the head as a baby" level retardation levels here."

"I don't respect people unless I think they deserve the respect. There are people who think that respect is something that should be given, and I happen to be one of the people who is perfectly happy saying no; respect should be earned. And without being earned, you don't get it. It's really that simple."

"One of the things, none of the distributions have ever done right is application packaging [...] making binaries for linux desktop applications is a major fucking pain in the ass."

"[GPL] version 3 was not a good "here we give you version 2" and then we try to sneak in this new rules and try force everyone to upgrade; that was the part I disliked. The FSF did really sneaky stuff, downright immoral in my opinion."

"I may be a huge computer nerd, but even so I don't think education should be about computers. Not as a subject, and not as a classroom resource either."

"On the internet nobody can hear you being subtle."

"I don’t care about you."

"the most important part of open source is that people are allowed to do what they are good at" and "all that [diversity] stuff is just details and not really important."

"I am a lazy person, which is why I like open source, for other people to do work for me."

"We don't merge kernel code just because user space was written by a retarded monkey on crack."

"Christ, people. Learn C, instead of just stringing random characters together until it compiles (with warnings)."

"Get rid of it. And I don't *ever* want to see that shit again."

"I've actually felt slightly uncomfortable at TED for the last two days, because there's a lot of vision going on, right? And I am not a visionary. I do not have a five-year plan. I'm an engineer. And I think it's really -- I mean -- I'm perfectly happy with all the people who are walking around and just staring at the clouds and looking at the stars and saying, "I want to go there." But I'm looking at the ground, and I want to fix the pothole that's right in front of me before I fall in. This is the kind of person I am."

"I was 21 at the time, so I was young, but I had already programmed for half my life, basically. And every project before that had been completely personal and it was a revelation when people just started commenting, started giving feedback on your code. And even before they started giving code back, that was, I think, one of the big moments where I said, "I love other people!" Don't get me wrong -- I'm actually not a people person."

"The desktop hasn't really taken over the world like Linux has in many other areas, but just looking at my own use, my desktop looks so much better than I ever could have imagined. Despite the fact that I'm known for sometimes not being very polite to some of the desktop UI people, because I want to get my work done. Pretty is not my primary thing. I actually am very happy with the Linux desktop, and I started the project for my own needs, and my needs are very much fulfilled. That's why, to me, it's not a failure. I would obviously love for Linux to take over that world too, but it turns out it's a really hard area to enter. I'm still working on it. It's been 25 years. I can do this for another 25. I'll wear them down."

"Lawsuits destroy community. They destroy trust. They would destroy all the goodwill we've built up over the years by being nice."

"The fact is, the people who have created open source and made it a success have been the developers doing work - and the companies that we could get involved by showing that we are not all insane crazy people like the FSF. The people who have *destroyed* projects have been lawyers that claimed to be out to "save" those projects."

"I've been personally pretty disappointed with ARM as a hardware platform, not as an instruction set, though I've had my issues there, too. [...] What I wanted to upgrade to was Acorn Archimedes ... the thing that gave ARM its name."

"None of this "there is no way to continue" bullshit. Because it is pure and utter SHIT."

"BULLSHIT. Have you _looked_ at the patches you are talking about? You should have - several of them bear your name. [...] As it is, the patches are COMPLETE AND UTTER GARBAGE. [...] WHAT THE F*CK IS GOING ON?"

"It looks like the IT security world has hit a new low. If you work in security, and think you have some morals, I think you might want to add the tag-line "No, really, I'm not a whore. Pinky promise" to your business card. Because I thought the whole industry was corrupt before, but it's getting ridiculous. At what point will security people admit they have an attention-whoring problem?"

"Can I just once again state my love for it and hope it gets merged soon? Maybe the code isn't perfect, but I've skimmed it, and compared to the horrors that are OpenVPN and IPSec, it's a work of art."

"This is my reality. I am not an emotionally empathetic kind of person and that probably doesn't come as a big surprise to anybody. Least of all me. The fact that I then misread people and don't realize (for years) how badly I've judged a situation and contributed to an unprofessional environment is not good. This week people in our community confronted me about my lifetime of not understanding emotions. My flippant attacks in emails have been both unprofessional and uncalled for. Especially at times when I made it personal. In my quest for a better patch, this made sense to me. I know now this was not OK and I am truly sorry."

"Don't use ZFS. It's that simple. It was always more of a buzzword than anything else, I feel, and the licensing issues just make it a non-starter for me."

"You don't know what you are talking about, you don't know what mRNA is, and you're spreading idiotic lies. Maybe you do so unwittingly, because of bad education. Maybe you do so because you've talked to "experts" or watched youtube videos by charlatans that don't know what they are talking about. But dammit, regardless of where you have gotten your mis-information from, any Linux kernel discussion list isn't going to have your idiotic drivel pass uncontested from me. [...] Get vaccinated. Stop believing the anti-vax lies. And if you insist on believing in the crazy conspiracy theories, at least SHUT THE HELL UP about it on Linux kernel discussion lists."

"I know most of us are preparing for Christmas, but give it a whirl, ok? How important are those presents (and that family) anyway?"

"Please, as you emerge from your holiday-induced food coma, do give it a quick test so that we can all be happy about the final release next weekend."

"...today, March 14th, is the 29th anniversary of the Linux 1.0 announcement. Of course, there are other arguably more important dates in Linux history, but this is one of them."

"I’m actually a horrible MIS person, and I would never want to maintain my own server. I’m a programmer for chrissake! The same way you should fear me if I hold a soldering iron, you should be very very nervous if I were to do any server management... and on a similar note: not only am I not much of a MIS person, I’m also not much of a social networking person. I foresee a lot of disappointment in the future of any followers of this account."

"It’s Caturday. Minky is no longer with us, but this is probably my favorite picture of her."

"It’s Sunday, which means no more cat pictures, and instead just the usual -rc release. Prize for odd bug this week goes to an otherwise harmless off-by-one buglet that then in turn confused clang sufficiently to generate bogus code that our ‘objtool’ checks then (correctly) complained about it. This is the kind of exciting lives that us kernel developers lead."

"Pet peeve of the day: all the people talking about how ChatGPT is not “conscious” and how it does not “understand” what it is saying, but just putting likely-sounding words together into likely-sounding sentences. Extra bonus points for using an example of a math problem as a way to show how these AI chat-bots talk about things they don’t really understand. The irony. The lack of self-awareness. It burns."

"Sometimes you have one of those days that just shows how incompetent you are... Moral of the day: RTFM."

"I’ve maintained a branch of the old micro-emacs (not GNU emacs) for decades. And by “maintained” I really mean “mostly kept working”. It’s a scrappy little editor from the eighties(!) and the “s” in scrappy is silent... Over the decades, I’ve “enhached” that thing to actually mostly understand UTF-8, and increased some internal limits, but it’s mostly the same thing that I used in the early nineties... I don’t love the fact that it’s a very limited text editor. I’d like syntax highlighting etc. But my fingers are absolutely hardcoded to it, and I am not in the least interested in something that makes me switch away from those (much less start using a mouse to move around etc). Which is just a very long way to say: “Does anybody know of some slightly more modern GUI editor that actually has good support for really changing keybindings”... And yes, I know one answer is “teach your fingers new ways”. But my micro-emacs works just fine, and so it really isn’t worth it to me... I’d rather maintain just a keybinding file than a whole scrappy editor... I’m not interested in yet another “runs in a terminal” editor, or some even older editor (ie “real” emacs, or vim) that just has had more lipstick applied over the years."

"It's Easter Sunday, which means that we're all about to gorge on mämmi (Right? You *do* have your carton of mämmi ready to go, don't you?)."

"Life is good. We have a dishwasher again. Our old one broke (again!) and while I fixed it myself last time, I wasn’t willing to deal with a dishwasher that keeps breaking. I grew up washing dishes by hand, and I’d largely forgotten how much I hated it. Ten days without a working dishwasher is ten days too many."

"(In response to a post of the Linux Kernel infrastructre maintainer showcasing an online scam mentioning God) Damn. Who will take care of the kernel.org infrastructure now? God really didn’t think that one through."

"I’m a card-carrying atheist, I think a woman’s right to choose is very important, I think that “well regulated militia” means that guns should be carefully licensed and not just randomly given to any moron with a pulse, and I couldn’t care less if you decided to dress up in the “wrong” clothes or decided you’d rather live your life without feeling tied to whatever plumbing you were born with. And dammit, if that all makes me “woke”, then I think anybody who uses that word as a pejorative is a f*cking disgrace to the human race. So please just unfollow me right now."

"I will now go back to my cave and continue pulling stuff, I just had to do something else for a while. Some people relax with a nice drink by the pool, I relax by playing around with inline asm."

"The day we finally get rid of HIGHMEM I will dance on its grave. I have hated that thing for a long long time."

"A third of a century. And it *still* isn't ready. I really need to get my sh*t together.."

"You're a smart person. I feel like I've given you enough hints. Why don't you sit back and think about it, and let's make it clear: you have exactly two choices here:"

"If you haven't heard of Russian sanctions yet, you should try to read the news some day. And by "news", I don't mean Russian state-sponsored spam. As to sending me a revert patch - please use whatever mush you call brains. I'm Finnish. Did you think I'd be *supporting* Russian aggression? Apparently it's not just lack of real news, it's lack of history knowledge too."

"Finally, I have a firm belief that most firmware developers are not actually humans, but are instead caged rodents fed a solid diet of crack cocaine. Because that would explain a lot."

"How about you accept the fact that maybe the problem is you. You think you know better. But the current process works. It has problems, but problems are a fact of life. There is no perfect."

"And no, I am not looking for yes-men, and I like it when you call me out on my bullshit. I say some stupid things at times, there needs to be people who just stand up to me and tell me I'm full of shit."

"But I much prefer other people solving my problems for me. So me having to come up with a project is actually a failure of the world—and the world just hasn’t failed in the last 20 years for me."

"I'm told that there are people claiming to "tokenize" my git repositories with my approval. I just want to clarify that that is not the case. I do not believe in monetizing my repositories. If you believe crypto-currencies are anything but a scam, I have a bridge to sell you. But I'm not selling source code."

"It's memorial day tomorrow here in the US, but like the USPS, "neither snow nor rain nor heat nor gloom of night" - nor memorial day - stops the merge window."

"People are strange, and you can't fix people."

"And yeah, I don't have a solid plan for when the major number itself gets big. But doing the math - by that time, I expect that we'll have somebody more competent in charge who isn't afraid of numbers past the teens. So I'm not going to worry about it."

"If 386BSD had been available when I started on Linux, Linux would probably never had happened."

"Software is like sex; it's better when it's free."

"The memory management on the PowerPC can be used to frighten small children."

"OK, I admit it. I was just a front-man for the real fathers of Linux, the Tooth Fairy and Santa Claus."

"95 percent of all software developers believe they are in the top 5 percent when it comes to knowledge and skills ."

"Guess what? Wheels have been round for a really long time, and anybody who "reinvents" the new wheel is generally considered a crackpot. It turns out that "round" is simply a good form for a wheel to have. It may be boring, but it just tends to roll better than a square, and "hipness" has nothing what-so-ever to do with it."

"I don't doubt at all that virtualization is useful in some areas. What I doubt rather strongly is that it will ever have the kind of impact that the people involved in virtualization want it to have."

"First off, I'm actually perfectly well off. I live in a good-sized house, with a nice yard, with deer occasionally showing up and eating the roses (my wife likes the roses more, I like the deer more, so we don't really mind). I've got three kids, and I know I can pay for their education. What more do I need? The thing is, being a good programmer actually pays pretty well; being acknowledged as being world-class pays even better. I simply didn't need to start a commercial company. And it's just about the least interesting thing I can even imagine. I absolutely hate paperwork. I couldn't take care of employees if I tried. A company that I started would never have succeeded – it's simply not what I'm interested in! So instead, I have a very good life, doing something that I think is really interesting, and something that I think actually matters for people, not just me. And that makes me feel good."

"So LSM stays in. No ifs, buts, maybes or anything else. When I see the security people making sane arguments and agreeing on something, that will change. Quite frankly, I expect hell to freeze over before that happens, and pigs will be nesting in trees. But hey, I can hope."

"So I would not be surprised if the globbing libraries, for example, will do NFD-mangling in order to glob "correctly", so even programs ported from real Unix might end up getting pathnames subtly changed into NFD as part of some hot library-on-library action with UTF hackery inside."

"In the near future, the web is going to be the master copy of human knowledge. We need to figure out ways to use that knowledge."

"Eventually, I decided that thinking was not getting me very far and it was time to try building."

"Where will we be ten years from now? CRT’s will be a thing of the past, multimedia will no longer be a buzzword, pen-based and voice input will be everywhere, and university students will still be editing with emacs. Pens and touchscreens are too low-bandwidth for real interaction; voice will probably also turn out to be inadequate. (Anyway, who would want to work in an environment surrounded by people talking to their computers?) Mice are sure to be with us a while longer, so we should learn how to use them well."

"Object-oriented design is the roman numerals of computing."

"On a related topic, let me say that I'm not much of a fan of object-oriented design. I've seen some beautiful stuff done with OO, and I've even done some OO stuff myself, but it's just one way to approach a problem. For some problems, it's an ideal way; for others, it's not such a good fit. [...] OO is great for problems where an interface applies naturally to a wide range of types, not so good for managing polymorphism (the machinations to get collections into OO languages are astounding to watch and can be hellish to work with), and remarkably ill-suited for network computing. That's why I reserve the right to match the language to the problem, and even - often - to coordinate software written in several languages towards solving a single problem. It's that last point - different languages for different subproblems - that sometimes seems lost to the OO crowd."

"Those days are dead and gone and the eulogy was delivered by Perl."

"I started keeping a list of these annoyances but it got too long and depressing so I just learned to live with them again. We really are using a 1970s era operating system well past its sell-by date. We get a lot done, and we have fun, but let's face it, the fundamental design of Unix is older than many of the readers of Slashdot, while lots of different, great ideas about computing and networks have been developed in the last 30 years. Using Unix is the computing equivalent of listening only to music by David Cassidy."

"The major things we saw wrong with Unix when we started talking about what would become Plan 9, back around 1985, all stemmed from the appearance of a network. As a stand-alone system, Unix was pretty good. But when you networked Unix machines together, you got a network of stand-alone systems instead of a seamless, integrated networked system. Instead of one big file system, one user community, one secure setup uniting your network of machines, you had a hodgepodge of workarounds to Unix's fundamental design decision that each machine is self-sufficient."

"One odd detail that I think was vital to how the group functioned was a result of the first Unix being run on a clunky minicomputer with terminals in the machine room. People working on the system congregated in the room - to use the computer, you pretty much had to be there. (This idea didn't seem odd back then; it was a natural evolution of the old hour-at-a-time way of booking machines like the IBM 7090.) The folks liked working that way, so when the machine was moved to a different room from the terminals, even when it was possible to connect from your private office, there was still a "Unix room" with a bunch of terminals where people would congregate, code, design, and just hang out. (The coffee machine was there too.)"

"The Unix room still exists, and it may be the greatest cultural reason for the success of Unix as a technology. More groups could profit from its lesson, but it's really hard to add a Unix-room-like space to an existing organization. You need the culture to encourage people not to hide in their offices, you need a way of using systems that makes a public machine a viable place to work - typically by storing the data somewhere other than the "desktop" - and you need people like Ken and Dennis (and Brian Kernighan and Doug McIlroy and Mike Lesk and Stu Feldman and Greg Chesson and ...) hanging out in the room, but if you can make it work, it's magical. When I first started at the Labs, I spent most of my time in the Unix room. The buzz was palpable; the education unparalleled."

"Syntax highlighting is juvenile. When I was a child, I was taught arithmetic using colored rods. I grew up and today I use monochromatic numerals."

"I assume that a precisely defined, verifiable, executable, and translatable UML is a Good Thing and leave it to others to make that case... In the summer of 1999, the UML has definitions for the semantics of its components. These definitions address the static structure of UML, but they do not define an execution semantics. They also address (none too precisely) the meaning of each component, but there are "semantic variation points" which allow a component to have several different meanings. Multiple views are defined, but there is no definition of how the views fit together to form a complete model. When alternate views conflict, there is no definition of how to resolve them. There are no defined semantics for actions... To determine what requires formalization, the UML must distinguish clearly between essential, derived, auxiliary, and deployment views. An essential view models precisely and completely some portion of the behavior of a subject matter, while a derived view shows some projection of an essential view... All we need now is to make the market aware that all this is possible, build tools around the standards defined by the core, executable UML, and make it so..."

"In its current form UML is designed to support a wide variety of different modelling techniques and formalisms. This is evident, for example, in the state machine formalism which allows both Moore and Mealy formalism with hierarchical states including concurrent sub-states and both synchronous and asynchronous calling semantics. The result of this is not only that almost any state modelling style can be supported but also that many combinations of elements have no defined execution semantics. It is now widely recognised within the UML community, however, that considerable benefit can be gained by forming subsets of the UML with well defined execution semantics. Such subsets can form an “executable UML” which would enable the simulation, execution, testing and ultimately translation of UML models into target code. As part of this movement, work is progressing under the auspices of the OMG towards the definition of “profiles” that define such subsets and towards the more detailed definition of the contents of “actions” including a more precise definition of the execution semantics of UML models."

"I was astonished to be invited to what became the meeting that originated the Agile Manifesto because my work had always been based around building models... The other signatories were kind enough, back in 2001, to write the manifesto using the word “software” (which can include executable models), not “code” (which is more specific.) As such I felt able, in good conscience, to become a signatory to the Manifesto while continuing to promote executable modeling. Ten years on we have a standard action language for agile modeling."

"An object in OOA represents a single typical but unspecified instance of something in the real world - any airplane, I don't care which one, as long as it is typical. The object-oriented analyst distinguishes this concept from that of a specified instance: Airplane number N2713A, Air Force One, or The Spirit of St. Louis, for example."

"While a small domain (consisting of fifty or fewer objects) can generally be analyzed as a unit, large domains must be partitioned to make the analysis a manageable task. To make such a partitioning, we take advantage of the fact that objects on an information model tend to fall into clusters: groups of objects that are interconnected with one another by many relationships. By contrast, relatively few relationships connect objects in different clusters. When partitioning a domain, we divide the information model so that the clusters remain intact... Each section of the information model then becomes a separate subsystem. Note that when the information model is partitioned into subsystems, each object is assigned to exactly one subsystem."

"Creating a modeling language that is also an executable language has long been a goal of the software community. Many years ago, in 1968 to be exact, while working with software components to successfully develop a telecommunications system, we created a modeling language that was the forerunner to UML. To model components we used sequence diagrams, collaboration diagrams, and state transition diagrams (a combination of state charts and activity diagrams). Our modeling language then seamlessly translated the component models into code. Each code component was in its turn compiled into an executable component that was deployed in our computer system. The computer system was a component management system—thus we had "components all the way down.""

"Executable UML is at the next higher layer of abstraction, abstracting away both specific programming languages and decisions about the organization of the software so that a specification built in Executable UML can be deployed in various software environments without change."

"Executable UML is designed to produce a comprehensive and comprehensible model of a solution without making decisions about the organization of the software implementation. It is a highly abstract thinking tool to aid in the formalization of knowledge, a way of thinking about and describing the concepts that make up an abstract solution to a client problem."

"We build models to increase productivity, under the justified assumption that it's cheaper to manipulate the model than the real thing. Models then enable cheaper exploration and reasoning about some universe of discourse . One important application of models is to understand a real, abstract, or hypothetical problem domain that a computer system will reflect. This is done by abstraction, classification, and generalization of subject-matter entities into an appropriate set of classes and their behavior."

"MDA per se is relaxed about exactly what models it transforms, so long as the modeling language in which the models are expressed can be defined."

"In the bad old days before MDA, (conceptual) models served only to facilitate communication between customers and developers and act as blueprints for construction. Nowadays, MDA establishes the infrastructure for defining and executing transformations between models of various kinds."

"What's the point of having metamodels, and why should you care? Because models must be stated in a way that yields a common understanding among all involved parties, we need a way to specify exactly what a model means. Metamodels allow you to do just that: They specify the concepts of the language you're using to specify a model."

"What's really going on is that Executable UML is a concurrent specification language."

"Steve Mellor and I independently came up with a characterization of the three modes in which people use the UML: sketch, blueprint, and programming language. By far the most common of the three, at least to my biased eye, is UML as sketch. In this usage, developers use the UML to help communicate some aspects of a system. As with blueprints, you can use sketches in a forward-engineering or reverse-engineering direction. Forward engineering draws a UML diagram before you write code, while reverse engineering builds a UML diagram from existing code in order to help understand it."

"Steve Mellor has long been active in this kind of work and has recently used the term Executable UML [Mellor and Balcer]. Executable UML is similar to MDA but uses slightly different terms. Similarly, you begin with a platform-independent model that is equivalent to MDA's PIM. However, the next step is to use a Model Compiler to turn that UML model into a deployable system in a single step; hence, there's no need for the PSM. As the term compiler suggests, this step is completely automatic."

"The key books about object-oriented graphical modeling languages appeared between 1988 and 1992. Leading figures included Grady Booch [Booch,OOAD]; Peter Coad [Coad, OOA], [Coad, OOD]; Ivar Jacobson (Objectory) [Jacobson, OOSE]; Jim Odell [Odell]; Jim Rumbaugh (OMT) [Rumbaugh, insights], [Rumbaugh, OMT]; Sally Shlaer and Steve Mellor [Shlaer and Mellor, data], [Shlaer and Mellor, states] ; and Rebecca Wirfs-Brock (Responsibility Driven Design) [Wirfs-Brock]."

"A system composed of 100,000 lines of C++ is not be sneezed at, but we don't have that much trouble developing 100,000 lines of COBOL today. The real test of OOP will come when systems of 1 to 10 million lines of code are developed."

"Elements (lines of code) in a coincidentally-cohesive module have no relationship. Typically occurs as the result of modularizing existing code, to separate out redundant code."

"Designed as a companion volume to the acclaimed Object-Oriented Analysis, this book focuses on the middle part of the software lifecycle: the activity of design. It shows readers how to apply object-oriented design, and how to tailor and expand the method to suit specific organization and project needs. Readers will explore the major issues in OOD; the role of OOD in the systems lifecycle; how to use graphical notation; strategies for creating design; and hints for evaluating the efficiency of a design created with OOD. For software engineers and other users undertaking real-world systems development projects and designing overall software architecture for systems will find this reference approach to improving systems design indispensable."

"OOA - Object-Oriented Analysis - is based upon concepts that we first learned in kindergarten: objects and attributes, wholes and parts, classes and members."

"[Object-oriented analysis is] the challenge of understanding the problem domain and then the system's responsibilities in that light."

"To us, analysis is the study of a problem domain, leading to a specification of externally observable behavior; a complete, consistent, and feasible statement of what is needed; a coverage of both functional and quantified operational characteristics (e.g. reliability, availability, performance)."

"Subject. A Subject is a mechanism for guiding a reader (analyst, problem domain expert, manager, client) through a large, complex model. Subjects are also helpful for organizing work packages on larger projects, based upon initial OOA investigations."

"Systems engineering as an approach and methodology grew in response to the increase size and complexity of systems and projects... This engineering approach to the management of complexity by modularization was re-deployed in the software engineering discipline in the 1960s and 1970s with a proliferation of structured methodologies that enabled the the analysis, design and development of information systems by using techniques for modularized description, design and development of system components. Yourdon and DeMarco's Structured Analysis and Design, SSADM, James Martin's Information Engineering, and Jackson's Structured Design and Programming are examples from this era. They all exploited modularization to enable the parallel development of data, process, functionality and performance components of large software systems. The development of object orientation in the 1990s exploited modularization to develop reusable software. The idea was to develop modules that could be mixed and matched like Lego bricks to deliver to a variety of whole system specifications. The modularization and reusability principles have stood the test of time and are at the heart of modern software development."

"People also underestimate the time they spend debugging. They underestimate how much time they can spend chasing a long bug. With testing, I know straight away when I added a bug. That lets me fix the bug immediately before it can crawl off and hide. There are few things more frustrating or time-wasting than debugging. Wouldn't it be a hell of a lot quicker if we just didn't create the bugs in the first place?"

"Transparency is valuable, but while many things can be made transparent in distributed objects, performance isn't usually one of them."

"Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a 'refactoring') does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it's less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring."

"One of the things I've been trying to do is look for simpler or rules underpinning good or bad design. I think one of the most valuable rules is to avoid duplication. "Once and only once" is the Extreme Programming phrase."

"Often designers do complicated things that improve the capacity on a particular hardware platform when it might actually be cheaper to buy more hardware."

"Modeling Principle: Models are not right or wrong; they are more or less useful."

"It is commonly said that a pattern, however it is written, has four essential parts: a statement of the context where the pattern is useful, the problem that the pattern addresses, the forces that play in forming a solution, and the solution that resolves those forces. … it supports the definition of a pattern as "a solution to a problem in a context", a definition that [unfortunately] fixes the bounds of the pattern to a single problem-solution pair"

"The definition I use for a pattern is an idea that has been useful in one practical context and will probably be useful in others"

"The second problem [with using UML for the purposes of this book] is that the Unified Modeling Language concentrates on implementation modeling rather than conceptual modeling"

"When you find you have to add a feature to a program, and the program's code is not structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature."

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."

"Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing the observable behavior of the software. To refactor (verb): to restructure software by applying a series of refactorings without changing the observable behavior of the software."

"Often you'll see the same three or four data items together in lots of places: fields in a couple of classes, parameters in many method signatures. Bunches of data that hang around together really ought to be made into their own objects."

"When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous."

"The key is to test the areas that you are most worried about going wrong. That way you get the most benefit for your testing effort. It is better to write and run incomplete tests than not to run complete tests"

"Steve Mellor and I independently came up with a characterization of the three modes in which people use the UML: sketch, blueprint, and programming language. By far the most common of the three, at least to my biased eye, is UML as a sketch. In this usage, developers use the UML to help communicate some aspects of a system. As with blueprints, you can use sketches in a forward-engineering or reverse-engineering direction. Forward engineering draws a UML diagram before you write code, while reverse engineering builds a UML diagram from the existing code in order to help understand it."

"The key books about object-oriented graphical modeling languages appeared between 1988 and 1992. Leading figures included Grady Booch [Booch,OOAD]; Peter Coad [Coad, OOA], [Coad, OOD]; Ivar Jacobson (Objectory) [Jacobson, OOSE]; Jim Odell [Odell]; Jim Rumbaugh (OMT) [Rumbaugh, insights], [Rumbaugh, OMT]; Sally Shlaer and Steve Mellor [Shlaer and Mellor, data], [Shlaer and Mellor, states] ; and Rebecca Wirfs-Brock (Responsibility Driven Design) [Wirfs-Brock]."

"Graphical design notations have been with us for a while... their primary value is in communication and understanding. A good diagram can often help communicate ideas about design, particularly when you want to avoid a lot of details. Diagrams can also help you understand either a software system or a business process. As part of a team trying to figure out something, diagrams both help to understand and communicate that understanding throughout a team. Although they aren't, at least yet, a replacement for textual programming languages, they are a helpful assistant... Of these graphical notations, the UML's importance comes from its wide use and standardization within the OO development community."

"Comprehensiveness is the enemy of comprehensibility"

"The assertion that a problem unstated is a problem unsolved seem to have escaped many builders... All too often, design and implementation begins before the real needs and system functions are fully known. The results are skyrocketing costs, missed scheduled, waste and duplication, disgruntled users and endless series of patches and repairs euphemistically called "systems maintenance""

"This report summarizes the activities of the M.I.T. Computer-Aided Design (CAD) Project from 1 December 1959 through 3 May 1967 in the development of a generalized 'system of software systems' for generating specialized problem-solving systems using high-level language techniques and advanced computer graphics. Known as the AED Approach (for Automated Engineering Design) the Project results are applicable not only to mechanical design, as an extension of earlier development of the APT System for numerical control, but to arbitrary scientific, engineering, management, and production systems as well."

"There is a rigorous science, just waiting to be recognized and developed, which encompasses the whole of 'the software problem,' as defined, including the hardware, software, languages, devices, logic, data, knowledge, users, users, and effectiveness, etc. for end-users, providers, enablers, commissioners, and sponsors, alike."

"The objective of the Computer-Aided Design Project is to evolve a machine systems which will permit the human designer and the computer to work together on creative design problems."

"From the computer application point of view the primary problem [of Computer-Aided Design] is not how to solve problems, but how to state them."

"It is very difficult to define what is meant by computer-aided design since the complete definition is, in fact, the sum and substance of the total project effort which has only begun. It is much easier to describe, what is not computer-aided design as we mean it."

"Computer-aided design is not automatic design, although it must include many automatic design features. By automatic design we mean design procedures which are capable of being completely specified in a form which a computer can execute without human intervention."

"Computer-aided design also is not automatic programming, although automatic programming techniques must necessarily play an important role in computer-aided design."

"Automatic design has the computer do too much and the human do too little, whereas automatic programming has the human do too much and the computer do too little. Both techniques are important, but are not representative for what we wish to mean by computer-aided design."

"(SA) combines blueprint-like graphic language with the nouns and verbs of any other language to provide a hierarchic, top-down, gradual exposition of detail in the form of an SA model. The things and happenings of a subject are expressed in a data decomposition and an activity decomposition, both of which employ the same graphic building block, the SA box, to represent a part of a whole. SA arrows, representing input, output, control, and mechanism, express the relation of each part to the whole."

"Neither Watt's steam engine nor Whitney's standardized parts really started the Industrial Revolution, although each has been awarded that claim, in the past. The real start was the awakening of scientific and technological thoughts during the Renaissance, with the idea that the lawful behavior of nature can be understood, analyzed, and manipulated to accomplish useful ends. That idea itself, alone, was not enough, however, for not until the creation and evolution of blueprints was it possible to express exactly how power and parts were to be combined for each specific task at hand."

"Mechanical drawings and blueprints are not mere pictures, but a complete and rich language. In blueprint language, scientific, mathematical, and geometric formulations, notations, mensurations, and naming do not merely describe an object or process, they actually model it. Because of broad differences in subject, purpose, roles, and the needs of the people who use them, many forms of blueprint have evolved, but all rigorously present well structured information in understandable form."

"There are certain basic, known principles about how people's minds go about the business of understanding, and communicating understanding by means of language, which have been known and used for many centuries. No matter how these principles are addressed, they always end up with hierarchic decomposition as being the heart of good storytelling. Perhaps the most relevant formulation is the familiar: "Tell 'em whatcha gonna tell'em. Tell 'em. Tell 'em whatcha told 'em." This is a pattern of communication almost as universal and well-entrenched as Newton's laws of motion."

"The natural law of good communications takes the following, quite different, form in SA:"

"We never have any understanding of any subject matter except in terms of our own mental constructs of "things" and "happenings" of that subject matter."

"I was sort of a hellraiser with a bunch of friends, most of whom were squeaking by with C's and D's while I was getting an A-average and should have been doing better. I did a lot of things on my own. I liked to make things with my hands. There was a lot of woodworking, model building, and model railroading. I collected stamps, and did various things in chemistry. I used to make things that exploded, and all that sort of thing. So I evidently got quite a good background in science. I always had a knack for that sort of thing. The hospital had a subscription to Scientific American and Science. So things came every week and I consumed them..."

"I realized after I'd been at MIT for a while that I had never even known the semantics of the word "engineering". You see, all my relatives and contacts were medical doctors or biology and chemistry professors. In fact, I'm almost the "black sheep" in the family for not being an MD or Ph.D. because everybody was doing that sort of thing. There was no contact at all with engineering. I didn't even know what the word meant..."

"With all this science and physics and so forth that I absorbed. I did have one early experience with engineering, however. When we got the Book of Knowledge, I found on one page a diagram for a short-wave radio. I thought it would be neat to try to make a shortwave radio, so I arranged with all the radio repairmen in the town that whenever they were going to junk a radio, they should set it aside and I would pick it up. I got all these old radios -- really classics now -- that I stripped. I had huge transformers and loudspeakers and huge condensers -- the whole works. Boxes full of this stuff. I didn't understand it. I didn't know a thing about it. I just liked to take things apart and learn how to solder. I discovered out of my collection of parts -- with the tuning condensers (with movable plates), the knobs, and all that stuff, that I had what seemed to be needed in this one page diagram of a shortwave receiver."

"I just looked in the phone book, and called up the Executive Officer of the Servomechanisms Laboratory (Al Sise) and said, "I'm a math graduate student and would like a summer job. If you could find an electrical engineering student, I'm sure by the end of the summer we could make you an electronic calculator that would beat the pants off that little mechanical thing that Wiener has put together. Are you interested?""

"A lot of people are not familiar with the fact that when Lincoln Lab grew out of the Project Whirlwind (which were just names to me at that point) for the purpose of looking into radar air defense -- processing radar signals with the computer and then using radio controls to defend with fighters and so forth -- Whirlwind had been originally designed as an aircraft simulator for individual airplanes."

"The first paper I ever wrote was "Gestalt Programming" and that was in 1955. The whole idea there was to replace the laborious writing out of detailed programs and all those steps by having analyzed a problem area well enough so that you had what I later came to call a "systematized solution." Then you could compose different problems of this class by just plugging together pieces of program, and they would in turn be controlled by a pushbutton language. The user would make a number of discreet selections. It's just like nowadays it's done with menus, and when you had indicated all the pieces that you wanted to put together--by these mnemonic names and words for things associated with buttons, switches, with one meaning "period," essentially, for that sentence, you see--all these things would be brought together and that would be the man/machine, manual-intervention mode of problem-solving. I took over the term from studying Gestalt psychology, meaning that everything was brought together at once, as a unit, instead of this laborious step-by-step build-up."

"The artificial intelligence people, the artificial intelligencia,... kept choosing little games to play, and little things that they could master, right? But my whole philosophy has always been give me a really tough problem that's just beyond the state-of-the-art, and give me a whole bunch of users beating on me to get it done. In other words, the real core of what being an engineer is."

"The real core of what being an engineer is. You have a scientific basis, but when you don't have the science, you put in some bugger factors, some safety factors, and so forth and you get smart enough, and you get the job done anyhow, right? Economically, and as close to on time as you can make it. And if the customer is asking for something that's outlandish, give him what you can, and educate him back to what it is."

"I introduced what I called "outside-in problem solving," which nowadays is called "top-clown." But I prefer outside-in because outside-in allows you to have many different viewpoints instead of a single top that you stupidly try to get to the bottom of, and things of that sort. came out of that."

"The APT and CAD Projects had one Air Force sponsorship, but it was actually a combination of about five or six projects, all going in parallel on both hardware and software matters, and I couldn't keep track of things, so I would take Polaroid pictures of the blackboard and then say what we had talked about into my dictating machine and my secretary would type it up."

"A general theme for what I'm trying to convey and what actually drove me and my very industrious and creative project members over all these years, is... that there is much more to it than pictures. It has to be a picture language. There has to be meaning there, and the meaning is useful. You're trying to solve problems. So it really comes down to man machine problem solving . Better means of communication and expression is what always has driven our work."

"Even though we started in the days when the equipment itself wasn't able to do very exciting visual things, we were always concentrating on this matter of communication and meaning."

"Douglas T. Ross, who began his career as a graduate student in math at MIT where he was quickly lured into computing, serving as head of the Computer Applications Group from 1952 to 1969, when he left MIT to form SofTech, Inc., which he served as president until 1975 and since then as chairman. He's made seminal contributions to several areas of computing, ranging from automatic programming of numerically controlled tools, the computer language APT, through Computer Aided Design, his Automated Engineering Design System, down to software engineering, the method of structured analysis design technique, which he puts generally under the heading of man machine collaboration. He's an old hand at historical gatherings, having reported on APT at the conference on the History of Programming Languages held in 1978, and more recently on the early development in the History of Personal Workstations in 1986."

"As Head of the Computer Application Group at the MIT Electronic Systems Laboratory, Doug led the development of the (APT), a special purpose programming language that became the world standard for programming computer-controlled machine tools. He then turned his attention to the development of a and supporting tools. This led to the development while at MIT of the first software engineering language and supporting tools, the AED system. In 1969 Doug founded where he continued to work on software engineering standards. While at SofTech, Doug conceived of SA, a graphic notation and methodology for system description. SA has been successfully applied worldwide as SofTechs (SADT) or as the U.S. government standard ."

"In his article “CAD: A Statement of Objectives”, published in. 1960, Ross, who was thirty years old then, defined not only the term CAD, but also the principles, goals and visions of Computer Aided Design. His ideas shaped all the further CAD development in the past 50 years."

"For me, he has been an important pioneer in crucial areas throughout his career. Here are two examples:"

"A real-time computer system may be defined as one which controls an environment by receiving data, processing them, and taking action or returning results sufficiently quickly to affect the functioning of the environment at that time."

"As technology grows in power, its ability either to disrupt or to heal increases. We can destroy the planet more easily than we can heal the harm we have done so far. To heal, we have to move to new technologies, new social patterns, new types of consumer products, new ways of generating and spending wealth. Such changes will inevitably occur, whether they are brought by healing forethought or mindless destruction. The future will not be a repetition of the past."

"From a very early age, we form concepts. Each concept is a particular idea or understanding we have about our world. These concepts allow us to make sense of and reason about the things in our world. These things to which our concepts apply are called objects."

"Information engineering has been defined with the reference to automated techniques as follows: An interlocking set of automated techniques in which enterprise models, data models and process models are built up in a comprehensive knowledge-base and are used to create and maintain data-processing systems."

"Information Engineering is the application of an interlocking set of formal techniques for the planning, analysis, design, and construction of information systems on the enterprise wide basis or across a major sector of the enterprise."

"Enterprise Engineering is not a single methodology, but a sophisticated synthesis of the most important and successful of today's change methods. "Enterprise Engineering" first explains in detail all the critical disciplines (including continuous improvement, radical reinvention of business processes, enterprise redesign, and strategic visioning). It then illustrates how to custom-design the right combination of these change methods for your organization's specific needs."

"A new type of professional is emerging – the enterprise engineer"

"Enterprise engineering is an integrated set of disciplines for building an enterprise, its processes, and systems."

"A horrifying amount of "business engineering" is done with the wrong strategic vision. A horrifying amount of IT development is done with the wrong business design."

"Dr James Martin, entrepreneur, visionary, "guru of the information age", "father of Case", ranked fourth in the world by Computerworld among the most influential people in the computer industry, Martin is not only a distinguished technology expert, but also a leading business authority, generally acknowledged as THE specialist on the social and business implications of computers and technology."

"Systems engineering as an approach and methodology grew in response to the increase size and complexity of systems and projects... This engineering approach to the management of complexity by modularization was re-deployed in the software engineering discipline in the 1960s and 1970s with a proliferation of structured methodologies that enabled the the analysis, design and development of information systems by using techniques for modularized description, design and development of system components. Yourdon and DeMarco's Structured Analysis and Design, SSADM, James Martin's Information Engineering, and Jackson's Structured Design and Programming are examples from this era. They all exploited modularization to enable the parallel development of data, process, functionality and performance components of large software systems. The development of object orientation in the 1990s exploited modularization to develop reusable software. The idea was to develop modules that could be mixed and matched like Lego bricks to deliver to a variety of whole system specifications. The modularization and reusability principles have stood the test of time and are at the heart of modern software development."

"The term architecture is used here to describe the attributes of a system as seen by the programmer, i.e., the conceptual structure and functional behavior, as distinct from the organization of the data flow and controls, the logical design, and the physical implementation. i. Additional details concerning the architecture,"

"[The architecture specification covers] all functions of the machine that are observable by the program."

"The architecture of a system can be defined as the functional appearance of the system to the user."

"The purpose of the Committee was to study and report upon the desirability and characteristics of another computer system based on Stretch technology but having a lower cost and broader market than the 7000 Sigma system. The Committee was instructed to keep an open mind in initially examining various machine possibilities both from the engineering and marketing points of view..."

"A study of the high-speed computer market with the intention of specifying a new computer brings forth a number of interesting observations... [An] striking feature of the market is that we seem to be close to satisfying the need for present-day uses of computers, but are standing on the threshold of a vast new area of applications. This new area can be characterized by the phrase computers which interact with the outside world. This concept is called "Integrated Data Processing", "Real-Time. Operation", "Process Control", "In-Line Operation", etc, Its characteristic feature is the ability of the computer to accept and send information directly to other devices. The use of computers in this fashion is being developed in the aircraft and missile industries . It is important to note that both scientific and commercial applications are going in this direction."

"Scientific customers are traditionally less worried about reprogramming efforts than commercial customers, since many jobs are of a research nature and will be done over from time to time anyway. This is obviously true of many small and 'lone shot" problems. In practice, however, there are many more machine hours spent on production-type scientific problems than on those of research-type at most scientific computing installations. These production problems can be as rigid and static as any commercial job. The scientists responsible for production work will complain about reprogramming just as violently as an accountant will under the same circumstances."

"In computer design three levels can be distinguished: architecture, implementation and realisation; for the first of them, the following working definition is given: The architecture of a system can be defined as the functional appearance of the system to the user, its phenomenology."

"The result of the implementation, the logical design, is traditionally shown as a series of block diagrams. These blocks represent in effect a series of statements, Actually, a direct presentation of these statements is more suitable and, although less familiar, more easily understood. The Harvard Mark IV was to large degree designed and described by such statements, as has been the case with several subsequent developments."

"There always is an architecture, whether it is defined in advance - as with modern computers - or found out after the fact - as with many older computers. For architecture is determined by behavior, not by words. Therefore, the term architecture, which rightly implies the notion of the arch, or prime structure, should not be understood as the vague overall idea. Rather, the product of the computer architecture, the principle of operations manual, should contain all detail which the user can know, and sooner or later is bound to know."

"The design of a digital system starts with the specification of the architecture of the system and continues with its implementation and its subsequent realisation... the purpose of architecture is to provide a function. Once that function is established, the purpose of implementation is to give a proper cost-performance and the purpose of realisation is to build and maintain the appropriate logical organisation."

"By architecture I mean 'appearance to the user' - it is the functional specification of the system (its behavioural appearance). By implementation I mean 'internal logical organisation which performs the functions specified by the architecture' and by realisation I mean 'the physical components in which the logical organisation is embodied'."

"A hardware design language should be (i) sufficiently high level, (ii) conversational, (iii) general purpose, and (iv) structured:"

"In this remarkable book on computer design, long-known in the field and widely used in manuscript form, Gerrit A. Blaauw and Frederick P. Brooks, Jr. provide a definitive guide and reference for practicing computer architects and for students. The book complements Brooks' recently updated classic, The Mythical Man-Month, focusing here on the design of "hardware" and there on "software," here on the "content" of computer architecture and there on the "process" of architecture design. The book's focus on "architecture" issues complements Blaauw's early work on "implementation" techniques. Having experienced most of the computer age, the authors draw heavily on their first-hand knowledge, emphasizing timeless insights and observations."

"Blaauw and Brooks first develop a conceptual framework for understanding computer architecture. They then describe not only what present architectural practice is, but how it came to be so. A major theme is the early divergence and the later reconvergence of computer architectures. They examine both innovations that survived and became part of the standard computer, and the many ideas that were explored in real machines but did not survive. In describing the discards, they also address "why" these ideas did not make it"

"As usual the audience consisted mainly of professors of computing science; this time the speakers were mainly specialists in logic design: for many in the audience the exposure was a shock. At the level of component technology the change over the last fifteen years has been drastic: what used to be expressed in milliseconds is expressed in microseconds now, what used to be expressed in kilobucks is now expressed in dimes and quarters. This change has been so drastic that it is well-known. Much less known is that at the next levels, viz. of circuit design and logic design, the attention of the designers has been so fully usurped by the obligation to adapt to the ever changing technology, that at those levels design methodology has had no chance to mature from craft to scientific discipline. This is in sharp contrast to the developments in programming methodology, where during that period of fifteen years a fairly stable "base" could be enjoyed. Having witnessed that development in programming methodology at close quarters, I was overcome by the feeling of being exposed to the result of fifteen years of intellectual stagnation, and it was during Blaauw's lecture on the first afternoon that I asked my right-hand neighbour "Close your eyes, forget how you came here and guess in which year you are living."; without hesitation he came up with exactly the same year I had in mind: 1962."

"The term Computer Architecture was first defined in the paper by Amdahl, Blaauw and Brooks of International Business Machines (IBM) Corporation announcing IBM System/360 computer family on April 7, 1964. On that day IBM Corporation introduced, in the words of IBM spokesman, "the most important product announcement that this corporation has made in its history"."

"Practical knowledge of modularity has come largely from the computer industry. The term architecture was first used in connection with computers by the designers of the System/360: Gene M. Amdahl, Gerrit A. Blaauw, and Frederick P. Brooks."

"Blaauw... joined the IBM research lab at Poughkeepsie, New York, USA. During this period Blaauw became famous for his methodological manner of building computer machines. He made a difference between architecture, implementation and realization of a machine. After a couple of years working on some different machines, one of the most famous machines built by Frederick Brooks, Gerrit Blaauw and Gene Amdahl was the IBM System/360, which was introduced in 1964. IBM Board Chairman Thomas Watson, Jr. called the event the most important product announcement in the company's history."

"Poor management can increase software costs more rapidly than any other factor. Particularly on large projects, each of the following mismanagement actions has often been responsible for doubling software development costs."

"Software Engineering Economics is an invaluable guide to determining software costs, applying the fundamental concepts of microeconomics to software engineering, and utilizing economic analysis in software engineering decision making."

"If a project has not achieved a system architecture, including its rationale, the project should not proceed to full-scale system development. Specifying the architecture as a deliverable enables its use throughout the development and maintenance process."

"What we see in both software development and military operations is a tendency for the pendulum to swing back and forth between extremes. Yet in most cases, we need a balance between armor and discipline and between mobility and agility. Actually, though, I would say that the leaders in both the agile and plan-driven camps occupy various places in the responsible middle. It’s only the over-enthusiastic followers who overinterpret “discipline” and “agility” to unhealthy degrees."

"Agile development methodologies promise higher customer satisfaction, lower defect rates, faster development times and a solution to rapidly changing requirements. Plan-driven approaches promise predictability, stability, and high assurance. However, both approaches have shortcomings that, if left unaddressed, can lead to project failure. The challenge is to balance the two approaches to take advantage of their strengths and compensate for their weaknesses."

"The dictionary defines "economics" as "a social science concerned chiefly with description and analysis of the production, distribution, and consumption of goods and services." Here is another definition of economics which I think is more helpful in explaining how economics relates to software engineering."

"If we look at the discipline of software engineering, we see that the microeconomics branch of economics deals more with the types of decisions we need to make as software engineers or managers."

"Throughout the software life cycle, there are many decision situations involving limited resources in which software engineering economics techniques provide useful assistance."

"Economic principles underlie the overall structure of the software lifecycle, and its primary refinements of prototyping, incremental development, and advancemanship. The primary economic driver of the life-cycle structure is the significantly increasing cost of making a software change or fixing a software problem, as a function of the phase in which the change or fix is made."

"“Stop the life cycle-I want to get off!”"

"The spiral model presented in this article is one candidate for improving the software process model situation. The major distinguishing feature of the spiral model is that it creates a risk-driven approach to the software process rather than a primarily document-driven or code-driven process. It incorporates many of the strengths of other models and resolves many of their difficulties."

"The Code-and-Fix Model. The basic model used in the earliest days of software development contained two steps:"

"The stagewise and waterfall models. As early as 1956, experience on large software systems such as the Semi-Automated Ground Environment (SAGE) had led to the recognition of these problems and to the development of a stagewise model to address them."

"Like many fields in their early stages, the software field has had its share of project disasters: the software equivalents of Beauvais Cathedral, the S.S. Titanic, and the "Galloping Gertie" Tacoma Narrows Bridge. The frequency of these disaster projects is a serious concern: a recent survey of 600 firms indicated that 35% of them had at least one "runaway' software project."

"Most post-mortems of these software disaster projects have indicated that their problems would have been avoided or strongly reduced if there had been an explicit early concern with identifying and resolving their high-risk elements. Frequently, these projects were swept along by a tide of optimistic enthusiasm during their early phases, which caused them to miss some clear signals of high risk issues which proved to be the project's downfall later. Enthusiasm for new software capabilities is a good thing. But it needs to be tempered with a concern for early identification and resolution of a project's high-risk elements, so that people can get these resolved early and then focus their enthusiasm and energy on the positive aspects of their software product."

"Success in all types of organization depends increasingly on the development of customized software solutions, yet more than half of software projects now in the works will exceed both their schedules and their budgets by more than 50%."

"A development method may be regarded as a path or a procedure by which the developer proceeds from a problem of a certain class to a solution of a certain class. In trivial cases, the method may be fully algorithmic; for example, there is an algorithmic procedure for obtaining the square root of a nonnegative number to any desired degree of accuracy."

"My first serious programming work was done in the very early 1960s, in Assembler languages on IBM and Honeywell machines. Although I was a careful designer — drawing meticulous flowcharts before coding — and a conscientious tester, I realised that program design was hard and the results likely to be erroneous. Into the Honeywell programs, which formed a little system for an extremely complex payroll, I wrote some assertions, with run-time tests that halted program execution during production runs. Time constraints didn't allow restarting a run from the beginning of the tape. So for the first few weeks I had the frightening task on several payroll runs of repairing an erroneous program at the operator’s keyboard ¾ correcting an error in the suspended program text, adjusting the local state of the program, and sometimes modifying the current and previous tape records before resuming execution. On the Honeywell 400, all this could be done directly from the console typewriter. After several weeks without halts, there seemed to be no more errors. Before leaving the organisation, I replaced the run-time halts by brief diagnostic messages: not because I was sure all the errors had been found, but simply because there would be no-one to handle a halt if one occurred. An uncorrected error might be repaired by clerical adjustments; a halt in a production run would certainly be disastrous."

"After forty years of currency the phrase "software engineering" still denotes no more then a vague and largely unfulfilled aspiration."

"One of the difficulties in thinking about software is its huge variety. A function definition in a spreadsheet cell is software. A smartphone app is software. The flight management system for an Airbus A380 is software. A word processor is software. We shouldn't expect a single discipline of software engineering to cover all of these, any more than we expect a single discipline of manufacturing to cover everything from the Airbus A380 to the production of chocolate bars, or a single discipline of social organization to cover everything from the United Nations to a kindergarten. Improvement in software engineering must come bottom-up, from intense specialized attention to particular products."

"The beginning of wisdom for a programmer is to recognize the difference between getting his program to work and getting it right. A program which does not work is undoubtedly wrong; but a program which does work is not necessarily right. It may still be wrong because it is hard to understand; or because it is hard to maintain as the problem requirements change; or because its structure is different from the structure of the problem; or because we cannot be sure that it does indeed work."

"We follow two rules in the matter of optimization:"

"Jackson System Development (JSD) and Object-Oriented Design (OOD) have one major - arguably central - principle in common; namely that the key to software quality lies in the structuring of the solution to a problem in such a way as to reflect the structure of the problem itself. There should be a simple and demonstrable correspondence between a (real world) component of the problem and a (software) component of the solution. The two methods also use similar concepts to describe the problem domain (or 'real world'). It is considered to consist of identifiable objects ('entities' in JSD) and operations that are either performed or suffered by these objects ('actions' in JSD}."

"Systems engineering as an approach and methodology grew in response to the increase size and complexity of systems and projects. It "recognizes each system is an integrated whole even though composed of diverse, specialized structures and sub-functions..." (Chestnut, 1965) This engineering approach to the management of complexity by modularization was re-deployed in the software engineering discipline in the 1960s and 1970s with a proliferation of structured methodologies that enabled the the analysis, design and development of information systems by using techniques for modularized description, design and development of system components. Yourdon and DeMarco's Structured Analysis and Design, SSADM, James Martin's Information Engineering, and Jackson's Structured Design and Programming are examples from this era. They all exploited modularization to enable the parallel development of data, process, functionality and performance components of large software systems. The development of object orientation in the 1990s exploited modularization to develop reusable software. The idea was to develop modules that could be mixed and matched like Lego bricks to deliver to a variety of whole system specifications. The modularization and reusability principles have stood the test of time and are at the heart of modern software development."

"Today some evidence arises that UML will more and more be used not as a but as a high level programming language. This has some advantages, as if the concepts of UML are executable, they can immediately be animated and tested, or the generated code even be used as implementation. Thus UML probably will have an implementation-oriented semantics describing this animation."

"Originally UML was intended to serve as a . But a specification is primarily intended to describe properties of systems that the system developers want to be valid, but to leave open other properties that are not clear already. Today this is partly achieved by having a semantics that is rather vague (and here we mean imprecise as opposed to not detailed). However, this is not an advantage, as the developer cannot fix this kind of impreciseness within UML, but can adapt the individual interpretation only. Furthermore, to get complete (and therefore executable) UML descriptions, often certain details have to be specified, which the developer does not yet know or wants to leave open to a later phase of development or even implementation. It is an intrinsic problem of executable languages that this kind of over-specification frequently occurs. Instead it would be of some help to have flexible concepts of under-specification to postpone detail decisions to situations, where the decisions can and must be made."

"Extreme Programming is the most prominent new, light-weight (or agile) methods, defined to contrast the current heavy-weight and partially overloaded object-oriented methods. It focuses on the core issues of software technology. One of its principles is not to rely on diagrams to document a system."

"In all engineering disciplines nowadays, software engineering excluded, there exists an established engineering process to develop a system, which is accompanied by a number of suited modeling description techniques. Software engineering, being a rather new field, has not as yet established any clear methodical guidance or a fully standardized modeling notation."

"One of the distinct features of XP is the lack of any documentation whatsoever, except for the code itself. This is a contraposition to the modeling techniques like the Unified Modeling Language (UML), which strongly focus on documentation. XP takes an extreme position there, not even documenting the architecture of the system. Often, it is very difficult to extract the overall structure, behavior or interactions with the environment from the code. The code is a rather detailed and fragile representation of the system’s tasks. Even though the code contains all necessary information about the system, this information is often burdened with details and it is tedious to extract the aspects one is interested in. Therefore, it would be useful to have a more compact system representation. The UML does provide a number of notations that are suited for this purpose. However, the tools so far are not capable of supporting UML in such a manner that it can be well-integrated with the approach of Extreme Programming."

"The term (MDE) is typically used to describe software development approaches in which abstract models of software systems are created and systematically transformed to concrete implementations.... Full realizations of the MDE vision may not be possible in the near to medium-term primarily because of the wicked problems involved. On the other hand, attempting to realize the vision will provide insights that can be used to significantly reduce the gap between evolving software complexity and the technologies used to manage complexity."

"Advances in hardware and network technologies have paved the way for the development of increasingly pervasive software-based that collaborate to provide essential services to society. Software in these systems is often required to (1) operate in distributed and embedded computing environments consisting of diverse devices (personal computers, specialized sensors and actuators), (2) communicate using a variety of interaction paradigms (e.g., SOAP messaging, media streaming), (3) dynamically adapt to changes in operating environments, and (4) behave in a dependable manner. Despite significant advances in programming languages and supporting integrated development environments (IDEs), developing these complex software systems using current code-centric technologies requires herculean effort."

"The growing complexity of software is the motivation behind work on industrializing software development. In particular, current research in the area of (MDE) is primarily concerned with reducing the gap between problem and software implementation domains through the use of technologies that support systematic transformation of problem-level abstractions to software implementations. The complexity of bridging the gap is tackled through the use of models that describe complex systems at multiple levels of abstraction and from a variety of perspectives, and through automated support for transforming and analyzing models. In the MDE vision of software development, models are the primary artifacts of development and developers rely on computer-based technologies to transform models to running systems."

"Bernhard Rumpe is chair of the Institute for Software Systems Engineering at the Braunschweig University of Technology, Germany. His main interests are software development methods and techniques that benefit form both rigorous and practical approaches. This includes the impact of new technologies such as model-engineering based on UML-like notations and domain specific languages and evolutionary, test-based methods, software architecture as well as the methodical and technical implications of their use in industry. He has furthermore contributed to the communities of formal methods and UML. He is author and editor of eight books and Co-Editor-in-Chief of the Springer International Journal on Software and Systems Modeling."

"The (UML) is a general-purpose visual modeling language that is used to specify, visualize, construct, and document the artifacts of a software system. It captures decisions and understanding about systems that must be constructed. It is used to understand, design, browse, configure, maintain, and control information about such systems. It is intended for use with all development methods, lifecycle stages, application domains, and media. The modeling language is intended to unify past experience about modeling techniques and to incorporate current software best practices into a standard approach. UML includes semantic concepts, notation, and guidelines. It has static, dynamic, environmental, and organizational parts. It is intended to be supported by interactive visual modeling tools that have code generators and report writers. The UML specification does not define a standard process but is intended to be useful with an iterative development process. It is intended to support most existing object-oriented development processes."

"People regard their environment in terms of objects. Therefore it is simple to think in the same way when it comes to designing a model."

"When a user uses the system, she or he will perform a behaviorally related sequence of transactions in a dialogue with the system. We call such a special sequence a use case."

"The control objects model functionality that is not naturally tied to any other object... We do not believe that the best (most stable) systems are built by only using objects that correspond to real-life entities, something that many other object-oriented analysis and design techniques claim... Behavior that we place in control objects will, in other methods, be distributed over several other objects, making it hard to change this behavior."

"A is a complete course of events in the system, seen from a user’s perspective."

"The analysis model will not be a reflection of what the problem domain looks like... The reason is simply to get a more maintainable structure where changes will be local and thus manageable. We thus do not model reality as it is, as object orientation is often said to do, but we model the reality as we want to see it and to highlight what is important in our application."

"The key books about object-oriented graphical modeling languages appeared between 1988 and 1992. Leading figures included Grady Booch [Booch,OOAD]; Peter Coad [Coad, OOA], [Coad, OOD]; Ivar Jacobson (Objectory) [Jacobson, OOSE]; Jim Odell [Odell]; Jim Rumbaugh (OMT) [Rumbaugh, insights], [Rumbaugh, OMT]; Sally Shlaer and Steve Mellor [Shlaer and Mellor, data], [Shlaer and Mellor, states] ; and Rebecca Wirfs-Brock (Responsibility Driven Design) [Wirfs-Brock]."

"The software architecture of a system or a family of systems has one of the most significant impacts on the quality of an organization's enterprise architecture. While the design of software systems concentrates on satisfying the functional requirements for a system, the design of the software architecture for systems concentrates on the nonfunctional or quality requirements for systems. These quality requirements are concerns at the enterprise level. The better an organization specifies and characterizes the software architecture for its systems, the better it can characterize and manage its enterprise architecture. By explicitly defining the systems software architectures, an organization will be better able to reflect the priorities and trade-offs that are important to the organization in the software that it builds."

"Ever wish you could draw a few diagrams, press a button, and have a working software system that meets your needs? Sound like magic? Perhaps, but that’s a major part of the Executable UML vision. The basic idea is that you will use a CASE tool to develop detailed UML diagrams and then supplement them by specifications written in a formal language, presumably the OMG’s Object Constraint Language (OCL). The basic idea behind Executable UML is that systems can be modeled at a higher level of abstraction than source code, simulated to support validation of your efforts, and then translated into efficient code. This higher-level of abstraction should help to avoid premature design, enable you to change your system as your requirements evolve, and to delay implementation decisions until the last minute."

"In my opinion this sounds great in theory, but unfortunately there are several problems to making this work in practice:"

":I have no doubt that we will begin to see some interesting tools emerge over the next few years based on the Executable UML vision."

"Enterprise Engineering is based on the belief that an enterprise, as any other complex system can be designed or improved in an orderly fashion thus giving a better overall result than ad hoc organisation and design."

"The is about those methods, models and tools which are needed to build the integrated enterprise. The architecture is generic because it applies to most, potentially all types of enterprise. The coverage of the framework spans Products, Enterprises, Enterprise Integration and Strategic Enterprise Management, with the emphasis being on the middle two. The proposal for the architecture follows the architecture itself improving the quality of the presentation and of the outcome. De nitions of Generic Enterprise Reference Architecture, Enterprise Engineering/ Integration Methodology, Enterprise Modelling Languages, Enterprise Models, and Enterprise Modules are given. It is proposed how the above could be developed on the basis of previously analysed architectures (and other results too), such as the , the GRAI Integrated Methodology, , and TOVIE."

"provides a Reference Architecture (known as the CIMOSA cube) from which particular enterprise architectures can be derived. This Reference Architecture and the associated enterprise modelling framework are based on a set of modelling constructs, or generic building blocks, which altogether form the CIMOSA modelling languages."

"Enterprise architecture (EA) promotes the belief that an enterprise, as a complex system, can be designed or improved in an orderly fashion achieving better overall results than ad-hoc organisation and design. EA is a co-operative effort of designers, analysts and managers and uses enterprise models in the process... enterprise models carry meaning. This resulted in requirements for the enterprise engineering process, which—if not met—can limit the viability of the process. The analysis of the same factors resulted in requirements for improved Enterprise Modelling Tools."

"Enterprise Engineering is the collection of those tools and methods which one can use to design and continually maintain an enterprise."

"Innovative e-business projects start with a design of the e-business model. We often encounter the view, in research as well as industry practice, that an e-business model is similar to a business process model, and so can be specified using UML activity diagrams or Petri nets. In this paper, we explain why this is a misunderstanding. The root cause is that a business model is not about process but about value exchanged between actors. Failure to make this separation of concerns leads to poor business decision-making and inadequate business requirements."

"Computer science is still a young field. The first computers were built in the mid 1940s, since when the field has developed tremendously. Applications from the early years of computerization can be characterized as follows: the programs were quite small, certainly when compared to those that are currently being constructed; they were written by one person; they were written and used by experts in the application area concerned. The problems to be solved were mostly of a technical nature, and the emphasis was on expressing known algorithms efficiently in some programming language. Input typically consisted of numerical data, read from such media as punched tape or punched cards. The output, also numeric, was printed on paper. Programs were run off-line. If the program contained errors, the programmer studied an octal or hexadecimal dump of memory. Sometimes, the execution of the program would be followed by binary reading machine registers at the console."

"Present-day applications are rather different in many respects. Present-day programs are often very large and are being developed by teams that collaborate over periods spanning several years. These teams may be scattered across the globe. The programmers are not the future users of the system they develop and they have no expert knowledge of the application area in question. The problems that are being tackled increasingly concern everyday life: automatic bank tellers, airline reservation, salary administration, electronic commerce, automotive systems, etc. Putting a man on the moon was not conceivable without computers."

"Software engineering concerns methods and techniques to develop large software systems. The engineering metaphor is used to emphasize a systematic approach to develop systems that satisfy organizational requirements and constraints."

"Almost 2000 years ago, the Roman architect Vitruvius recorded what makes a design good: durability (firmitas), utility (utilitas), and charm (venustas). These quality requirements still hold, for buildings as well as software systems. A well-designed system is easy to implement, is understandable and reliable, and allows for smooth evolution. Badly-designed systems may work at first, but they are hard to maintain, difficult to test, and unreliable."

"As a child, I witnessed a great deal of violence and persecution as well as social unrest during The Cultural Revolution...This experience has made me understand the complexity of human nature and society—I’ve realized that the future of human civilization is also full of danger and uncertainty. Such understanding is manifested in my science fiction novels…"

"The world described by modern physics has already moved far beyond our common sense and intuition, even beyond our imagination, and this is, of course, the richest resource for science fiction. I’ve tried to turn the magical world as demonstrated by modern physics into vivid stories. Most of my stories were based on and imagined along the lines of physics and cosmology."

"As to the future of humanity, I’m essentially an optimist. I believe that with the advancement of technology, mankind has a hopeful future. But this optimistic view is based on reason: on one hand, whether the future will be bright or be dark depends largely on the choices we make today."

"Contemporary China is a complex society in transition. The kinds of technological and social changes that took societies in the west centuries to move through have sometimes been experienced by a mere two generations in China. The anxiety of careening out of balance, of being torn by parts moving too fast and too slow, is felt everywhere."

"The glories and obstacles of the past are just a speck compared to the vastness of the future."

"Nostalgia ages people, but science fiction is a literature of youth. Its spirit is the youthful yearning for new worlds, and new ways of living. Mainstream literature is like Chinese baijiu, tasting better as it ages; science fiction, on the other hand, is like tap beer—you’ve got to drink it quick. Read today, even the sci-fi classics seem feeble, not revelatory. The nature of science fiction is to shine brightest in the present, then to be quickly forgotten. But science fiction shouldn’t be afraid of obsolescence. As a literature of innovation, it uses a constant stream of inventions and shocks to hold back obsolescence, like an everlasting fire. Just as ash falls, the flame springs back to life, emitting dazzling light. To accomplish this, it must hold on to its usefulness."

"In the remote future, when people remember the history of the mid-twentieth century to the present, all of the great events that seemed so momentous in this period will be milled away, leaving little trace, and only two things that we have overlooked will be seen as more and more important: first, humanity took its first step outside the cradle, and second, humanity then took a step backward. The importance of these two events cannot be overestimated."

"In technological terms, space voyages and environmental protections seem different in character, with the former being intense, high speed, and adventurous, with connotations of state-of-the-art technology, while the latter is a gentle green public-service activity, one which, though involving technology, doesn’t give the impression of being as difficult as the former. But that is only an impression. The true situation is: If we want to achieve the present targets for environmental protection, the technology needed is more difficult to develop than that for large-scale interplanetary travel."

"Of all the unexpected things that might interrupt Chinese science fiction’s development, social unrest has to be the most worrying. I once told readers at a conference that science fiction is the product of leisurely and carefree minds. No one agreed, but I was telling the truth. Only when our lives are stable and quiet can we allow the universe’s catastrophes to fascinate and awe us. If we already live in an environment full of danger, then science fiction won’t interest us. In fact, two of the last three bursts of creative progress that Chinese science fiction underwent were cut short by social unrest, which is lethal to the genre."

"The world of fantasy and myth isn’t really that large. The universe, as depicted in Eastern and Western mythology alike, is hardly ever larger than two astronomical units in radius. The notion of a light-year could never have made it into a myth because such a scale is beyond the capacity of the mythological imagination. The most magnificent deities of the world of magic are dwarfed by the stars of the world of sci-fi, and its most terrible demons pale in comparison to the sci-fi world’s black holes."

"The truth is that sci-fi and fantasy have many more similarities than differences. They have the same goal: both strive to create ethereal, free worlds of the imagination from which readers can derive the shocks and delights of beauty. (Personally, I’ve never thought it’s sci-fi’s job to represent reality or human nature.) The only difference between the two is the source of their imaginings."

"Fantasy has been around since antiquity, and there’s been so much of it. The years have taken their toll and depleted some of its imaginative power. The rapid progress of science, on the other hand, constantly infuses fresh blood into the science-fictional imagination. The worlds described in today’s sci-fi are entirely different from those of a few decades ago, whereas today’s fantasy worlds aren’t so different from those of the Middle Ages."

"We tend to imagine that readers of fantasy recognize that what they’re reading is make-believe, which is certainly true today, but wasn’t necessarily so in ancient times. People of ages past regarded fantasies and myths as nothing less than fact. Back then, the real world and the world of magic were mixed together as an inseparable whole, and a large part of the appeal of magical fantasy was its perceived realism. Now, its sense of realism is gone for good, which is why modernity can produce only fairy tales, never myths."

"Mind you, what we are discussing isn’t religion, per se, but religious feeling. This isn’t the feeling someone has toward God—it’s atheistic, and not in the complicated way of Spinoza or whomever. The religious feeling of science fiction is a deep sense of awe at the great mysteries of the universe."

"Numbness to the universe is pervasive in society."

"It is science fiction’s mission to broaden and deepen people’s minds. If someone on the way home from work at night pauses to look thoughtfully up at the stars for a while because of a sci-fi story they’ve read, then that work is a great success. Unfortunately, our current sci-fi is also benumbed to a considerable extent, and I see two possible reasons. The first is conceptual. There’s an idea that sci-fi, like mainstream literature, is about relationships between people. This idea reduces the universe to nothing but a prop, a set piece, a supporting role. It cannot be denied that this idea has given rise to many excellent works, but sci-fi is at its strongest and most charming when it depicts the relationship between people and the universe. In sci-fi, the universe itself should be a protagonist, as much as any of its characters."

"A professor of philosophy once said that lesson one for freshman in his field should consist of a long, hard look late at night at the stars. I think this would be an even more apt first lesson for aspiring writers of sci-fi."

"The cosmos had not chosen humanity after all. In the old timeline, humans had created the apex civilization on earth, but that had been a one-time and accidental chance. In our human conceit, we’d taken the accidental for the inevitable."

"The products of modern science have already surpassed the wonders of magic."

"It’s an interesting thing, really: The rigorous, science-based predictions of scientists and futurologists and the spirited “flights of fancy” of sci-fi writers are just about equally (in)accurate!"

"That humans will biologically alter themselves is inevitable, which makes life sciences the most terrifying of the sciences."

"Quantitative change eventually gives way to qualitative change."

"Exploring the secrets of the universe is the basic instinct of all intelligent life."

"Technology is a capability. To be good is a choice. Over the past 23 years, Tencent has managed to come this far because society and our country have provided support that allowed Tencent to continuously grow."

"We feel that users have more expectations. Concerning antitrust, privacy protections, the prevention of big data price discrimination, and so on, we, as users, share these concerns. For instance, with our gaming business, we know there are a lot of doubts."

"Education and health care are not only commercial services, but also public and universal ones. So on top of commerce, what can we do to play our role? What can we do in terms of pension and health in an ageing society?"

"Wealth won’t give you satisfaction, creating a good product that’s well received by users is what matters most."

"A service starts with the satisfaction and needs of its users in mind and is defined by those two things. Spending core resources and time repeatedly on the optimisation of the obvious characteristics is basically the mania of novice internet entrepreneurs."

"But copying others can't make you great. So the key is how to localize a great idea and create domestic innovation."

"Ask Jeeves will be committing resources to Bloglines to help us build out our service even more and accelerate our product roadmap"

"I got to ride the bubble"

"This time, I’m trying to make new mistakes"

"[Memo to Bill Gates:] "Bring it on." [A Microsoft newsreader would expand the market without hurting Bloglines]. They’re a program, we’re a service, like webmail. With us, you’ll be able to read your feeds from anywhere"

"I’m not great at CSS and, like many others, find that positioning elements on a web page can range from tedious at best to utterly frustrating at worst. Fortunately, ChatGPT-4 is pretty adept at stuff like this. I’m not saying it’s perfect every time, but usually, I can arrive at an answer after a few iterations."

"Groupthink: Fletcher took listservs mainstream with OneList, a company he founded in 1997. Users turned to OneList to create, administer, and find mailing lists through a simple Web-based interface. By 2000, when Yahoo! bought the company for $420 million to establish Yahoo! Groups, OneList had millions of subscribers and was sending out billions of emails per month"

"Every one of us is going to die eventually, but we as a species will stick around for a while. That’s why I think accumulating money, fame or power is irrelevant. Serving humanity is the only thing that really matters in the long run."

"In my 20 years of managing discussion platforms, I noticed that conspiracy theories only strengthen each time their content is removed by moderators. Instead of putting an end to wrong ideas, censorship often makes it harder to fight them."

"Earlier this week, Hamas used w:Telegram (software) to warn civilians in Ashkelon to leave the area ahead of their missile strikes. Would shutting down their channel help save lives — or would it endanger more lives?”"

"I’m turning 41, but I don’t feel like celebrating."

"Everyone tells me not to say the things I do. I'm very direct, very undiplomatic. Everyone tells me to stop talking about my hacker history, about my lifesytle, but I don't give a ****, I've just stayed the way I am. Over the past few years I realised that if I was to run a company or a fund, I needed to be the captain and not listen to anyone else. I needed to be the ruler of my world otherwise it was never going to work."

"[On his early history as a hacker] Every hack was a trophy. I had a big feeling of power because I was running the most important worldwide mailbox exchanging hacking information and I knew what was really going on."

"They're treating us like a Mafia, man! [...] It's unbelievable. It's only because they cannot extradite us to the US just for copyright violation. If they treat us as some sort of international criminal conspiracy, they can."

"[Defending his purchase of a rare signed copy of Adolf Hitler's Mein Kampf] I'm a [video game] Call of Duty player right ... It's all about World War II and how you play and I'm a big fan of that. I've bought memorabilia from Churchill, from Stalin, from Hitler."

"Well let me make it absolutely clear, I'm not buying into the Nazi ideology. I'm totally against what the Nazis did."

"I think in another 100 years that book will probably go up in value times 10."

"What the US Govt is doing reminds me of what I learned in school about Nazi Germany. Ironic, Hollywood is run by mostly Jewish entrepreneurs."

"[T]he obedient US colony in the South Pacific just decided to extradite me for what users uploaded to Megaupload."

"Before you know it, we have an army of strong and powerful women that can stand and compete anywhere in the world."

"Information is out there but local communities don’t have access to it, and they will rely on the next alternative."

"Over the years, people have gotten inappropriate medical advice from some practitioners, especially at the local council level and of course the consequence was disastrous to their health."

"I incorporated it in 2016, and it has grown beyond my wildest dreams."

"Government’s focus mainly on research findings from institutes is not encouraging to the young ones who have fresh and modern ideas that can help fast tract socio-economic development."

"Also, available seminars and conferences are expensive and not flexible, so to address this problem, I designed O’track to enable health workers to easily choose courses online."

"I was born in Lagos, Nigeria on 6th April,1979. I spent most of my childhood in the Caribbean islands of Dominica and Grenada, amongst other places. I landed on the shores of Accra in June 1988. Since I ended up spending most of my school-going years in developing countries, without special schools for children with disabilities, I was home schooled by my mom till I was 12 when I entered mainstream school for the first time. I started out from (Junior Secondary School) JSS 1 at Cambridge JSS (Korle-Gonno) but went to JSS 2 and 3 and wrote the (Basic Education Certificate Examination) BECE in Kaneshie Awudome 1 JSS. After which I went to a Diploma in the Management of Information Systems then I started working... In 2004, I got admission into the University of Hertfordshire (UK) to read a BSc in Computer Science and I was exempted from the first two years of the course. . Talking about her and education."

"It is picking up but we still have a long way to go. We first of all have to cultivate the habit of reading, before more people would be motivated to write. . Interview question- What is your view on the literary scene in Ghana?"

"They are both very demanding 'husbands' and one usually suffers slightly when the other is being attended to - which is why it has taken me this long to answer your questions. ."

"Ironic that the largest minority group which cuts across race, religion and sexual orientation is (one of) the most discriminated against."

"You must put in the work. Do not expect a free pass just because you have special needs. You need to be exceptionally good at what you are doing but institutions also need to put up an enabling environment that lets people with special needs be as productive as they can be."

"Nobody is perfect. We all have a part of us that doesn’t work well. Identify your disability and turn it into greatness."

"I tell myself, “You can do this, you’ve done more difficult things and survived. And even if you don’t make this deal or you can’t do this task, life goes on”. My faith has also played an important role."

"We first of all have to cultivate the habit of reading, before more people would be motivated to write."

"Representation matters, and persons with disabilities are sorely underrepresented."

"Persons with disabilities are usually portrayed as being feeble and asking for handouts, in the media. I want to change that perception. We have weaknesses and strengths like everybody else and it’s about time the focus moved from what we can’t do to what we CAN do."

"A strong female lead, gives a role model for girls to want to emulate."

"I intend to change perceptions with my story."

"I was frustrated; frustrated with societal perception of people with disabilities and frustrated with reading about a foreigner's perspective of the "African Story", which usually involves wars, famines, AIDS and child soldiers. I think it is time for us to tell our own stories.Farida speaking on the inspiration for her writing"

"I didn’t set out to impact anybody. I set out to prove to myself and to society that I could be a successful software developer despite having a neurological condition."

"If you don’t have a passion for your product and you want to become an entrepreneur because of the money, close up your business and look for a well-paying job."

"The frustrations and disappointments that come with entrepreneurship can break you, but if you are in it because you want to make a difference or you believe in what you are producing, then that spurs you on."

"There is a lot of potential for fintech in this part of the world."

"All my life I’ve been told to remove the word ‘I can’t’ from my vocabulary and replace it with ‘I’ll try’ and by grace, everything I’ve tried I’ve been successful at."

"“People with disability don’t want preferential treatment we want the playing ground to be given so we can compete as competitively as anybody else.”"

"Build something remarkable, be resourceful enough to find places where you can articulate what you are doing."

"Solutions to hard work is persistence and resilience."

"Figuring out a market that is growing is some of the things people look out for."

"It is important to think of your co-funders and your partners as people you are going to be on a long journey with."

"All acquisition conversations always require careful thought and consideration, and it was no different in this case. The Paystack team has been interacting with Patrick and the Stripe team over the past couple years and after significant amounts of collaboration and knowledge exchange between both companies, we agreed that this move was a natural evolution of what was and continues to be a great relationship."

"Venture-backed companies are generally destined for one of two outcomes. IPO or acquisition. Five years in, neither of these were on the list of things that we care about as a company. We’ve always been focused on building the best payments and growth tools for African businesses and are in it for the long haul. The option to team up with the world’s most sophisticated payments company to accelerate our ambitions happened to show up, and we believe it was fortuitous."

"Stripe and Paystack are both Y Combinator alumni, so that was the first point of contact. We were introduced to Patrick, who then offered to invest. Stripe would then lead our Series A, and along with Visa, invest $8 million in 2018. Since then, Stripe has been a close partner, and after over two years of knowledge exchange between our teams, we've built up a lot of mutual respect for each other. Eventually, it became obvious that our visions were so aligned that the natural evolution of the relationship would be to join forces in this way."

"Businesses are bought, not sold. The most important thing is to choose a problem you are excited about solving, and focusing on that every day."

"I am not really interested in Flash as a mere animation tool. I use Flash because of its programming possibilities, ability to integrate with graphical images, good browser compatibility and because it is easy to use."

"Some people feel that designers are often drawn to Flash because of its multimedia capabilities at the expense of other demands of a client's brief. In other words, Flash is often misused or used to build sites where other technologies might have served the client's needs better."

"I agree with some of it. In the light of current Web systems, creating a site with ordinary HTML and XML technology ensures effective information media. Up to now, developing a site by using Flash meant that sacrifices had to be made in other areas. We must bear this in mind. We should also remember that Flash is a mere tool like any other Web technology. It is important to know how to use tools freely, but dependency on a specific tool leads to meaningless results."

"On the other hand, I feel strongly that where the Web is used as media, it should always involve new experiences and excitement. I like to satisfy my desire to present something interesting that has not been seen before, even if it is at a cost. When I work with a client who feels the same, I will go ahead and do what I want to do. Each case is of course judged on its own merits."

"What the internet has truly changed is not political dissent, but rather social dissent. We must protect it as a safe space where people can experiment with gender and sexual identities, explore what it means to be gay or a single mom or an atheist or a Christian in the Middle East, but also what it means to be black and angry in the US, to be Muslim and ostracized in Europe, or to be a coal miner in a world that must cut back on greenhouse gases. The internet is the only space where all different modes of being Palestinian can meet. If I express this precariousness in symbolic violence, will you hear me out? Will you protect me from both prosecution by the establishment and exploitation by the well-funded fringe extremists?"

"can we get back to killing zionists please? they seem to be more violent when we stick to non violence."

"Unfortunately, the Iranian nuclear project isn't dedicated to the extermination of the white man; Bin Laden's odds are higher."

"Dear Zionists, please don’t ever talk to me, I’m a violent person who advocated the killing of all Zionists including civilians, so f--- off."

"So the brilliant British dogs and monkeys really think terrorists will reveal their plans on Twitter."

"there was no genocide against Jews by the Nazis – after all, many Jews are left."

"Now my real criticism of these post-police murder riots is the wrong focus, go burn the City or Downing Street, or hunt police fools."

"police are not human...They don’t have rights, we should just kill them all."

"I consider killing any colonialists and specially zionists heroic, we need to kill more of them."

"Now all I can think of is joining Bin Laden and killing a few Americans."

"I’m telling you that I hate white people."

"And you talk to most of them, and they come out telling you they're the ones who's oppressed and victims. I seriously, seriously, seriously hate white people, especially those of English or Dutch or German descent."

"May I start by raising the case of Alaa Abd el-Fattah? As the Prime Minister knows and has said, he is a British citizen jailed for the crime of posting on social media and has been imprisoned in Egypt for most of the last nine years; he has been on hunger strike for the last six months. The Prime Minister just said that he raised this case with President Sisi; what progress did he make in securing Alaa's release?"

"I’m delighted that Alaa Abd El-Fattah is back in the UK and has been reunited with his loved ones, who must be feeling profound relief... Alaa's case has been a top priority for my government since we came to office."

"Mr El-Fattah is a British citizen. It has been a long-standing priority under successive governments to work for his release from detention, and to see him reunited with his family in the UK."

"By his own public posts, Mr Abd El-Fattah has endorsed killing ‘zionists’ and urged more of it. He has also been widely reported as having called for the killing of Israelis, in terms so extreme that his nomination for a major European human rights prize was withdrawn when the post came to light. He has since sought to explain himself. That only underlines the point: this is not ancient history. It is a live controversy about incitement and hatred."

"Tweet the wrong thing in Britain and you’ll serve 13 months. Tweet the wrong thing in Egypt and we’ll bring you here, put you up, pay for your son’s special school - while you call us apes and boast of hating white people."

"Discussions about AI advancements in Africa often highlight the misconceptions held by the rest of the world. First, Africa has always been positioned as merely a passive consumer of technologies developed elsewhere: They build, ship here, and we're expected to use them."

"...many AI-driven solutions introduced in Africa fail to address local needs, are riddled with biases, and inadvertently create a form of foreign technological dominance in African markets."

"...it is entirely false to assume that innovation cannot thrive on the continent. The narrative must shift from waiting for external solutions to actively building and scaling local innovations."

"Decision-makers who shape global AI strategies rarely engage with the realities on the ground. It is not just being quoted as an African, If you haven’t been ground-building AI-driven models in Africa, you can’t be loud and make decisions on our behalf."

"Africa plays a vital role in the global AI landscape. Our experience navigating complex social, economic, and cultural contexts equips us to develop nuanced, adaptable governance frameworks, and models that could inspire other regions facing similar challenges."

"If you want to build AI-driven solutions for African markets, don't focus on trends, build with purpose. Africa doesn't need fancy AI products; we need effective, impactful solutions. Also, keep in mind that for every problem, there are multiple ways to solve it. AI is just one tool in the toolbox, and sometimes, it may not be the best one. So be open-minded."

"To young African women aspiring to break into AI and tech, believe in your potential and skills. Stay open to collaboration, and don't shy away from driving innovation. Own your story and actively shape it. Your ideas, your voice, and your innovations are crucial to the future of technology in Africa. Don't miss the opportunity to contribute to the Africa AI narrative."

"It's time for us as young African engineers to start working on solutions to solve our local challenges."

"It’s time for us as young African engineers to start working on solutions to solve our local challenges.” — Charlette N’Guessan on driving innovation tailored to Africa’s needs."