🔢Dhanurjay "DJ" Patil - Collected Quotes

"[...] a good definition of a data product is a product that facilitates an end goal through the use of data. It’s tempting to think of a data product purely as a data problem. After all, there’s nothing more fun than throwing a lot of technical expertise and fancy algorithmic work at a difficult problem." (Dhanurjay Patil, "Data Jujitsu: The Art of Turning Data into Product", 2012)

"As data scientists, we prefer to interact with the raw data. We know how to import it, transform it, mash it up with other data sources, and visualize it. Most of your customers can’t do that. One of the biggest challenges of developing a data product is figuring out how to give data back to the user. Giving back too much data in a way that’s overwhelming and paralyzing is 'data vomit'. It’s natural to build the product that you would want, but it’s very easy to overestimate the abilities of your users. The product you want may not be the product they want." (Dhanurjay Patil, "Data Jujitsu: The Art of Turning Data into Product", 2012)

"By giving data back to the user, you can create both engagement and revenue. We’re far enough into the data game that most users have realized that they’re not the customer, they’re the product. Their role in the system is to generate data, either to assist in ad targeting or to be sold to the highest bidder, or both." (Dhanurjay Patil, "Data Jujitsu: The Art of Turning Data into Product", 2012)

"Data Jujitsu: the art of using multiple data elements in clever ways to solve iterative problems that, when combined, solve a data problem that might otherwise be intractable." (Dhanurjay Patil, "Data Jujitsu: The Art of Turning Data into Product", 2012)

"Generalizing beyond advertising, when building any data product in which the data is obfuscated (where there isn’t a clear relationship between the user and the result), you can compromise on precision, but not on recall. But when the data is exposed, focus on high precision." (Dhanurjay Patil, "Data Jujitsu: The Art of Turning Data into Product", 2012)

"Ideas for data products tend to start simple and become complex; if they start complex, they become impossible." (Dhanurjay Patil, "Data Jujitsu: The Art of Turning Data into Product", 2012)

"In many applications, a design treatment that gives the user control over the outcome can go far to create interactions that leave the user feeling good." (Dhanurjay Patil, "Data Jujitsu: The Art of Turning Data into Product", 2012)

"Smart data scientists don’t just solve big, hard problems; they also have an instinct for making big problems small." (Dhanurjay Patil, "Data Jujitsu: The Art of Turning Data into Product", 2012)

"The best way to avoid data vomit is to focus on actionability of data. That is, what action do you want the user to take? If you want them to be impressed with the number of things that you can do with the data, then you’re likely producing data vomit. If you’re able to lead them to a clear set of actions, then you’ve built a product with a clear focus." (Dhanurjay Patil, "Data Jujitsu: The Art of Turning Data into Product", 2012)

"The key aspect of making a data product is putting the 'product' first and 'data' second. Saying it another way, data is one mechanism by which you make the product user-focused. With all products, you should ask yourself the following three questions: (1) What do you want the user to take away from this product? (2) What action do you want the user to take because of the product? (3) How should the user feel during and after using your product?" (Dhanurjay Patil, "Data Jujitsu: The Art of Turning Data into Product", 2012)

"You can give your data product a better chance of success by carefully setting the users’ expectations. [...] One under-appreciated facet of designing data products is how the user feels after using the product. Does he feel good? Empowered? Or disempowered and dejected?" (Dhanurjay Patil, "Data Jujitsu: The Art of Turning Data into Product", 2012)

"Data is such an incredible lever arm for change, we need to make sure that the change that is coming, is the one we all want to see." (Dhanurjay Patil, "A Code of Ethics for Data Science", 2016)

Alfred R Ilersic - Collected Quotes

"Diagrams are sometimes used, not merely to convey several pieces of information such as several time series on one chart, but also to provide visual evidence of relationships between the series." (Alfred R Ilersic, "Statistics", 1959)

"Everybody has some idea of the meaning of the term 'probability' but there is no agreement among scientists on a precise definition of the term for the purpose of scientific methodology. It is sufficient for our purpose, however, if the concept is interpreted in terms of relative frequency, or more simply, how many times a particular event is likely to occur in a large population." (Alfred R Ilersic, "Statistics", 1959)

"However informative and well designed a statistical table may be, as a medium for conveying to the reader an immediate and clear impression of its content, it is inferior to a good chart or graph. Many people are incapable of comprehending large masses of information presented in tabular form; the figures merely confuse them. Furthermore, many such people are unwilling to make the effort to grasp the meaning of such data. Graphs and charts come into their own as a means of conveying information in easily comprehensible form." (Alfred R Ilersic, "Statistics", 1959)

"In brief, the greatest care must be exercised in using any statistical data, especially when it has been collected by another agency. At all times, the statistician who uses published data must ask himself, by whom were the data collected, how and for what purpose?" (Alfred R Ilersic, "Statistics", 1959)

"It is a good rule to remember that the first step in analyzing any statistical data, whether it be culled from an official publication or a report prepared by someone else, is to check the definitions used for classification." (Alfred R Ilersic, "Statistics", 1959)

"It is helpful to remember when dealing with index numbers that they are specialized tools and as such are most efficient and useful when properly used. A screwdriver is a poor substitute for a chisel, although it may be used as such. All index numbers are designed to measure particular groups of related changes." (Alfred R Ilersic, "Statistics", 1959)

"Most people tend to think of values and quantities expressed in numerical terms as being exact figures; much the same as the figures which appear in the trading account of a company. It therefore comes as a considerable surprise to many to learn that few published statistics, particularly economic and sociological data, are exact. Many published figures are only approximations to the real value, while others are estimates of aggregates which are far too large to be measured with precision." (Alfred R Ilersic, "Statistics", 1959)

"Numerical data, which have been recorded at intervals of time, form what is generally described as a time series. [...] The purpose of analyzing time series is not always the determination of the trend by itself. Interest may be centered on the seasonal movement displayed by the series and, in such a case, the determination of the trend is merely a stage in the process of measuring and analyzing the seasonal variation. If a regular basic or under- lying seasonal movement can be clearly established, forecasting of future movements becomes rather less a matter of guesswork and more a matter of intelligent forecasting." (Alfred R Ilersic, "Statistics", 1959)

"Often, in order to simplify statistical tables, the practice of rounding large figures and totals is resorted to. Where the constituent figures in a table together with their aggregate have been so treated, a discrepancy between the rounded total and the true sum of the rounded constituent figures frequently arises. Under no circumstances should the total be adjusted to what appears to be the right answer. A note to the table to the effect that the figures have been rounded, e.g. to the nearest 1,000, is all that is necessary. The same remark applies to percentage equivalents of the constituent parts of a total; it they do not add to exactly 100 per cent, leave them." (Alfred R Ilersic, "Statistics", 1959)

"Poor statistics may be attributed to a number of causes. There are the mistakes which arise in the course of collecting the data, and there are those which occur when those data are being converted into manageable form for publication. Still later, mistakes arise because the conclusions drawn from the published data are wrong. The real trouble with errors which arise during the course of collecting the data is that they are the hardest to detect." (Alfred R Ilersic, "Statistics", 1959)

"Statistical method consists of two main operations; counting and analysis. [...] The statistician has no use for information that cannot be expressed numerically, nor generally speaking, is he interested in isolated events or examples. The term 'data  is itself plural and the statistician is concerned with the analysis of aggregates. " (Alfred R Ilersic, "Statistics", 1959)

"The averaging of percentages themselves requires care, where the percentages are each computed on different bases, i.e. different quantities. The average is not derived by aggregating the percentages and dividing them. Instead of this, each percentage must first be multiplied by its base to bring out its relative significance to the other percentages and to the total. The sum of the resultant products is then divided by the sum of the base values [...], not merely the number of items." (Alfred R Ilersic, "Statistics", 1959)

"The rounding of individual values comprising an aggregate can give rise to what are known as unbiased or biased errors. [...]The biased error arises because all the individual figures are reduced to the lower 1,000 [...] The unbiased error is so described since by rounding each item to the nearest 1,000 some of the approximations are greater and some smaller than the original figures. Given a large number of such approximations, the final total may therefore correspond very closely to the true or original total, since the approximations tend to offset each other. [...] With biased approximations, however, the errors are cumulative and their aggregate increases with the number of items in the series." (Alfred R Ilersic, "Statistics", 1959)

"The simplest way of indicating that figures are not given precisely to the last unit is to express them to the nearest 100 or 1,000; or in some cases to the nearest 100,000 or million. [...] The widespread desire for precision is reflected in many reports on economic trends which quote figures in great detail, rather than emphasizing the trends and movements reflected in the figures." (Alfred R Ilersic, "Statistics", 1959)

"The statistician has no use for information that cannot be expressed numerically, nor generally speaking, is he interested in isolated events or examples. The term ' data ' is itself plural and the statistician is concerned with the analysis of aggregates." (Alfred R Ilersic, "Statistics", 1959)

"The statistics themselves prove nothing; nor are they at any time a substitute for logical thinking. There are […] many simple but not always obvious snags in the data to contend with. Variations in even the simplest of figures may conceal a compound of influences which have to be taken into account before any conclusions are drawn from the data." (Alfred R Ilersic, "Statistics", 1959)

"There are good statistics and bad statistics; it may be doubted if there are many perfect data which are of any practical value. It is the statistician's function to discriminate between good and bad data; to decide when an informed estimate is justified and when it is not; to extract the maximum reliable information from limited and possibly biased data." (Alfred R Ilersic, "Statistics", 1959)

"This is the essential characteristic of a logarithmic scale. Any given increase, regardless of its absolute size, is related to a given base quantity. Thus, a perfectly straight line on such a graph denotes a constant percentage rate of increase, and not a constant absolute increase. It is the slope of the line or curve which is significant in such a graph. The steeper the slope, whether it be downwards or upwards, the more marked is the rate of change." (Alfred R Ilersic, "Statistics", 1959)

"This type of graph possesses a number of advantages. It is possible to graph a number of series of widely differing magnitudes on a single chart and bring out any relationship between their movements. How- ever wide the amplitude of the fluctuations in the series, a logarithmic scale reduces them to manageable size on a single sheet of graph paper, whereas, on a normal scale, it might prove impossible to get the larger fluctuations on to a single chart, except by so reducing the scale that all the other smaller movements in the series are almost obliterated." (Alfred R Ilersic, "Statistics", 1959)

"Time series analysis often requires more knowledge of the data and relevant information about their background than it does of statistical techniques. Whereas the data in some other fields may be controlled so as to increase their representativeness, economic data are so changeable in their nature that it is usually impossible to sort out the separate effects of the various influences. Attempts to isolate cyclical, seasonal and irregular, or random movements, are made primarily in the hope that some underlying pattern of change over time may be revealed."  (Alfred R Ilersic, "Statistics", 1959)

"When using estimated figures, i.e. figures subject to error, for further calculation make allowance for the absolute and relative errors. Above all, avoid what is known to statisticians as 'spurious' accuracy. For example, if the arithmetic Mean has to be derived from a distribution of ages given to the nearest year, do not give the answer to several places of decimals. Such an answer would imply a degree of accuracy in the results of your calculations which are quite un- justified by the data. The same holds true when calculating percentages." (Alfred R Ilersic, "Statistics", 1959)

"While it is true to assert that much statistical work involves arithmetic and mathematics, it would be quite untrue to suggest that the main source of errors in statistics and their use is due to inaccurate calculations." (Alfred R Ilersic, "Statistics", 1959)

Book available on Archive.org.

✏️Roy D G Allen - Collected Quotes

"A knowledge of statistical methods is not only essential for those who present statistical arguments it is also needed by those on the receiving end." (Roy D G Allen, "Statistics for Economists", 1951)

"All statistical data are subject to errors in collection." (Roy D G Allen, "Statistics for Economists", 1951)

"Any time series can now be plotted in two ways. Time is measured along the horizontal axis on a natural scale; the variable is measured along the vertical axis either on a natural or on a ratio scale. A graph of the second kind is the new construction; it is often called a semi-logarithmic graph since the ratio or logarithmic scale is used on one of the two axes of the graph."

"As with tabulation, however, skill in constructing diagrams is only acquired after long experience. The main point can be easily made; a graph or diagram should be clear and simple since it adds nothing to our understanding if it does not show up the trends and relations of our data more obviously than in the original tables. A chart is meant to 'help out' in drawing broad conclusions from a table which may be quite complicated. Inevitably the graph or diagram is less exact and shows less detail than the table; it is a step in the constant process of summarizing data. This must not be overdone. It is only too easy to simplify so drastically as to be misleading." (Roy D G Allen, "Statistics for Economists", 1951)

"Graphs and diagrams help to show up trends and relations but they do not define or measure them precisely. This can be achieved by calculations on the numerical data and, in particular, by the derivation of figures to summarize and relate the significant facts in a table. The main purpose of statistical analysis is to make comparisons. A single figure has no meaning by itself; it only becomes significant and "alive" when compared explicitly or implicitly with another figure. Our first task in analysis is to make the comparisons explicit, to express the relation between one figure and another." (Roy D G Allen, "Statistics for Economists", 1951)

"Graphs [for time series] can be misleading, however, and we need to subject our first impression to a closer scrutiny. We must develop more precise methods of analysis of time series. The variations of a time series are of many kinds which can be grouped under three heads. There is, first, the general direction of movement or the trend of the variable over the long period. Then there are oscillations of various types, of greater or less regularity, superimposed on the trend. Finally, there are residual or irregular variations which may arise from isolated events such as a war or general strike, or which may be due to the operation of random influences." (Roy D G Allen, "Statistics for Economists", 1951)

"It is only by experience that skill is acquired in the framing of tables. It is partly a matter of design, to get a neat and concise layout which is both cheap to print and easy on the eye. It is partly a question of making sure that no essential information is omitted so as to leave the meaning of the table uncertain." (Roy D G Allen, "Statistics for Economists", 1951)

"Not even the most subtle and skilled analysis can overcome completely the unreliability of basic data." (Roy D G Allen, "Statistics for Economists", 1951)

"One very simple but effective form of statistical analysis is to represent the tabular data by drawing graphs or diagrams. If made with skill and care in avoiding bias, a diagram will show the data in a graphical form in which the salient features leap to the eye. The risk is that diagrams can be misleading when drawn by the unskilled and they can be very dangerous tools in unscrupulous hands." (Roy D G Allen, "Statistics for Economists", 1951)

"Summarization of statistical data into tabular form is an art rather than a routine following a set of formal rules. Tabulation inevitably implies a loss of detail. The original data are far too voluminous to be appreciated and understood; the significant details are mixed up with much that is irrelevant. The art of tabulation lies in the sacrifice of detail which is less significant for the purposes in hand so that what is really important can be emphasized. Tabulation implies classification, the grouping of items into classes according to various characteristics. And classification depends on clear and precise definitions." (Roy D G Allen, "Statistics for Economists", 1951)

"The error in a sum or difference of any number of rounded figures is the sum of the errors in the separate figures. [...] The relative error in a product or quotient. of two rounded figures is approximately the sum of the relative errors in the separate figures. [...] It is generally safe to write a product or quotient as correct to one less significant figure than the less accurate of the two values in the product or quotient." (Roy D G Allen, "Statistics for Economists", 1951)

"The function of the regression lines, as approximate representations of means of arrays, is to isolate the mean value of one variable corresponding to any given value of the other; the variation of the first variable about its mean is ignored. A regression line is an average relation, and with it there is a variation of values about the average. In the regression of y on x, the variation ignored is in the vertical direction, a variation of y up and down about the line." (Roy D G Allen, "Statistics for Economists", 1951)

⛩️Daniel Jackson - Collected Quotes

"A commitment to simplicity of design means addressing the essence of design - the abstractions on which software is built - explicitly and up front. Abstractions are articulated, explained, reviewed and examined deeply, in isolation from the details of the implementation. This doesn’t imply a waterfall process, in which all design and specification precedes all coding. But developers who have experienced the benefits of this separation of concerns are reluctant to rush to code, because they know that an hour spent on designing abstractions can save days of refactoring." (Daniel Jackson, "Software Abstractions", 2006)

"A language for describing software abstractions is more than just a logic. You need ways to organize a model, to build larger models from smaller ones, and to factor out components that can be used more than once. There are also small syntactic details - such as shorthands for declarations - that make a language usable in practice. And finally, there’s the need to communicate with an analysis tool, by indicating which analyses are to be performed." (Daniel Jackson, "Software Abstractions", 2006)

"A model diagram declares some sets and binary relations, and imposes some basic constraints on them. A diagram is a good way to convey the outline of a model, but diagrams aren’t expressive enough to include detailed constraints." (Daniel Jackson, "Software Abstractions", 2006) 

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

"An assertion is a constraint that is intended to follow from the facts of the model. […] Typically, assertions play two different roles. Some express mundane properties that aren’t interesting in their own right; they’re written purely to detect flaws in the model. It’s surprising how effective even a few such assertions can be in uncovering subtle flaws. […] Other assertions express truly essential properties, and are sometimes more fundamental than the facts of the model." (Daniel Jackson, "Software Abstractions", 2006)

"Analysis brings software abstractions to life in three ways. First, it encourages you as you explore, by giving you concrete examples that reinforce intuition and suggest new scenarios. Second, it keeps you honest, by helping you to check as you go along that what you write down means what you think it means. And third, it can reveal subtle fl aws that you might not have discovered until much later (or not at all)." (Daniel Jackson, "Software Abstractions", 2006)

"An abstraction is not a module, or an interface, class, or method; it is a structure, pure and simple - an idea reduced to its essential form. Since the same idea can be reduced to different forms, abstractions are always, in a sense, inventions, even if the ideas they reduce existed before in the world outside the software. The best abstractions, however, capture their underlying ideas so naturally and convincingly that they seem more like discoveries." (Daniel Jackson, "Software Abstractions", 2006)

"Software is built on abstractions. Pick the right ones, and programming will flow naturally from design; modules will have small and simple interfaces; and new functionality will more likely fit in without extensive reorganization […] Pick the wrong ones, and programming will be a series of nasty surprises: interfaces will become baroque and clumsy as they are forced to accommodate unanticipated interactions, and even the simplest of changes will be hard to make." (Daniel Jackson, "Software Abstractions", 2006)

⛩️Alan J Perlis - Collected Quotes

"A language that doesn’t affect the way you think about programming, is not worth knowing." (Alan J Perlis, "Epigrams on Programming", 1982)

"A program without a loop and a structured variable isn’t worth writing." (Alan J Perlis, "Epigrams on Programming", 1982)

"A programming language is low level when its programs require attention to the irrelevant." (Alan J Perlis, "Epigrams on Programming", 1982)

"Adapting old programs to fit new machines usually means adapting new machines to behave like old ones." (Alan J Perlis, "Epigrams on Programming", 1982)

"Computers don’t introduce order anywhere as much as they expose opportunities." (Alan J Perlis, "Epigrams on Programming", 1982)

"Documentation is like term insurance: It satisfies because almost no one who subscribes to it depends on its benefits." (Alan J Perlis, "Epigrams on Programming", 1982)

"Don’t have good ideas if you aren’t willing to be responsible for them." (Alan J Perlis, "Epigrams on Programming", 1982)

"Epigrams retrieve deep semantics from a data base that is all procedure." (Alan J Perlis, "Epigrams on Programming", 1982)

"Every program has (at least) two purposes: the one for which it was written, and another for which it wasn’t." (Alan J Perlis, "Epigrams on Programming", 1982)

"Functions delay binding; data structures induce binding. Moral: Structure data late in the programming process. " (Alan J Perlis, "Epigrams on Programming", 1982)

"If a program manipulates a large amount of data, it does so in a small number of ways." (Alan J Perlis, "Epigrams on Programming", 1982)

"If we believe in data structures, we must believe in independent (hence simultaneous) processing. For why else would we collect items within a structure? Why do we tolerate languages that give us the one without the other?" (Alan J Perlis, "Epigrams on Programming", 1982)

"In programming, everything we do is a special case of something more general — and often we know it too quickly." (Alan J Perlis, "Epigrams on Programming", 1982)

"In seeking the unattainable, simplicity only gets in the way." (Alan J Perlis, "Epigrams on Programming", 1982)

"Interfaces keep things tidy, but don’t accelerate growth: Functions do." (Alan J Perlis, "Epigrams on Programming", 1982)

"It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." (Alan J Perlis, "Epigrams on Programming", 1982)

"It is easier to change the specification to fit the program than vice versa. " (Alan J Perlis, "Epigrams on Programming", 1982)

"It is easier to write an incorrect program than understand a correct one." (Alan J Perlis, "Epigrams on Programming", 1982)

"It is not a language’s weakness but its strengths that control the gradient of its change: Alas, a language never escapes its embryonic sac." (Alan J Perlis, "Epigrams on Programming", 1982)

"Make no mistake about it: Computers process numbers — not symbols. We measure our understanding (and control) by the extent to which we can arithmetize an activity." (Alan J Perlis, "Epigrams on Programming", 1982)

"Making something variable is easy. Controlling duration of constancy is the trick." (Alan J Perlis, "Epigrams on Programming", 1982)

"Most people find the concept of programming obvious, but the doing impossible." (Alan J Perlis, "Epigrams on Programming", 1982)

"Often it is the means that justify the ends: Goals advance technique and technique survives even when goal structures crumble." (Alan J Perlis, "Epigrams on Programming", 1982)

"One can only display complex information in the mind. Like seeing, movement or flow or alteration of view is more important than the static picture, no matter how lovely." (Alan J Perlis, "Epigrams on Programming", 1982)

"Programmers are not to be measured by their ingenuity and their logic but by the completeness of their case analysis." (Alan J Perlis, "Epigrams on Programming", 1982)

"Prolonged contact with the computer turns mathematicians into clerks and vice versa." (Alan J Perlis, "Epigrams on Programming", 1982)

"Recursion is the root of computation since it trades description for time." (Alan J Perlis, "Epigrams on Programming", 1982)

"Simplicity does not precede complexity, but follows it." (Alan J Perlis, "Epigrams on Programming", 1982)

"Software is under a constant tension. Being symbolic it is arbitrarily perfectible; but also it is arbitrarily changeable." (Alan J Perlis, "Epigrams on Programming", 1982)

"Some programming languages manage to absorb change, but withstand progress." (Alan J Perlis, "Epigrams on Programming", 1982)

"Symmetry is a complexity-reducing concept (co-routines include subroutines); seek it everywhere." (Alan J Perlis, "Epigrams on Programming", 1982)

"Systems have sub-systems and sub-systems have sub-systems and so on ad infinitum - which is why we’re always starting over." (Alan J Perlis, "Epigrams on Programming", 1982)

"The cybernetic exchange between man, computer and algorithm is like a game of musical chairs: The frantic search for balance always leaves one of the three standing ill at ease." (Alan J Perlis, "Epigrams on Programming", 1982)

"The goal of computation is the emulation of our synthetic abilities, not the understanding of our analytic ones." (Alan J Perlis, "Epigrams on Programming", 1982)

"The string is a stark data structure and everywhere it is passed there is much duplication of process. It is a perfect vehicle for hiding information." (Alan J Perlis, "Epigrams on Programming", 1982)

"The use of a program to prove the 4-color theorem will not change mathematics - it merely demonstrates that the theorem, a challenge for a century, is probably not important to mathematics." (Alan J Perlis, "Epigrams on Programming", 1982)

"To understand a program you must become both the machine and the program." (Alan J Perlis, "Epigrams on Programming", 1982)

"We kid ourselves if we think that the ratio of procedure to data in an active data-base system can be made arbitrarily small or even kept small." (Alan J Perlis, "Epigrams on Programming", 1982)

"We will never run out of things to program as long as there is a single program around." (Alan J Perlis, "Epigrams on Programming", 1982)

"Wherever there is modularity there is the potential for misunderstanding: Hiding information implies a need to check communication." (Alan J Perlis, "Epigrams on Programming", 1982)

⛩️Yegor Bugayenko - Collected Quotes

"All companies are built as hierarchies, no matter what that holacracy adepts are saying now. It's always a boss on the top and then people who report to him down to the lowest level. Staying on the lowest level is what I always try to avoid. Not only because I have some dignity, but mostly because I am lazy. The lower you are in the hierarchy, the more work you have to do and the less money you get for it. This is how the division of labor works, not only in the software industry." (Yegor Bugayenko, "Code Ahead", 2018)

"Any software project must have a technical leader, who is responsible for all technical decisions made by the team and have enough authority to make them. Responsibility and authority are two mandatory components that must be present in order to make it possible to call such a person an architect." (Yegor Bugayenko, "Code Ahead", 2018)

"Attributing bugs to their authors doesn't make them more responsible, only more scared." (Yegor Bugayenko, "Code Ahead", 2018)

"Automated testing is a safety net that protects the program from its programmers." (Yegor Bugayenko, "Code Ahead", 2018)

"Every conflict must produce a win-win outcome and must never be resolved through a compromise, which makes both sides suffer in some way. Even forcing one side to do what the other side wants is better than a compromise." (Yegor Bugayenko, "Code Ahead", 2018)

"Fixing the system without fixing people that work in it would be a huge trauma for them; they will do everything they can to prevent it from happening." (Yegor Bugayenko, "Code Ahead", 2018)

"It is not loyalty or internal motivation that drives us programmers forward. We must write our code when the road to our personal success is absolutely clear for us and writing high quality code obviously helps us move forward on this road. To make this happen, the management has to define the rules of the game, also known as "process", and make sure they are strictly enforced, which is much more difficult than 'being agile'." (Yegor Bugayenko, "Code Ahead", 2018)

"It's impossible to change the management system without changing the managers who built it. The management is the product of people who created it." (Yegor Bugayenko, "Code Ahead", 2018)

"Just by making the architect role explicit, a team can effectively resolve many technical conflicts." (Yegor Bugayenko, "Code Ahead", 2018)

"Punishment demotivates when it comes from people rather than a system of well-defined rules." (Yegor Bugayenko, "Code Ahead", 2018)

"Quality is a product of a conflict between programmers and testers." (Yegor Bugayenko, "Code Ahead", 2018)

"Quality must be enforced, otherwise it won't happen. We programmers must be required to write tests, otherwise we won't do it." (Yegor Bugayenko, "Code Ahead", 2018)

"Responsibility means an inevitable punishment for mistakes; authority means full power to make them." (Yegor Bugayenko, "Code Ahead", 2018)

"The higher the price of information in a software team, the less effective the team is." (Yegor Bugayenko, "Code Ahead", 2018)

"The job of a tester is to prove that the software is bug free, while it has to be the other way around: The job of a tester is to prove that the software is broken. The better testers are doing their jobs, the more bugs they manage to find and report." (Yegor Bugayenko, "Code Ahead", 2018)

"To make technical decisions, a result-oriented team needs a strong architect and a decision making process, not meetings." (Yegor Bugayenko, "Code Ahead", 2018)

"Very often managers are just a noise, while the real boss is the project, which we work for and which pays us." (Yegor Bugayenko, "Code Ahead", 2018)

"We must not blame programmers for their bugs. They belong to them only until the code is merged to the repository. After that, all bugs are ours!" (Yegor Bugayenko, "Code Ahead", 2018)

"We, newbies and young programmers, don't like chaos because it makes us dependent on experts. We have to beg for information and feel bad." (Yegor Bugayenko, "Code Ahead", 2018)

⛩️Martin Kleppmann - Collected Quotes

"A fault is usually defined as one component of the system deviating from its spec, where - as a failure is when the system as a whole stops providing the required service to the user. It is impossible to reduce the probability of a fault to zero; therefore it is usually best to design fault-tolerance mechanisms that prevent faults from causing failures." (Martin Kleppmann, "Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems", 2015)

"[…] a NoSQL system may find itself accidentally reinventing SQL, albeit in disguise."(Martin Kleppmann, "Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems", 2015)

"An architecture that scales well for a particular application is built around assumptions of which operations will be common and which will be rare - the load parameters. If those assumptions turn out to be wrong, the engineering effort for scaling is at best wasted, and at worst counterproductive." (Martin Kleppmann, "Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems", 2015)

"[…] as software engineers and architects, we also need to have a technically accurate and precise understanding of the various technologies and their trade-offs if we want to build good applications." (Martin Kleppmann, "Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems", 2015)

"[…] building for scale that you don’t need is wasted effort and may lock you into an inflexible design. In effect, it is a form of premature optimization. However, it’s also important to choose the right tool for the job, and different technologies each have their own strengths and weaknesses." (Martin Kleppmann, "Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems", 2015)

"Consensus is one of the most important and fundamental problems in distributed computing. On the surface, it seems simple: informally, the goal is simply to get several nodes to agree on something." (Martin Kleppmann, "Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems", 2015)

"Every legacy system is unpleasant in its own way, and so it is difficult to give general recommendations for dealing with them." (Martin Kleppmann, "Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems", 2015)

"Everybody has an intuitive idea of what it means for something to be reliable or unreliable. For software, typical expectations include: The application performs the function that the user expected. It can tolerate the user making mistakes or using the software in unexpected ways. Its performance is good enough for the required use case, under the expected load and data volume. The system prevents any unauthorized access and abuse." (Martin Kleppmann, "Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems", 2015)

"It would be unwise to assume that faults are rare and simply hope for the best. It is important to consider a wide range of possible faults - even fairly unlikely ones - and to artificially create such situations in your testing environment to see what happens. In distributed systems, suspicion, pessimism, and paranoia pay off." (Martin Kleppmann, "Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems", 2015)

"Reducing response times at very high percentiles is difficult because they are easily affected by random events outside of your control, and the benefits are diminishing." (Martin Kleppmann, "Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems", 2015) 

"Technology is a powerful force in our society. Data, software, and communication can be used for bad: to entrench unfair power structures, to undermine human rights, and to protect vested interests. But they can also be used for good: to make underrepresented people’s voices heard, to create opportunities for everyone, and to avert disasters." (Martin Kleppmann, "Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems", 2015)

"The architecture of systems that operate at large scale is usually highly specific to the application - there is no such thing as a generic, one-size-fits-all scalable architecture (informally known as magic scaling sauce)." (Martin Kleppmann, "Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems", 2015)

"The fact that SQL is more limited in functionality gives the database much more room for automatic optimizations." (Martin Kleppmann, "Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems", 2015)

"The need for data integration often only becomes apparent if you zoom out and consider the dataflows across an entire organization." (Martin Kleppmann, "Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems", 2015)

"This is a deliberate choice in the design of computers: if an internal fault occurs, we prefer a computer to crash completely rather than returning a wrong result, because wrong results are difficult and confusing to deal with. Thus, computers hide the fuzzy physical reality on which they are implemented and present an idealized system model that operates with mathematical perfection." (Martin Kleppmann, "Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems", 2015)

"[...] when measuring performance, it’s worth using percentiles rather than averages. The main advantage of the mean is that it’s easy to calculate, but percentiles are much more meaningful." (Martin Kleppmann, "Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems", 2015)

"When we develop predictive analytics systems, we are not merely automating a human’s decision by using software to specify the rules for when to say yes or no; we are even leaving the rules themselves to be inferred from data. However, the patterns learned by these systems are opaque: even if there is some correlation in the data, we may not know why. If there is a systematic bias in the input to an algorithm, the system will most likely learn and amplify that bias in its output." (Martin Kleppmann, "Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems", 2015)

"Working with distributed systems is fundamentally different from writing software on a single computer - and the main difference is that there are lots of new and exciting ways for things to go wrong." (Martin Kleppmann, "Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems", 2015)

⛩️Titus Winters - Collected Quotes

"A boat without a captain is nothing more than a floating waiting room: unless someone grabs the rudder and starts the engine, it’s just going to drift along aimlessly with the current. A piece of software is just like that boat: if no one pilots it, you’re left with a group of engineers burning up valuable time, just sitting around waiting for something to happen (or worse, still writing code that you don’t need)." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"Code coverage can provide some insight into untested code, but it is not a substitute for thinking critically about how well your system is tested." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"Fixing a bug is much like adding a new feature: the presence of the bug suggests that a case was missing from the initial test suite, and the bug fix should include that missing test case." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"[...] do not underestimate the power of playing the social game. It’s not about tricking or manipulating people; it’s about creating relationships to get things done. Relationships always outlast projects. When you’ve got richer relationships with your coworkers, they’ll be more willing to go the extra mile when you need them." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"Given enough time and enough users, even the most innocuous change will break something; your analysis of the value of that change must incorporate the difficulty in investigating, identifying, and resolving those breakages." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"In a professional software engineering environment, criticism is almost never personal - it’s usually just part of the process of making a better project. The trick is to make sure you (and those around you) understand the difference between a constructive criticism of someone’s creative output and a flat-out assault against someone’s character." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"In addition to developing the proper culture, invest in your testing infrastructure by developing linters, documentation, or other assistance that makes it more difficult to write bad tests." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"In short, performance ratings are indicative only of how a person is performing in their given role at the time they are being evaluated. Ratings, although an important way to measure performance during a specific period, are not predictive of future performance and should not be used to gauge readiness for a future role or qualify an internal candidate for a different team. (They can, however, be used to evaluate whether an employee is properly or improperly slotted on their current team; therefore, they can provide an opportunity to evaluate how to better support an internal candidate moving forward.)" (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"Knowledge is in some ways the most important (though intangible) capital of a software engineering organization, and sharing of that knowledge is crucial for making an organization resilient and redundant in the face of change. A culture that promotes open and honest knowledge sharing distributes that knowledge efficiently across the organization and allows that organization to scale over time. In most cases, investments into easier knowledge sharing reap manyfold dividends over the life of a company." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

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

"One of the broad truths we’ve seen to be true is the idea that finding problems earlier in the developer workflow usually reduces costs." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"People are inherently imperfect - we like to say that humans are mostly a collection of intermittent bugs. But before you can understand the bugs in your coworkers, you need to understand the bugs in yourself. We’re going to ask you to think about your own reactions, behaviors, and attitudes - and in return, we hope you gain some real insight into how to become a more efficient and successful software engineer who spends less energy dealing with people-related problems and more time writing great code." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"Programming is the immediate act of producing code. Software engineering is the set of policies, practices, and tools that are necessary to make that code useful for as long as it needs to be used and allowing collaboration across a team." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"This is what good management is about: 95% observation and listening, and 5% making critical adjustments in just the right place." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"When an engineer refactors the internals of a system without modifying its interface, whether for performance, clarity, or any other reason, the system’s tests shouldn’t need to change. The role of tests in this case is to ensure that the refactoring didn’t change the system’s behavior. Tests that need to be changed during a refactoring indicate that either the change is affecting the system’s behavior and isn’t a pure refactoring, or that the tests were not written at an appropriate level of abstraction." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

⛩️Mark W Maier - Collected Quotes

"A systems approach is one that focuses on the system as a whole, specifically linking value judgments (what is desired) and design decisions (what is feasible). A true systems approach means that the design process includes the 'problem' as well as the solution. The architect seeks a joint problem–solution pair and understands that the problem statement is not fixed when the architectural process starts. At the most fundamental level, systems are collections of different things that together produce results unachievable by the elements alone."  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

"Architecting is both an art and a science - both synthesis and analysis, induction and deduction, and conceptualization and certification - using guidelines from its art and methods from its science. As a process, it is distinguished from systems engineering in its greater use of heuristic reasoning, lesser use of analytics, closer ties to the client, and particular concern with certification of readiness for use."  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

"Architecting is creating and building structures - that is, 'structuring'. Systems architecting is creating and building systems. It strives for fit, balance, and compromise among the tensions of client needs and resources, technology, and multiple stakeholder interests."  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

"Insight, or the ability to structure a complex situation in a way that greatly increases understanding of it, is strongly guided by lessons learned from one’s own or others’ experiences and observations. Given enough lessons, their meaning can be codified into succinct expressions called 'heuristics', a Greek term for guide. Heuristics are an essential complement to analytics, particularly in situations where analysis alone cannot provide either insights or guidelines."  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

"It is generally agreed that increasing complexity is at the heart of the most difficult problems facing today’s systems architecting and engineering. When architects and builders are asked to explain cost overruns and schedule delays, by far the most common, and quite valid, explanation is that the system is much more complex than originally thought. The greater is the complexity, the greater the difficulty. It is important, therefore, to understand what is meant by system complexity if architectural progress is to be made in dealing with it."  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

"Less apparent is that qualitatively different problem-solving techniques are required at high levels of complexity than at low ones. Purely analytical techniques, powerful for the lower levels, can be overwhelmed at the higher ones. At higher levels, architecting methods, experience-based heuristics, abstraction, and integrated modeling must be called into play."  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

"Modeling is the creation of abstractions or representations of the system to predict and analyze performance, costs, schedules, and risks and to provide guidelines for systems research, development, design, manufacture, and management. Modeling is the centerpiece of systems architecting - a mechanism of communication to clients and builders, of design management with engineers and designers, of maintaining system integrity with project management, and of learning for the architect, personally."  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

"Modeling is the fabric of architecting because architecting is at a considerable distance of abstraction from actual construction. The architect does not manipulate the actual elements of construction. The architect builds models that are passed into more detailed design processes. Those processes lead, eventually, to construction drawings or the equivalent and actual system fabrication or coding."  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

"Taking a systems approach means paying close attention to results, the reasons we build a system. Architecture must be grounded in the client’s/user’s/customer’s purpose. Architecture is not just about the structure of components. One of the essential distinguishing features of architectural design versus other sorts of engineering design is the degree to which architectural design embraces results from the perspective of the client/user/customer. The architect does not assume some particular problem formulation, as “requirements” is fixed. The architect engages in joint exploration, ideally directly with the client/user/customer, of what system attributes will yield results worth paying for."  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

"The basic idea behind all of these techniques is to simplify problem solving by concentrating on its essentials. Consolidate and simplify the objectives. Focus on the things with the highest impact, things that determine other things. Put to one side minor issues likely to be resolved by the resolution of major ones. Discard the nonessentials. Model (abstract) the system at as high a level as possible, then progressively reduce the level of abstraction. In short: Simplify!"  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

"This primacy of complexity in system design helps explain why a single 'optimum' seldom if ever exists for such systems. There are just too many variables. There are too many stakeholders and too many conflicting interests. No practical way may exist for obtaining information critical in making a 'best' choice among quite different alternatives."  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

⛩️Eric Evans - Collected Quotes

"A domain model is not a particular diagram; it is the idea that the diagram is intended to convey. It is not just the knowledge in a domain expert’s head; it is a rigorously organized and selective abstraction of that knowledge." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Always remember that the model is not the diagram. The diagram’s purpose is to help communicate and explain the model. The code can serve as a repository of the details of the design." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"But code as a design document does have its limits. It can overwhelm the reader with detail. Although its behavior is unambiguous, that doesn’t mean it is obvious. And the meaning behind a behavior can be hard to convey. […] A document shouldn’t try to do what the code already does well. The code already supplies the detail. It is an exact specification of program behavior. Other documents need to illuminate meaning, to give insight into large-scale structures, and to focus attention on core elements. Documents can clarify design intent when the programming language does not support a straightforward implementation of a concept. Written documents should complement the code and the talking." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Diagrams are a means of communication and explanation, and they facilitate brainstorming. They serve these ends best if they are minimal. Comprehensive diagrams of the entire object model fail to communicate or explain; they overwhelm the reader with detail and they lack meaning." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Domain-driven design is both a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Domain experts are usually not aware of how complex their mental processes are as, in the course of their work, they navigate all these rules, reconcile contradictions, and fill in gaps with common sense. Software can’t do this. It is through knowledge crunching in close collaboration with software experts that the rules are clarified, fleshed out, reconciled, or placed out of scope." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Effective domain modelers are knowledge crunchers. They take a torrent of information and probe for the relevant trickle. They try one organizing idea after another, searching for the simple view that makes sense of the mass. Many models are tried and rejected or transformed. Success comes in an emerging set of abstract concepts that makes sense of all the detail. This distillation is a rigorous expression of the particular knowledge that has been found most relevant." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Extreme Programming recognizes the importance of design decisions, but it strongly resists upfront design. Instead, it puts an admirable effort into communication and improving the project’s ability to change course rapidly. With that ability to react, developers can use the “simplest thing that could work” at any stage of a project and then continuously refactor, making many small design improvements, ultimately arriving at a design that fits the customer’s true needs." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Continuous refactoring is a series of small redesigns; developers without solid design principles will produce a code base that is hard to understand or change—the opposite of agility. And although fear of unanticipated requirements often leads to overengineering, the attempt to avoid overengineering can develop into another fear: a fear of doing any deep design thinking at all." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"If the architecture isolates the domain-related code in a way that allows a cohesive domain design loosely coupled to the rest of the system, then that architecture can probably support domain-driven DESIGN." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"If the design, or some central part of it, does not map to the domain model, that model is of little value, and the correctness of the software is suspect. At the same time, complex mappings between models and design functions are difficult to understand and, in practice, impossible to maintain as the design changes. A deadly divide opens between analysis and design so that insight gained in each of those activities does not feed into the other." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"In fact, XP works best for developers with a sharp design sense. The XP process assumes that you can improve a design by refactoring, and that you will do this often and rapidly. But past design choices make refactoring itself either easier or harder. The XP process attempts to increase team communication, but model and design choices clarify or confuse communication." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Knowledge crunching is an exploration, and you can’t know where you will end up." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Many objects are not fundamentally defined by their attributes, but rather by a thread of continuity and identity." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 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)

"Maps are models, and every model represents some aspect of reality or an idea that is of interest. A model is a simplification. It is an interpretation of reality that abstracts the aspects relevant to solving the problem at hand and ignores extraneous detail." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Models come in many varieties and serve many roles, even those restricted to the context of a software development project. Domain-driven design calls for a model that doesn’t just aid early analysis but is the very foundation of the design […]  Tightly relating the code to an underlying model gives the code meaning and makes the model relevant." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Software design is a constant battle with complexity." (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)

"The technical model that drives the software development process must be strictly pared down to the necessary minimum to fulfill its functions. An explanatory model can include aspects of the domain that provide context that clarifies the more narrowly scoped model. Explanatory models offer the freedom to create much more communicative styles tailored to a particular topic. Visual metaphors used by the domain experts in a field often present clearer explanations, educating developers and harmonizing experts. Explanatory models also present the domain in a way that is simply different, and multiple, diverse explanations help people learn." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"To create software that is valuably involved in users' activities, a development team must bring to bear a body of knowledge related to those activities. The breadth of knowledge required can be daunting. The volume and complexity of information can be overwhelming. Models are tools for grappling with this overload. A model is a selectively simplified and consciously structured form of knowledge. An appropriate model makes sense of information and focuses it on a problem." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Useful models seldom lie on the surface. As we come to understand the domain and the needs of the application, we usually discard superficial model elements that seemed important in the beginning, or we shift their perspective. Subtle abstractions emerge that would not have occurred to us at the outset but that pierce to the heart of the matter." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Well-written code can be very communicative, but the message it communicates is not guaranteed to be accurate. Oh, the reality of the behavior caused by a section of code is inescapable. But a method name can be ambiguous, misleading, or out of date compared to the internals of the method. The assertions in a test are rigorous, but the story told by variable names and the organization of the code is not. Good programming style keeps this connection as direct as possible, but it is still an exercise in self-discipline. It takes fastidiousness to write code that doesn’t just do the right thing but also says the right thing." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"When a design is based on a model that reflects the basic concerns of the users and domain experts, the bones of the design can BE revealed to the user to a greater extent than with other design approaches. Revealing the model gives the user more access to the potential of the software and yields consistent, predictable behavior." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"When we set out to write software, we never know enough. Knowledge on the project is fragmented, scattered among many people and documents, and it’s mixed with other information so that we don’t even know which bits of knowledge we really need. Domains that seem less technically daunting can be deceiving: we don’t realize how much we don’t know. This ignorance leads us to make false assumptions." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

⛩️Michael M Hammer - Collected Quotes

"At the heart of reengineering is the notion of discontinuous thinking—of recognizing and breaking away from the outdated rules and fundamental assumptions that underlie operations. Unless we change these rules, we are merely rearranging the deck chairs on the Titanic. We cannot achieve breakthroughs in performance by cutting fat or automating existing processes. Rather, we must challenge old assumptions and shed the old rules that made the business underperform in the first place." (Michael M Hammer, "Reengineering Work: Don't Automate, Obliterate", Magazine, 1990) [source]

"Conventional process structures are fragmented and piecemeal, and they lack the integration necessary to maintain quality and service. They are breeding grounds for tunnel vision, as people tend to substitute the narrow goals of their particular department for the larger goals of the process as a whole. When work is handed off from person to person and unit to unit, delays and errors are inevitable. Accountability blurs, and critical issues fall between the cracks." (Michael M Hammer, "Reengineering Work: Don't Automate, Obliterate", Magazine, 1990) [source]

"In reengineering, managers break loose from outmoded business processes and the design principles underlying them and create new ones. [...] Reengineering requires looking at the fundamental processes of the business from a cross-functional perspective. [...] The reengineering team must keep asking Why? and What if? Why do we need to get a manager’s signature on a requisition? Is it a control mechanism or a decision point?" (Michael M Hammer, "Reengineering Work: Don't Automate, Obliterate", Magazine, 1990) [source]

"In short, a reengineering effort strives for dramatic levels of improvement. It must break away from conventional wisdom and the constraints of organizational boundaries and should be broad and cross-functional in scope. It should use information technology not to automate an existing process but to enable a new one." (Michael M Hammer, "Reengineering Work: Don't Automate, Obliterate", Magazine, 1990) [source]

"Information technology can capture and process data, and expert systems can to some extent supply knowledge, enabling people to make their own decisions. As the doers become self-managing and self-controlling, hierarchy - and the slowness and bureaucracy associated with it - disappears." (Michael M Hammer, "Reengineering Work: Don't Automate, Obliterate", Magazine, 1990) [source]

"Reengineering cannot be planned meticulously and accomplished in small and cautious steps. It's an all-or-nothing proposition with an uncertain result. Still, most companies have no choice but to muster the courage to do it. For many, reengineering is the only hope for breaking away from the antiquated processes that threaten to drag them down." (Michael M Hammer, "Reengineering Work: Don't Automate, Obliterate", Magazine, 1990) [source]

"Reengineering triggers changes of many kinds, not just of the business process itself. Job designs, organizational structures, management systems - anything associated with the process - must be refashioned in an integrated way. In other words, reengineering is a tremendous effort that mandates change in many areas of the organization." (Michael M Hammer, "Reengineering Work: Don't Automate, Obliterate", Magazine, 1990) [source]

"A business process is a collection of activities that takes one or more kinds of input and creates an output that is of value to the customer. A business process has a goal and is affected by events occurring in the external world or in other processes." (James A Champy & Michael M Hammer, "Reengineering the Corporation", 1993)

"A process perspective sees not individual tasks in isolation, but the entire collection of tasks that contribute to a desired outcome. Narrow points of view are useless in a process context. It just won't do for each person to be concerned exclusively with his or her own limited responsibility, no matter how well these responsibilities are met. When that occurs, the inevitable result is working at cross–purpose, misunderstanding, and the optimization of the part at the expense of the whole. Process work requires that everyone involved be directed toward a common goal; otherwise, conflicting objectives and parochial agendas impair the effort."  (James A Champy & Michael M Hammer, "Reengineering the Corporation", 1993)

"'Automating a mess yields an automated mess.' Unless an organization reconceptualized its operations, overlaying new technology on these operations accomplished little." (James A Champy & Michael M Hammer, "Reengineering the Corporation", 1993)

"Business reengineering isn't about fixing anything. Business reengineering means starting all over, starting from scratch. Business reengineering means putting aside much of the received wisdom of two hundred years of industrial management [...] How people and companies did things yesterday doesn't matter to the business reengineer." (James A Champy & Michael M Hammer, "Reengineering the Corporation", 1993)

"Reengineering is the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical contemporary measures of performance such as cost, quality, service and speed." (James A Champy & Michael M Hammer, "Reengineering the Corporation", 1993)

"Reengineering posits a radical new principle: that the design of work must be based not on hierarchical management and the specialization of labor but on end-to-end processes and the creation of value for the customer." (James A Champy & Michael M Hammer, "Reengineering the Corporation", 1993)

"To succeed at reengineering, you have to be a missionary, a motivator, and a leg breaker." (Michael M Hammer, Fortune, August 1993)

⛩️Robert C Martin - Collected Quotes

"A system that is comprehensively tested and passes all of its tests all of the time is a testable system. That’s an obvious statement, but an important one. Systems that aren’t testable aren’t verifiable. Arguably, a system that cannot be verified should never be deployed." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Any comment that forces you to look in another module for the meaning of that comment has failed to communicate to you and is not worth the bits it consumes." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008) 

"Clean code is focused. Each function, each class, each module exposes a single-minded attitude that remains entirely undistracted, and unpolluted, by the surrounding details."  (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Clean code is not written by following a set of rules. You don’t become a software craftsman by learning a list of heuristics. Professionalism and craftsmanship come from values that drive disciplines." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Code formatting is important. It is too important to ignore and it is too important to treat religiously. Code formatting is about communication, and communication is the professional developer’s first order of business."  (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Duplication is the primary enemy of a well-designed system. It represents additional work, additional risk, and additional unnecessary complexity."  (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Every system is built from a domain-specific language designed by the programmers to describe that system. Functions are the verbs of that language, and classes are the nouns."  (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

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

"If the discipline of requirements specification has taught us anything, it is that well-specified requirements are as formal as code and can act as executable tests of that code!"  (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"In an ideal system, we incorporate new features by extending the system, not by making modifications to existing code." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. [… Therefore,] making it easy to read makes it easier to write." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008) 

"It is a myth that we can get systems 'right the first time'. Instead, we should implement only today’s stories, then refactor and expand the system to implement new stories tomorrow. This is the essence of iterative and incremental agility. Test-driven development, refactoring, and the clean code they produce make this work at the code level." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"It is not enough for code to work. Code that works is often badly broken. Programmers who satisfy themselves with merely working code are behaving unprofessionally. They may fear that they don’t have time to improve the structure and design of their code, but I disagree. Nothing has a more profound and long-term degrading effect upon a development project than bad code." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"It is unit tests that keep our code flexible, maintainable, and reusable. The reason is simple. If you have tests, you do not fear making changes to the code! Without tests every change is a possible bug."  (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Nothing has a more profound and long-term degrading effect upon a development project than bad code. Bad schedules can be redone, bad requirements can be redefined. Bad team dynamics can be repaired. But bad code rots and ferments, becoming an inexorable weight that drags the team down." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"One difference between a smart programmer and a professional programmer is that the professional understands that clarity is king. Professionals use their powers for good and write code that others can understand." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008) 

"One of the best ways to ruin a program is to make massive changes to its structure in the name of improvement. Some programs never recover from such “improvements.” The problem is that it’s very hard to get the program working the same way it worked before the 'improvement'." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Refactoring is a lot like solving a Rubik’s cube. There are lots of little steps required to achieve a large goal. Each step enables the next." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 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)

"The majority of the cost of a software project is in long-term maintenance. In order to minimize the potential for defects as we introduce change, it’s critical for us to be able to understand what a system does. As systems become more complex, they take more and more time for a developer to understand, and there is an ever greater opportunity for a misunderstanding. Therefore, code should clearly express the intent of its author. The clearer the author can make the code, the less time others will have to spend understanding it. This will reduce defects and shrink the cost of maintenance." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"The problem isn’t the simplicity of the code but the implicity of the code (to coin a phrase): the degree to which the context is not explicit in the code itself." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"There are two parts to learning craftsmanship: knowledge and work. You must gain the knowledge of principles, patterns, practices, and heuristics that a craftsman knows, and you must also grind that knowledge into your fingers, eyes, and gut by working hard and practicing." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"We do not want to expose the details of our data. Rather we want to express our data in abstract terms. This is not merely accomplished by using interfaces and/or getters and setters. Serious thought needs to be put into the best way to represent the data that an object contains. The worst option is to blithely add getters and setters." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"When people look under the hood, we want them to be impressed with the neatness, consistency, and attention to detail that they perceive. We want them to be struck by the orderliness. We want their eyebrows to rise as they scroll through the modules. We want them to perceive that professionals have been at work. If instead they see a scrambled mass of code that looks like it was written by a bevy of drunken sailors, then they are likely to conclude that the same inattention to detail pervades every other aspect of the project." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Whether you are designing systems or individual modules, never forget to use the simplest thing that can possibly work." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Yet attentiveness to detail is an even more critical foundation of professionalism than is any grand vision. First, it is through practice in the small that professionals gain proficiency and trust for practice in the large. Second, the smallest bit of sloppy construction, of the door that does not close tightly or the slightly crooked tile on the floor, or even the messy desk, completely dispels the charm of the larger whole. That is what clean code is about." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"You should choose a set of simple rules that govern the format of your code, and then you should consistently apply those rules. If you are working on a team, then the team should agree to a single set of formatting rules and all members should comply." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Acceptance tests are not unit tests. Unit tests are written by programmers for programmers. They are formal design documents that describe the lowest level structure and behavior of the code. The audience is programmers, not business. Acceptance tests are written by the business for the business (even when you, the developer, end up writing them). They are formal requirements documents that specify how the system should behave from the business’ point of view. The audience is the business and the programmers." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Coding is an intellectually challenging and exhausting activity. It requires a level of concentration and focus that few other disciplines require. The reason for this is that coding requires you to juggle many competing factors at once." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"Following the principle of 'late precision', acceptance tests should be written as late as possible, typically a few days before the feature is implemented. In Agile projects, the tests are written after the features have been selected for the next Iteration or Sprint." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

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

"One of the most common communication issues between programmers and business is the requirements. The business people state what they believe they need, and then the programmers build what they believe the business described. At least that’s how it’s supposed to work. In reality, the communication of requirements is extremely difficult, and the process is fraught with error." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"One of the worst symptoms of a dysfunctional team is when each programmer builds a wall around his code and refuses to let other programmers touch it." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"Programming is an act of creation. When we write code we are creating something out of nothing. We are boldly imposing order upon chaos. We are confidently commanding, in precise detail, the behaviors of a machine that could otherwise do incalculable damage. And so, programming is an act of supreme arrogance." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"Software development is a marathon, not a sprint. You can’t win the race by trying to run as fast as you can from the outset. You win by conserving your resources and pacing yourself. A marathon runner takes care of her body both before and during the race. Professional programmers conserve their energy and creativity with the same care." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"The cost of automating acceptance tests is so small in comparison to the cost of executing manual test plans that it makes no economic sense to write scripts for humans to execute. Professional developers take responsibility for their part in ensuring that acceptance tests are automated." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"The fact that bugs will certainly occur in your code does not mean you aren’t responsible for them. The fact that the task to write perfect software is virtually impossible does not mean you aren’t responsible for the imperfection." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"The fundamental assumption underlying all software projects is that software is easy to change. If you violate this assumption by creating inflexible structures, then you undercut the economic model that the entire industry is based on." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"The purpose of acceptance tests is communication, clarity, and precision. By agreeing to them, the developers, stakeholders, and testers all understand what the plan for the system behavior is. Achieving this kind of clarity is the responsibility of all parties. Professional developers make it their responsibility to work with stakeholders and testers to ensure that all parties know what is about to be built." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"The second best way to learn is to collaborate with other people. Professional software developers make a special effort to program together, practice together, design and plan together. By doing so they learn a lot from each other, and they get more done faster with fewer errors." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"The true professional knows that delivering function at the expense of structure is a fool’s errand. It is the structure of your code that allows it to be flexible. If you compromise the structure, you compromise the future." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"True professionals work hard to keep their skills sharp and ready. It is not enough to simply do your daily job and call that practice. Doing your daily job is performance, not practice. Practice is when you specifically exercise your skills outside of the performance of your job for the sole purpose of refining and enhancing those skills." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"Unfortunately, all too many projects become mired in a tar pit of poor structure. Tasks that used to take days begin to take weeks, and then months. Management, desperate to recapture lost momentum, hires more developers to speed things up. But these developers simply add to the morass, deepening the structural damage and raising the impediment." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011) 

"When you cannot concentrate and focus sufficiently, the code you write will be wrong. It will have bugs. It will have the wrong structure. It will be opaque and convoluted. It will not solve the customers’ real problems. In short, it will have to be reworked or redone. Working while distracted creates waste." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"[…] you should not agree to work overtime unless (1) you can personally afford it, (2) it is short term, two weeks or less, and (3) your boss has a fall-back plan in case the overtime effort fails." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"Function or architecture? Which of these two provides the greater value? Is it more important for the software system to work, or is it more important for the software system to be easy to change?" (Robert C Martin, "Clean Architecture: A Craftsman's Guide to Software Structure and Design", 2017)

"Getting software right is hard. It takes knowledge and skills that most young programmers haven’t yet acquired. It requires thought and insight that most programmers don’t take the time to develop. It requires a level of discipline and dedication that most programmers never dreamed they’d need. Mostly, it takes a passion for the craft and the desire to be a professional." (Robert C Martin, "Clean Architecture: A Craftsman's Guide to Software Structure and Design", 2017)

"Software architects are, by virtue of their job description, more focused on the structure of the system than on its features and functions. Architects create an architecture that allows those features and functions to be easily developed, easily modified, and easily extended." (Robert C Martin, "Clean Architecture: A Craftsman's Guide to Software Structure and Design", 2017)

"The bigger lie that developers buy into is the notion that writing messy code makes them go fast in the short term, and just slows them down in the long term. Developers who accept this lie exhibit the hare’s overconfidence in their ability to switch modes from making messes to cleaning up messes sometime in the future, but they also make a simple error of fact. The fact is that making messes is always slower than staying clean, no matter which time scale you are using." (Robert C Martin, "Clean Architecture: A Craftsman's Guide to Software Structure and Design", 2017)

"The goal of software architecture is to minimize the human resources required to build and maintain the required system." (Robert C Martin, "Clean Architecture: A Craftsman's Guide to Software Structure and Design", 2017)

"What is OO? There are many opinions and many answers to this question. To the software architect, however, the answer is clear: OO is the ability, through the use of polymorphism, to gain absolute control over every source code dependency in the system. It allows the architect to create a plugin architecture, in which modules that contain high-level policies are independent of modules that contain low-level details. The low-level details are relegated to plugin modules that can be deployed and developed independently from the modules that contain high-level policies." (Robert C Martin, "Clean Architecture: A Craftsman's Guide to Software Structure and Design", 2017)

"When software is done right, it requires a fraction of the human resources to create and maintain. Changes are simple and rapid. Defects are few and far between. Effort is minimized, and functionality and flexibility are maximized." (Robert C Martin, "Clean Architecture: A Craftsman's Guide to Software Structure and Design", 2017)

"When we talk about software architecture, software is recursive and fractal in nature, etched and sketched in code. Everything is details. Interlocking levels of detail also contribute to a building’s architecture, but it doesn’t make sense to talk about physical scale in software. Software has structure - many structures and many kinds of structures-but its variety eclipses the range of physical structure found in buildings. You can even argue quite convincingly that there is more design activity and focus in software than in building architecture - in this sense, it’s not unreasonable to consider software architecture more architectural than building architecture!" (Robert C Martin, "Clean Architecture: A Craftsman's Guide to Software Structure and Design", 2017)