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 concept [...]
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 be [...]
Continue Reading »
Tags: abstraction, classdiagram, dependencies, design, intent, pattern, patternity, problem, Programming, sequencediagram, solution, tree
Posted in Patternity, Patterns, Programming • No Comments »
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 are already [...]
Continue Reading »
Tags: design, domain, pattern, patternity, problem, Programming, solution
Posted in Patternity, Patterns, Programming • 1 Comment »
In my very first job, I was doing R&D, working on a map-matching algorithm. The goal of this algorithm was to pinpoint a moving car on a vector map, based on the data from various sensors, including a GPS, an electronic compass and the car odometer. Such algorithm was essential for the business of the [...]
Continue Reading »
Tags: abstraction, analysis, design, methodology, pattern, problem, Programming, research, uml
Posted in Patterns, Programming • No Comments »
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, Physical Computing, Programming • No Comments »
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 only [...]
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 »