Degrees of freedom analysis

1 December 20091 December 2009 cyrille 1 Comment

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 in maths

The concept of DOF is central in solving systems of linear equations, and in the main post of his series, Michael L. Perry starts by focusing on mathematical system of linear equations:

A mathematical model of a problem is written with equations and unknowns. You can think of the number of unknowns as representing the number of dimensions in the problem.

Depending on the number m of equations compared to the number n of unknowns (variables), there are several cases:

m > n: there is no solution, the problem is over-constrained
m = n: there is only one solution
m < n: the system is under-determined system, and the dimension of the solution set is usually equal to n ? m, where n is the number of variables and m is the number of equations.

A common concept in mechanics

3 legs are enough to be stable, but tables usually have 4 legs anyway.

The concept of DOF is prevalent in mechanics. In particular, a system with more internal constraints than the total possible number of DOFs has no solution. However in practice it can still work, provided some of the bodies are not absolutely rigid.

The table is often given as an example, because it only needs three legs to be stable on the ground, but usually has 4 legs. This only works because the table is not fully rigid, and can accommodate the small imperfection of the ground.

Not yet common in software

In his post, Michael L. Perry explains in practice how to analyse software using DOF. First find the unknowns:

To identify the degrees of freedom in software, start by defining the unknowns. These are usually pretty simple to spot. These are the things that can change. In a checkbook program, for example, each transaction amount is an unknown, as are the the account balance and the color used to display it (black or red).

Then find out the constraints between the DOFs.

Next, define the equations. These are the relationships between the unknowns that the software has to enforce. In the checkbook, the balance is the sum of all transaction amounts. And the color is red if the balance is negative or black otherwise.

Finally:

Subtract to find your degrees of freedom. One amount per transaction (n), one balance, and one color gives n+2 unknowns. The balance sum and the color rule give us two equations. n+2-2 = n degrees of freedom, one per transaction.

What for?

Quoting again Michael L. Perry (across various posts in the DOF category):

Understanding the degrees of freedom in the software helps to create a maintainable design.

Adding independent data to a system increases its degrees of freedom. Adding dependent data does not. Adding an immutable field does not.

You want no more degrees of freedom in the system than the problem calls for.

The concept of degree of freedom is remarkably useful to help distilling the domain down to the essential variable parts and the constraints between them. Any extra independent data can only create opportunities for bugs.

Essential patterns books for today object-oriented developers

13 January 200929 September 2010 admin 2 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 they offer a standard vocabulary but they also help structuring the mind by their relationships: patterns can be related as exclusive alternatives, or rather often-go-together, which is useful.

Patterns are not always supposed to be “tricks” to learn, or extra complication to introduce to a design; indeed even obvious and uninteresting pattern are worth reading in books, just for the social advantage of being able to reference them. Going further, sometime you can just go to the book to find out which is the pattern that you just did without knowing its name…

1. Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing Series) by Erich Gamma et al.


	The most essential book, a definitive must-have. Every experienced software developer must know these 23 design patterns.

2. Analysis Patterns: Reusable Object Models (Addison-Wesley Object Technology Series) by Martin Fowler


	The essential complement to the GoF, to extend the benefits of patterns from design to analysis (closer to the problem to solve in the domain). Each pattern will not necessarily teach you a new solution, but will always give you have a standard name for each solution, which is already worth the book.

3. Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans


	A book that can change the way you deal with software. Considering the domain as the main driver of the design is so powerful an approach! Works best together with the analysis patterns.

4. Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series) by Martin Fowler


	Other analysis patterns to solve many technical problems, useful complement to Analysis Patterns.

5. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley Signature Series) by Gregor Hohpe


	Very complete pattern language (both test and visual vocabulary) about messaging, will improve the communication within a team a lot, both in efficiency and in accuracy.

6. Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects by Douglas Schmidt


	Important book, more specialized toward optimized low-level problems (web servers…). often quoted. The other volumes are less relevant for today software development on modern languages or virtual machines.

7. Patterns in Java: A Catalog of Reusable Design Patterns Illustrated with UML, 2nd Edition, Volume 1 by Mark Grand


	The book I discovered design patterns in, quite affordable, but some colleagues do not like it that much.

Software development is more than mastering syntax

28 June 20055 January 2009 cyrille

When a junior developer joins our team, it is interesting to realize how mastering language syntax and API is just a small part of the skills that matter.

Just after the syntax and API knowledge (actually knowing where to find what you want in the API is enough), there are a few other skills you definitely must know.

First is unit test. It is not difficult to begin with that, it is not that easy to tune tests so that they dont depend on too many things, to save time when refactoring. Also mocking objects is the next step.

Mastering dependencies is another key to successful software development. Dependency Injection is a buzzword for a very simple idea, that everyone can apply only by being aware to do the ”new” where is it most convenient to change, using valued constructors or setters.

Design patterns are of course an essential tool to build flexible software. Everytime there is a design problem, design and analysis patterns often provide a good solution. They also guide you to good object-oriented thinking. However, when there is no design problem, there is no need for patterns.

The last very important thing to understand in software development is to look for simplicity, always. It is easy to build a complicated solution, it is difficult to build a simple one. But a simple solution has so many advantages… To simplify a design, domain analysis is a great tool; the more you understand the domain, the best you can align your design to it, and the simplest it will be. By separating orthogonal things or by unifying similar things you can also simplify.

There are also things that we must unlearn, like doing design first and testing at the very end of a project; it is most of the time also useless to create extensive UML diagrams, good design can hardly come from diagrams, if you are not close enough to the code you may miss the point and have a flawed design, even though it looks great as a diagram.

It is counter-intuitive to beginners to focus on anything but syntax. Therefore, unless you have a colleague to introduce you to other concerns, or unless you are really motivated to look for advises on the Internet, you can live a long time without even knowing there is more than that…

Initially published on Jroller on Tuesday June 28, 2005

What’s wrong with Design Patterns ?

25 April 20055 January 2009 cyrille

I’m a big fan of design patterns, they do make my work easier, more explicit, more maintenable and also more enjoyable; however I’m surprised that not everyone knows them and actually uses them. What’s wrong with design patterns ?

Some facts:

they are difficult to learn and to teach, it is nearly impossible to teach design patterns at school unless students already have significant hands-on practice of software development, unless they already encountered real-world problems
they are difficult to implement correctly when you start with them, you often misuse them at first tries
they do not match the way many people think about software, many people still resist to them, they think using design patterns is counter-intuitive (this is especially true if you started your carrer with a procedural point of view, how many times people tell me: “using patterns or not, it is the same at the end of the day in the software !”)
once you know them, you are impressed at the power and expressiveness they give you, so you tend to overuse them

Since I’m still convinced design patterns MUST be known by any professional developer today, what are the best ways to learn or teach them ?

There is no magic answer, however these are some clues:
mentoring is undoubtedly the best way to learn design patterns; so the best way to learn them is to find coworkers that know them more than you do; it is even better to work on the same part of the software to really get the point in using, -or not using- patterns (pair programming ?)
If patterns have to be taught in a classroom environment to people that already have work experience (as in company internal training sessions), it is worthless to describe and explain the catalog of patterns, you’d better explain what you found difficult or confusing when you were learning them, this is much more valuable for your audience. For instance, explain that the intent of a pattern comes first, that yes it is normal that the UML diagrams may be the same for two or three patterns, because their intent is different, that yes they are already using some patterns without even being aware of it… I think presenting patterns through refactoring examples should also be very relevant since the value-added of patterns is more obvious.
Maybe design patterns are too abstract to be learnt directly (1); as usual when abstraction is a problem, we should then focus on more concrete examples (or instances). In the case of design patterns, more concrete examples may be J2EE patterns (it is very surprising to see that many people know much more about J2EE patterns than fundamental GoF patterns !), or Analysis Patterns that derive from design patterns and that solve a particular domain problem. Once the apprentice knows enough such concrete patterns, it becomes easier to describe the abstract pattern that sums them all.

(1) Actually one strength of design patterns is that they are abstract enough to be reusable to a great extent.

Initially published on Jroller on Monday April 25, 2005