Software Engineers

"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."

"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)."

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

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

"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."

"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."

"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."

"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]."

"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."

"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."

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

"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."

"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."

"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."

"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."

"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."

"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."

"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."

"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."

"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."

"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."

"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 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."

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

"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."

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

"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."

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

"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."

"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."

"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"."

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

"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."

"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."

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

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

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

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

"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."

"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!"?"

"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."

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