"The XP philosophy is to start where you are now and move towards the ideal. From where you are now, could you improve a little bit?" (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)
"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)
"Enterprise-architecture is the integration of everything the enterprise is and does. Even the term ‘architecture’ is perhaps a little misleading. It’s on a much larger scale, the scale of the whole rather than of single subsystems: more akin to city-planning than to the architecture of a single building. In something this large, there are no simple states of ‘as-is’ versus ‘to-be’, because its world is dynamic, not static. And it has to find some way to manage the messy confusion of what is, rather than the ideal that we might like it to be." (Tom Graves, "Real Enterprise-Architecture : Beyond IT to the whole enterprise", 2007)
"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)
"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)
"Many processes in software development are repetitive and easily automated. The DRY principle applies in these contexts, as well as in the source code of the application. Manual testing is slow, error-prone, and difficult to repeat, so automated test suites should be used where possible. Integrating software can be time consuming and error-prone if done manually, so a build process should be run as frequently as possible, ideally with every check-in. Wherever painful manual processes exist that can be automated, they should be automated and standardized. The goal is to ensure that there is only one way of accomplishing the task, and it is as painless as possible." (Steve Smith, [in Kevlin Henney’s "97 Things Every Programmer Should Know", 2010])
"A model is an abstraction of the system being studied rather than an alternative representation of that system. Ideally, a representation of a system should maintain all the information about the entity being represented. An abstraction deliberately simplifies and picks out the most salient characteristics." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)
"The conceptual model is not the users' mental model of the application. [...] users of an application form mental models of it to allow them to predict its behavior. A mental model is the user's high-level understanding of how the application works; it allows the user to predict what the application will do in response to various user-actions. Ideally, a user's mental model of an application should be similar to the designers' conceptual model, but in practice the two models may differ signicantly. Even if a user-s mental model is the same as the designer's conceptual model, they are distinct models." (Jeff Johnson & Austin Henderson, "Conceptual Models", 2011)
"Agile teams often do not distinguish between bugs, enhancements, or change requests. They use a general unit called change to track progress. Change seems to be a valid unit for both development and operations because operations teams primarily think in terms of changes to the production system. Using changes as a shared term for both development and operations makes it easier to stream production issues back to a work backlog (that is ideally shared by both groups)." (Michael Hüttermann et al, "DevOps for Developers", 2013)
"Software systems are prone to the build up of cruft - deficiencies in internal quality that make it harder than it would ideally be to modify and extend the system further. Technical Debt is a metaphor […] that frames how to think about dealing with this cruft, thinking of it like a financial debt. The extra effort that it takes to add new features is the interest paid on the debt." (Martin Fowler,"Technical Debt", 2019)
No comments:
Post a Comment