Design is Not Functional Decomposition

Nick Malik writes about the common misconception about design, that you just have to follow a well-defined process to break down a problem in its constituents, and voila, you’ve got the design! No way it’s that easy. That’s an easy trap for those people who excel in model driven development, I think.

Advertisement

Syncing Solution was Unstable

In a previous post, I suggested that I’ve found a syncing solution that works for syncing tasks, calendar and contacts involving a PDA, a work computer and a home computer, so that I can filter out what items are synced to my work computer, while all items exist on my PDA and home computer. Unfortunately, today I ran into the same problem that I had initially, when I tried to use LapLink PDAsync for syncing to both computers, although now I use it only between the work computer and the PDA (for the filtering functionality).

So unfortunately, I can’t recommend that solution anymore. I’ll be back when I find something better, or a manageable workaround.

More On Google Chrome Responsiveness

The Chromium Blog has published more stuff on how to get the Google Chrome GUI responsive. Very interesting to read! Today they’re discussing how plugins affect responsiveness.

GUI Responsiveness in Google Chrome

Over at the Chromium Blog, there’s a post about Google Chrome’s I/O principles. Finally an improvement in GUI responsiveness from the prevalent industry standard. What if Microsoft implemented this in their Office suite, too? I’ve always argued that GUIs should be responsive at all times, thus showing the state of the application, instead of just hanging.

Service vs. Function part II

I just came up with a pretty good explanation of the difference between a service and a function, to clarify on a recent post. It kind of explains why it is difficult to reach an agreement, since people are discussing on different levels. So, watch this: Suppose that you’re a consultant, and you have a contract to perform a certain task, with certain deliverables and other agreements on what’s included. Then the service is the contract, and what you actually do is the function. This works for software services as well as for services of an enterprise that are comprised not only of software, but also of people and organizations.

A Software Development Q&A that Could Work

Joel Spolsky has set up a new Software Development Q&A, called Stack Overflow, together with Jeff Atwood of Coding Horror. If you’re used to the common kinds of web forums that turn up when you have a programming question, you’ll like this one. It’s content is completely user driven (digg-like), so that good answers get voted up by the users, and bad ones are voted down. No discussion is possible (because of this reordering), so the Q&A will only contain questions and answers. Sounds like a really good idea. Take a look!

How to Agree on the Difference between a Service and a Function

In this post, I’ll establish exactly what’s the difference between a service (SOA parlance) and a function. Just joking, no, I won’t. I participated in an animated discussion today about the topic, and the discussion just went on and on. The participants were very bright people, and everyone was right in some way. We just couldn’t move the discussion forward! (Although some progress was made; I admit that.)

So at first, I thought that I’d better write a post to settle the issue. But soon, I realized that then I’d just take my part in the “I know best” game, so I simply skip that, and attack the more abstract problem of how such a problem should be addressed. That is, if you have a disagreement about a concept, and everyone is talking about it from different positions of understanding, and with different levels of abstraction in their understanding, and varying confidence in themselves, how would you settle the discussion with everyone reasonably satisfied?

I’m afraid I don’t have a complete solution to that, so I’ll try to outline some ingredients.

• Try to make everyone listen and understand the others’ points of view.
• Try to make everyone understand the structure of the others’ model of the concept.
• Try to see what differs between those views, and those structures.
• Then argue in a structured way using that knowledge, for example, argue on compatible levels of abstraction, and on compatible scenarios.

Is this possible at all? Any better ideas for getting to consensus on important concepts?

Maybe Edward de Bono‘s Six Thinking Hats could help?

The context in this case is modelling an enterprise using the MODAF modelling framework, which is nice in itself. But since it’s very strict in how things should be modelled, it seems that it’s even harder to make people agree on how to model things.