"The engineer must be able not only to design, but to execute. A draftsman may be able to design, but unless he is able to execute his designs to successful operation he cannot be classed as an engineer. The production engineer must be able to execute his work as he has planned it. This requires two qualifications in addition to technical engineering ability: He must know men, and he must have creative ability in applying good statistical, accounting, and 'system' methods to any particular production work he may undertake." (Hugo Diemer, "Industrial Engineering", 1905)
"It is a good rule of thumb that a program should read from top to bottom in the order that it will be executed; if this is not true, watch out for the bugs that often accompany poor structure. Make your programs read from top to bottom." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"The best documentation for a computer program is a clean structure. It also helps if the code is well formatted, with good mnemonic identifiers and labels" (if any are needed), and a smattering of enlightening comments. Flowcharts and program descriptions are of secondary importance; the only reliable documentation of a computer program is the code itself. The reason is simple -whenever there are multiple representations of a program, the chance for discrepancy exists. If the code is in error, artistic flowcharts and detailed comments are to no avail. Only by reading the code can the programmer know for sure what the program does." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)
"A good information system both exposes interface errors and stimulates their correction" (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)
"A good top-down design avoids bugs in several ways. First, the clarity of structure and representation makes the precise statement of requirements and functions of the modules easier. Second, the partitioning and independence of modules avoids system bugs. Third, the suppression of detail makes flaws in the structure more apparent. Fourth, the design can be tested at each of its refinement steps, so testing can start earlier and focus on the proper level of detail at each step." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)
"I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)
"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." (Edsger W Dijkstra, "How do we tell truths that might hurt?", 1975)
"A good scientist is a person with original ideas. A good engineer is a person who makes a design that works with as few original ideas as possible. There are no prima donnas in engineering." (Freeman Dyson, "Disturbing the Universe", 1979)
"Today's scientific investigations are so complicated that even experts in related fields may not understand them well. But there is a logic in the planning of experiments and in the analysis of their results that all intelligent people can grasp, and this logic is a great help in determining when to believe what we hear and read and when to be skeptical. This logic has a great deal to do with statistics, which is why statisticians have a unique interest in the scientific method, and why some knowledge of statistics can so often be brought to bear in distinguishing good arguments from bad ones." (Robert Hooke, "How to Tell the Liars from the Statisticians", 1983)
"Object-oriented programming increases the value of these metrics by managing this complexity. The most effective tool available for dealing with complexity is abstraction. Many types of abstraction can be used, but encapsulation is the main form of abstraction by which complexity is managed in object-oriented programming. Programming in an object-oriented language, however, does not ensure that the complexity of an application will be well encapsulated. Applying good programming techniques can improve encapsulation, but the full benefit of object-oriented programming can be realized only if encapsulation is a recognized goal of the design process." (Rebecca Wirfs-Brock," Object-Oriented Design: A responsibility-driven approach", 1989)
"Programming in an object-oriented language, however, does not ensure that the complexity of an application will be well encapsulated. Applying good programming techniques can improve encapsulation, but the full benefit of object-oriented programming can be realized only if encapsulation is a recognized goal of the design process." (Rebecca Wirfs-Brock, "Object-oriented Design: A responsibility-driven approach", 1989)
"Good engineering is not a matter of creativity or centering or grounding or inspiration or lateral thinking, as useful as those might be, but of decoding the clever, even witty, messages the solution space carves on the corpses of the ideas in which you believed with all your heart, and then building the road to the next message." (Fred Hapgood, "Up the infinite Corridor: MIT and the Technical Imagination", 1993)
"Users are not designers, so it is not reasonable to expect them to come up with design ideas from scratch. However, they are very good at reacting to concrete designs they do not like or that will not work in practice. To get full benefits from user involvement, it is necessary to present these suggested system designs in a form the users can understand." (Jakob Nielsen, "Usability Engineering", 1993)
"Users often do not know what is good for them. [...] Users have a very hard time predicting how they will interact with potential future systems with which they have no experience. [...] Furthermore, users will often have divergent opinions when asked about details of user interface design." (Jakob Nielsen, "Usability Engineering", 1993)
"When one considers how hard it is to write a computer program even approaching the intellectual scope of a good mathematical paper, and how much greater time and effort have to be put into it to make it 'almost' formally correct, it is preposterous to claim that mathematics as we practice it is anywhere near formally correct." (William P Thurston, "On proof and progress in mathematics", Bulletin of the AMS 30" (2), 1994)
"Good design protects you from the need for too many highly accurate components in the system. But such design principles are still, to this date, ill-understood and need to be researched extensively. Not that good designers do not understand this intuitively, merely it is not easily incorporated into the design methods you were taught in school. Good minds are still needed in spite of all the computing tools we have developed." (Richard Hamming, "The Art of Doing Science and Engineering: Learning to Learn", 1997)
"The woes of software engineering are not due to lack of tools or proper management, but largely due to lack of sufficient technical competence. A good designer must rely on experience; on precise, logical thinking; and on pedantic exactness. No magic will do. In light of all this, it is particularly sad that, in many informatics curricula, programming in the large is badly neglected. Design has become a non-topic." (Niklaus Wirth, [interview in Software Development] 1997)
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." (Martin Fowler, "Refactoring: Improving the Design of Existing Code", 1999)
"Good programmers know what to write. Great ones know what to rewrite." (Eric S Raymond, "The Cathedral and the Bazaar", 1999)
"The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better." (Eric S Raymond, "The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary", 1999)
"Project failures are not always the result of poor methodology; the problem may be poor implementation. Unrealistic objectives or poorly defined executive expectations are two common causes of poor implementation. Good methodologies do not guarantee success, but they do imply that the project will be managed correctly." (Harold Kerzner, "Strategic Planning for Project Management using a Project Management Maturity Model", 2001)
"The physical design process is a key phase in the overall design process. It is too often ignored until the last minute in the vain hope that performance will be satisfactory. Without a good physical design, performance is rarely satisfactory and throwing hardware at the problem is rarely completely effective. There is no substitute for a good physical design, and the time and effort spent in the physical design process will be rewarded with an efficient and well-tuned database, not to mention happy users!" (Ken England, "Microsoft SQL Server 2000 Performance Optimization and Tuning Handbook", 2001)
"Good design is also an act of communication between the designer and the user, except that all the communication has to come about by the appearance of the device itself. The device must explain itself." (Donald Norman, "The Design of Everyday Things", 2002)
"All OO languages show some tendency to suck programmers into the trap of excessive layering. Object frameworks and object browsers are not a substitute for good design or documentation, but they often get treated as one. Too many layers destroy transparency: It becomes too difficult to see down through them and mentally model what the code is actually doing. The Rules of Simplicity, Clarity, and Transparency get violated wholesale, and the result is code full of obscure bugs and continuing maintenance problems." (Eric S Raymond, "The Art of Unix Programming", 2003)
"Many things can put a project off course: bureaucracy, unclear objectives, and lack of resources, to name a few. But it is the approach to design that largely determines how complex software can become. When complexity gets out of hand, developers can no longer understand the software well enough to change or extend it easily and safely. On the other hand, a good design can create opportunities to exploit those complex features." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)
"The effectiveness of an overall design is very sensitive to the quality and consistency of fine-grained design and implementation decisions. With a MODEL-DRIVEN DESIGN, a portion of the code is an expression of the model; changing that code changes the model. Programmers are modelers, whether anyone likes it or not. So it is better to set up the project so that the programmers do good modeling work." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)
"Coupling describes how tightly a class or routine is related to other classes or routines. The goal is to create classes and routines with small, direct, visible, and flexible relations to other classes and routines, which is known as loose coupling." The concept of coupling applies equally to classes and routines [...] Good coupling between modules is loose enough that one module can easily be used by other modules."" (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)
"Good code is its own best documentation." (Steve McConnell, "Code Complete", 2004)
"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." (Rob Pike, [interview] 2004)
"The flip side of the coin was that even good programmers and language designers tended to do terrible extensions when they were in the heat of programming, because design is something that is best done slowly and carefully." (Alan Kay, [ACM Queue A Conversation with Alan Kay Vol. 2" (9)] 2004-2005)
"Abstractions matter to users too. Novice users want programs whose abstractions are simple and easy to understand; experts want abstractions that are robust and general enough to be combined in new ways. When good abstractions are missing from the design, or erode as the system evolves, the resulting program grows barnacles of complexity. The user is then forced to master a mass of spurious details, to develop workarounds, and to accept frequent, inexplicable failures." (Daniel Jackson, "Software Abstractions", 2006)
"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." (Linus Torvalds, [email] 2006)
"Much data in databases has a long history. It might have come from old 'legacy' systems or have been changed several times in the past. The usage of data fields and value codes changes over time. The same value in the same field will mean totally different thing in different records. Knowledge or these facts allows experts to use the data properly. Without this knowledge, the data may bc used literally and with sad consequences. The same is about data quality. Data users in the trenches usually know good data from bad and can still use it efficiently. They know where to look and what to check. Without these experts, incorrect data quality assumptions are often made and poor data quality becomes exposed." (Arkady Maydanchik, "Data Quality Assessment", 2007)
"One of the essential parts of a formal training in programming is a long and demanding study of the large collection of algorithms that have already been discovered and analyzed, together with the Data Structures" (carefully tailored, seemingly unnatural ways of organizing data for effective access) that go with them. As with any other engineering profession, it is impossible to do a good job without a thorough knowledge of what has been tried before. If a programmer starts the job fully armed with what is already known, they will have some chance of finding something new. Inventiveness is important: not all problems have been seen before. A programmer who does not already know the standard algorithms and data structures is doomed to nothing more than rediscovering the basics." (Robert Plant & Stephen Murrell, "An Executive's Guide to Information Technology: Principles, Business Models, and Terminology", 2007)
"We are also limited by the fact that verbalization works best when mental model manipulation is an inherent element of the task of interest. Troubleshooting, computer programming, and mathematics are good examples of tasks where mental model manipulation is central and explicit. In contrast, the vast majority of tasks do not involve explicit manipulation of task representations. Thus, our access of mental models - and the access of people doing these tasks - is limited." (William B Rouse, "People and Organizations: Explorations of Human-Centered Design", 2007)
"Well-commented code is one hallmark of good programming practice; it shows that you care about what you're doing, and it is considerate to those who will come after you to fix your bugs. But comments also serve as a kind of back channel for programmer-to-programmer communication and even occasionally as a competitive arena or an outlet for silliness." (Scott Rosenberg, "Dreaming in Code", 2007)
"Good software designs accommodate change without huge investments and rework. When we use code that is out of our control, special care must be taken to protect our investment and make sure future change is not too costly." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)
"Most programming languages contain good parts and bad parts. I discovered that I could be better programmer by using only the good parts and avoiding the bad parts." (Douglas Crockford, "JavaScript: The Good Parts", 2008)
"Standards make it easier to reuse ideas and components, recruit people with relevant experience, encapsulate good ideas, and wire components together. However, the process of creating standards can sometimes take too long for industry to wait, and some standards lose touch with the real needs of the adopters they are intended to serve." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)
"A good system design is based on a sound conceptual model" (architecture). A system design that has no conceptual structure and little logic to its organization is ultimately going to be unsuccessful. Good architecture will address all the requirements of the system at the right level of abstraction." (Vasudeva Varma, "Software Architecture: A Case Based Approach", 2009)
"Anti-patterns are the dark side of patterns - common mistakes we fall into repeatedly. Sometimes they seem to be good solutions that experience has demonstrated don���t work in practice. On other occasions, we know that they're not a good idea, but we fall into them anyway." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)
"One final point - whether fixing bugs or implementing new functionality, it's good practice to always examine exactly what it is that you're about to check in before every check-in. It won't take long, and every once in a while, you'll catch a change that you really didn't intend to make from slipping through."" (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)
"For some reason software developers don't think of debugging time as coding time. They think of debugging time as a call of nature, something that just has to be done. But debugging time is just as expensive to the business as coding time is, and therefore anything we can do to avoid or diminish it is good." (Robert C Martin, "The Clean Coder: A code of conduct for professional programmers", 2011)
"A complete data analysis will involve the following steps: (i) Finding a good model to fit the signal based on the data. (ii) Finding a good model to fit the noise, based on the residuals from the model." (iii) Adjusting variances, test statistics, confidence intervals, and predictions, based on the model for the noise." (DeWayne R Derryberry, "Basic data analysis for time series with R", 2014)
"A good heuristic decision is made by 1) knowing what to look for, 2) knowing when enough information is enough" (the 'threshold of decision' ), and 3) knowing what decision to make." (Patrick Van Horne, "Left of Bang", 2014)
"Good architecture is all about splitting stuff reliably into self-contained parcels that allow work on them to continue relatively independently in parallel" (often these days in different locations)." (Richard Hopkins & Stephen Harcombe, "Agile Architecting: Enabling the Delivery of Complex Agile Systems Development Projects", 2014)
"Good architecture provides good interfaces that separate the shear layers of its implementation: a necessity for evolution and maintenance. Class-oriented programming puts both data evolution and method evolution in the same shear layer: the class. Data tend to remain fairly stable over time, while methods change regularly to support new services and system operations. The tension in these rates of change stresses the design." (James O Coplien & Trygve Reenskaug, "The DCI Paradigm: Taking Object Orientation into the Architecture World", 2014)
"In more ways than one, architecture is all about avoiding bottlenecks. In architecture, the term bottleneck typically refers to a design problem that is preventing processing from occurring at full speed. [...] A good architecture will avoid bottlenecks in both." (Richard Hopkins & Stephen Harcombe, "Agile Architecting: Enabling the Delivery of Complex Agile Systems Development Projects", 2014)
"There is a tendency to believe that good architecture leads to systems that perform better and are more secure, but such claims relate less to any given architectural principle than to the timing of big-picture deliberations in the design cycle and to the proper engagement of suitable stakeholders." (James O Coplien & Trygve Reenskaug, "The DCI Paradigm: Taking Object Orientation into the Architecture World", 2014)
"When designers intentionally trick users into inviting friends or blasting a message to their social networks, they may see some initial growth, but it comes at the expense of users' goodwill and trust. When people discover they've been duped, they vent their frustration and stop using the product." (Nir Eyal, "Hooked: How to Build Habit-Forming Products", 2014)
"When you write a computer program you've got to not just list things out and sort of take an algorithm and translate it into a set of instructions. But when there's a bug - and all programs have bugs - you've got to debug it. You've got to go in, change it, and then re-execute [...] and you iterate. And that iteration is really a very, very good approximation of learning." (Nicholas Negroponte, "A 30-year history of the future", [Ted Talk] 2014)
"Areas of low complexity or that are unlikely to be invested in can be built without the need for perfect code quality; working software is good enough. Sometimes feedback and first-to-market are core to the success of a product; in this instance, it can make business sense to get working software up as soon as possible, whatever the architecture." (Scott Millett, "Patterns Principles and Practices of Domain Driven Design", 2015)
"But 'average cost to fix one defect' is a stupid metric [...] It makes bad projects look good, and good projects look bad. How? By failing to divide the costs of fixing into two categories: fixed costs of detecting and fixing defects - costs which are the same no matter how buggy or how good the product is - and variable costs, those which you pay for each defect." (Laurent Bossavit, "The Leprechauns of Software Engineering", 2015)
"Good user stories are expected to be independent, negotiable, valuable, estimable, small, and testable" (mnemonic INVEST). Good tasks are expected to be specific, measurable, achievable, relevant, and time-boxed" (mnemonic SMART). The key difference is that tasks need not be independent or valuable by themselves." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)
"This is what the Agile Manifesto means when it says responding to change over following a plan. To maximize adaptability, it is essential to have good, fast feedback loops. This is why there is so much emphasis on iterative development." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)
"No methodology can guarantee success. But a good methodology can provide a feedback loop for continual improvement and learning." (Ash Maurya, "Scaling Lean: Mastering the Key Metrics for Startup Growth", 2016)
"Sometimes you can't fit everything in. Remember that the sprint is great for testing risky solutions that might have a huge payoff. So you'l have to reverse the way you would normally prioritize. If a small fix is so good and low-risk that you're already planning to build it next week, then seeing it in a prototype won't teach you much. Skip those easy wins in favor of big, bold bets." (Jake Knapp et al, "Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days", 2016)
"Feature extraction is also the most creative part of data science and the one most closely tied to domain expertise. Typically, a really good feature will correspond to some real-world phenomenon. Data scientists should work closely with domain experts and understand what these phenomena mean and how to distill them into numbers." (Field Cady, "The Data Science Handbook", 2017)
"Making good engineering decisions is all about weighing all of the available inputs and making informed decisions about the trade-offs. Sometimes, those decisions are based on instinct or accepted best practice, but only after we have exhausted approaches that try to measure or estimate the true underlying costs." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)
No comments:
Post a Comment