The concept of degrees of freedom looks so relevant to software development that I am wondering why it is not considered more often. Fortunately Michael L. Perry dedicates a full section of his blog to that concept. In this post I will quote a lot, please consider that as a sign of enthusiasm. A common [...]
Continue Reading »
Tags: analysis, ddd, design, dof, domain, education, maths, methodology, problem, Programming, solution
Posted in Programming • 1 Comment »
For tools to be aware of patterns, the patterns must be formalized, at least partially. At this point I must quote Gregor Hohpe to clarify my thoughts, as I strongly agree with his skipticism: Typically, when people ask me about « codifying » or « toolifying » patterns my first reaction is one of skepticism. Patterns are meant to [...]
Continue Reading »
Tags: abstraction, classdiagram, dependencies, design, intent, pattern, patternity, problem, Programming, sequencediagram, solution, tree
Posted in Patternity, Patterns, Programming • Comments Off
Over time, patterns have appeared on many different topics, not all related to programming. Here is a list of patterns and pointers to other lists of patterns, to illustrate two things: Knowledge and experience in general can be packaged into patterns, often using the pattern form. Patterns are convenient for reuse, in any domain. There [...]
Continue Reading »
Tags: design, domain, pattern, patternity, problem, Programming, solution
Posted in Patternity, Patterns, Programming • 1 Comment »
In nature, out of every possible arrangement of several elements, only a few arrangements are stable. This is illustrated with atoms combined together, or smaller particles arranged together into atoms, where not every combination is sustainable. Unstable arrangements tend to move toward stable ones over time. Whenever you observe the elements, you mostly see stable [...]
Continue Reading »
Tags: abstraction, pattern, patternity, Programming, research, solution, tool
Posted in Patternity, Patterns, Programming • 1 Comment »
There is great power in being able to manipulate collective things as one single thing. It gives you simplicity, hence control. You can focus your attention on it and reason about it, even though behind the hood it is made of many parts. The composite thing is kept simple, therefore you can also deal with [...]
Continue Reading »
Tags: abstraction, classification, collective, design, group, methodology, multiplicity, pattern, problem, Programming, solution, solving
Posted in General, Patterns, Programming • Comments Off
The more patterns developers know, the most efficient they become within a team: it only takes one or two words (the pattern name) to communicate a design decision or proposal, instead of 10 mn of explanations. Communication also gets much more accurate and to-the-point (or less fuzzy). Because patterns often form a pattern language, not [...]
Continue Reading »
Tags: analysis, book, design, domain, education, java, pattern, problem, Programming, solution
Posted in Patterns • 2 Comments »
In any order management systems a quote is not quite different of an order, just a different status of the same entity that is the description of a work to be done (status = POTENTIAL) or done (status = COMPLETED). However I usually find people are tempted to consider they are different concept with no [...]
Continue Reading »
Tags: abstraction, analysis, problem, solution
Posted in Programming • 2 Comments »