Jan Willem Tulp’s blog

Butter & Marge: A Tale of Two Spreads from Outside Line on Vimeo.

From http://www.flickr.com/photos/robotjohnny/3629069606/sizes/o/

At backspace.com a great introduction to Info Graphic Design is posted as PDF document. Click here to check it out!!

A few days ago New Scientist has published a great Info Graphic that illustrates the mass consumption of earth’s resources. Although the Info Graphic is great, its message is quite a scary one…

Click for a full size image…

According to several EU directives, light bulbs, white good, cars and even homes must have energy labels. These labels indicate the energy efficiency in a range from A to G, where A is the most efficient and G is the least efficient. Yesterday I was discussing my current software project with a colleague, and we concluded that they way we’ve divided our project into components is a very flexible one. And because it is so flexible, our software has become very durable, because you can replace one component with a new one, without affecting all the others in any way, as long as the functionality of the software is not changed. And because durability is a hot environmental topic today, we thought that energy-label-like quality ratings for software would not be such a bad idea.

I believe that today there is no such thing as a standardized labeling system for software indicating the quality of the software.Wouldn’t it be a nice thing for customers to see that their software suppliers deliver A quality (durable) software instead of G quality (unmaintainable spaghetti code)? And I believe that one of the key factors in creating durable software is managing your dependencies well. As soon as one component becomes entangled with another one, you’ve already lost some of your flexibility.

I’ve read the book Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin quite some time ago. He explains really well how to handle package or component dependencies, but it wasn’t until my current project that it really got through to me.

The following are my own set of guidelines for deciding how to separate my project into components. It works really well for me:

1. Create one or more domain components
These components should have NO dependencies on frameworks, implementations, XML, or what so ever. These components will most likely contain interfaces, and domain logic. These components should capture the (abstraction of) the functionality of your application. And most important: no dependencies to implementations or frameworks!!

2. Create well isolated implementation components
Implement your domain logic in separate components. And don’t put ALL of the implementation in 1 component. For example, if your application has a view and some sort of data storage that should be used by your domain logic, create a separate view implementation component and a separate data source component. If you would have put them in the same component, your view depends on the data source implementation which is not a good thing.

3. Don’t fall back on shortcuts, it will never help you in the end
Once you use shortcuts or the fastest solution instead of the best solution, software durability and flexibility drops, especially if you create dependencies between components. If you think “oh well, lets just implement the quickest way to pass this extra information” while this information is not related to this component, you mix up responsibilities, create unwanted dependencies, and eventually you’ll end up with a highly entangled product. So be aware of shortcuts!

4. Think: “can I replace this component without affecting something unrelated”
This is a thought I keep in my mind constantly. For our front-end application we used to have only 1 component. Now we’ve separated this application into components with their own responsibilities and their own dependencies. This increased the durability of out application immensely. As long as the functionality of our application does not change, one can decide to use a different front-end framework, while the rest of the components can remain.

5. Think composition
You’re almost always better of composing your application out of small components than creating one bulky component that does all. Being able to compose your application is the path to flexibility.

Creating a highly durable product is fun and very satisfying. Summarized I would recommend: no shortcuts, separate responsibilities, domain logic with no dependencies, application composition.

Being a piano player, I like to follow technological development of digital stage pianos. Every year at NAMM, the National Association of Music Merchants, vendors of musical instruments always show their latest products. I usually go to a music store to check out some of the new instruments I like. Although I’ve only checked out one of them, these two new products have already entered my wishlist:

- the Roland V-Piano
- the Nord Stage EX

Watch this guy play amazingly funky music on a Nord Electro 3:

Here is a great visualization of the financial crisis, by Jonathan Jarvis:



The Crisis of Credit Visualized from Jonathan Jarvis on Vimeo.


And for an overview of more visualizations of the financial crisis, see one of my favorite websites: Flowing Data

This is going to a somewhat technical post, be warned

Currently I am working on a project where I have to build a web application that allows users to search a large database with user data (an LDAP database). This web application is actually composed of 2 separate applications that communicate with each other using a Web Service. One of them you can call a front-end application, which contains the web pages, the front-end logic (like sorting results) and a client for the Web Service. And you can call the other one the back-end application, which hosts the web service, the domain logic and the logic for communicating with LDAP. In this post I want to focus on layering in the back-end application.

When I write software, there are always good software design principles in my head, like: keep methods short, make your code readable, seperation of concerns, minimize the side effects, etc. Now, in deciding how to package my back-end application into deployable components, I learned some great lessons from the design principles by Robert C. Martin (Uncle Bob). And especially the fact that different parts of the application may evolve at different speeds helped me to decide to define the components.

Now in this application I actually had 3 components:

• a Web Service component that exposes the domain logic to the outside world
• a domain component that contains all the domain logic of search for user data
• an LDAP component that implements the domain logic using LDAP specifics

And to have maximum flexibility, I wired the dependencies like this:

• the Web Service component only knows about the the domain component, since it’s only purpose is to expose domain logic to the outside world. The Web Service component doesn’t know anything about how the domain component does that, so it could be an LDAP database, a SQL database, text files, some over enthusiastic employee typing in responses in real-time, etc.
• the domain component only knows about itself. It even doesn’t know anything about external frameworks
• the LDAP component only know about the domain component, since the purpose of the LDAP component is to implement the domain logic using LDAP
• all these components are wired using Dependency Injection, which means that these components are connected to each other by means of an external configuration file

This setup makes the design extremely flexible, and these components now can evolve separately from each other without breaking (or just re-deploying) the other components. It also allows for swapping components, like using a REST Web Service instead of a SOAP Web Service to expose the domain logic to the outside world without touching the other ones. And using a SQL database instead of the current LDAP database without touching the other components.

Though I am quite content with this separation of concerns, this flexibility, and this independence, yesterday I ran into a point where I decided to create another component, namely, a specific LDAP component. The reason for this is the following: the current LDAP database we’re using contains inconsistent data. There are many parties responsible for delivering their own data to this LDAP database, without complying to certain standards (at least they appear not to be strict enough). The result is that the LDAP database is cluttered with attributes that are filled for one person, and left out for another person. In order to deal with these inconsistencies, I had to write some logic that deals with this.

But the point is this: this logic that deals with these specific inconsistencies, is not representative for all LDAP implementations. You can see this kind of logic as some sort of anti-corruption layer. The general purpose LDAP logic is now located in the other LDAP component, and specifics for dealing with inconsistent data is now located in this new LDAP component. With regards to flexibility this decision means that you can swap from one LDAP implementation to another without touching the original LDAP component. Or it could also mean that if the organization manages to fix the data so that it is consistent again, this new LDAP component is the only one that needs to be modified (or it may even become obsolete).

Even though I am quite satisfied with this decision, more components also means a need for more decisions: “where should I put this piece of logic, is it general purpose LDAP or is it specific LDAP?”. The direction of my thinking is to make the general purpose LDAP component implement the domain logic as much as possible, and then only put the exceptions in the specific LDAP component.

Anyway, it’s really nice to think about layering, responsibilities and dependencies, and trying to make it as flexible and independent as possible.

Currently I am creating an Excel sheet that I am using to monitor the progress of the project I am currently working. Working on this Excel sheet made me aware of some common mistakes people often make while making estimations. Here are 3 of the most common mistakes:

1. Forgetting that you will probably NOT be working full time on your project.
When you work 8 hours a day, it is often the case that you won’t be working 8 hours full time on your project. People disturb you, you have some meetings you need to attend, you spend some time answering email, you’ve got a brainstorm session, you need to go out to meet the customer, etc. Not working full time on your project means that your focus factor is not 100%. If you call everything else a ‘disturbance’ of effective work time, it might be interesting to figure out how much of your time is spent on disturbances and how much of your time is effectively spent on your project. The project I am currently working on will eventually turn out to have a focus factor of around 80%, which means that 20% of my time at work is spent at meetings, etc.

2. Forgetting the number of hours you have available
If you’re working in a team where some of your team members are part time employees, you will have less available hours to get the work done than a team consisting only of full time employees. Although this sounds logical, available hours is something that is quite often not taken into account.

3. Forgetting that productivity / speed will change over time and can be hard to estimate in advance.
If you’re starting a project with a new team, it will be difficult to estimate how fast your team will work. Once you have worked together for some time, you will (if you measure it) gain some knowledge of how much work your team can complete in a certain period of time. Without this experience as a team, you have to base your estimation on wild guesses and experience with other teams that may be different than this one. It is also very hard to estimate how long something will take when you’re going to do something that is entirely new for you: will it be easy? Will it take lots of study time to master it? Also, you will probably get better at the tasks you’re about to be doing. This means that an estimation of 4 days in the beginning of a project could be only 3 days once you’re familiar with the tasks at hand. Making relative estimations can be a solution to decouple time from size. If you estimate in absolute or fixed days, you are actually ignoring the fact that you’re team will get better and faster along the way.

Example:
Say, you estimate that some task takes 4 days. Now, if you have a focus factor of 80%, this means that the work will take 5 days to complete. Now, if this person only works 4 hours a week, this will mean that if he starts on Monday, has a focus factor of 80% and 1 part time day off, then the task won’t be finished until Monday next week in the end of the day.

So remember that you always take into account that you won’t be working full time on a project, and that you have a (limited) number of hours available for your project. Also take into account that estimations at the beginning of a project may be unrealistic further in time. Remember this when determining a deadline, or deciding which parts of the project will be skipped in order to make it to the deadline.

I have stumbled upon this highly creative way of combining interactive technology with the arts. And now it popped up again in my own RSS reader again, and I thought: this is absolutely worth posting, so here it is: Messa di Voce (by Golan Levin, Zachary Lieberman, Jaap Blonk and Joan La Barbara).

Messa di Voce is a performance and installation in which the speech, shouts and songs produced by two vocalists are augmented in real-time by custom interactive visualization software. The visualization software used is Processing. Really a must see!! If you’re in NYC, you can watch the performance live and for free on February 23rd, so be sure to be on time!



Messa di Voce (Performance), Excerpts from Tmema on Vimeo.