Friday, October 26, 2012

Strawberries, Chocolate and Tomatoes

Recently my wife and I decided to try an experiment with 7 of our children. Each child got to pick out their favorite ingredient for dinner. It could be anything they wanted, but it had to be a single ingredient. They were all told their favorite ingredient would be put into dinner that evening. They all wrote their ideas on a piece of paper. No one knew what the other person wrote down. The challenge for my wife and I was to use all the ingredients to make something for dinner.

So here's a list of ingredients, starting from youngest to oldest child.



  • strawberries - very good choice
  • maple syrup - another great choice
  • chocolate chips - sounds like a yummy dessert
  • coconut milk - again a great combination
  • olive oil - this is no longer dessert, it’s something else
  • tomatoes -fits well with the olive oil
  • parmesan cheese - the finishing touch

We had bow tie pasta planned for that night so we made 2 batches. One batch with chicken alfredo, the other with the concoction of favorite ingredients. The results were amazing....amazingly gross. All of these individual ingredients were great, but together a gastronomical disaster.

At work I have noticed the same sort of thing with development tools. If we don't spend time looking at the big picture, we can sometimes end up with great point solutions that combined together make a less than desirable system. A great build tool combined with a great configuration management tool adding in a requirements management tool can be great as long as they can all talk to each other and use a common systematic data model. If not, then you end up with a Frankenstein system that is hard to manage and not too pretty to look at. Some simple planning upfront with goals and objectives for each of the ingredients, can quickly change disaster into a utopian system.

First, focus on a common data model. This does not mean a single database, just a common data model. That means that when I say the word Defect, it means the same in all of the tools, has common fields and if possible resides in one place.

Second, focus on integration of tools not through replication of data. Replicating and translation of data always leads to problems. It is far better to link data across tools with as little data manipulation as possible. If a tool already has a notion of defect that does not match your primary tool for defects, then you can have a problem. Where is the real defect?

Third, remember the “best of breed” tool that does not fit into the system well, does not belong in the system. No matter how good the chocolate was that went into our family’s dinner, it tasted horrible with tomatoes and olive oil. The same is true with point tools that cannot effectively talk with other tools.

Last, look for the low touch integration. Just like in a well designed system you do not want to have a highly coupled tool integration suite. It causes problems when tools are upgraded. Look for loose coupling and high cohesion in the tools that you integrate together.

Good luck with the tool soup you are creating, remember that not all great things thrown together are necessarily a good combination.

DWP

No comments:

Post a Comment