Tuesday, January 29, 2008

See kids? Modularity *is* good!

Here's a good one: we show that tightly coupled components have a higher probability of survival as a design evolves; in essence, they are “harder-to-kill.” We also find that tightly-coupled components are harder to maintain, in that they are more likely to experience surprise design changes unrelated to newly added or removed functionality. Finally, we show that tightly-coupled components are harder to augment, in that the mix of new components added in each version is significantly more modular than the legacy design. These results have important implications for managers, highlighting the impact of design decisions made today on both the evolution and maintainability of a design in subsequent years.

Basically they say that you don't want to mess around with objects that are hard to kill. I tend to agree.

Ok, now that I've actually read the article, it occurred to me that the central, hard to kill objects in most applications are the data objects. These are the payloads of data you pass around as arguments between your methods.

The key concepts of your business are represented by data objects, ie. customer, account, order, product etc. These objects are used by many of your processes, so data objects have a high visibility (good for survival, not good for adaptibility). Thinking long and hard about the definition of your data is thus a money saving tactic.

Crystal 128 kivio.Image via WikipediaOk, maybe I go a little fast here. The href'd article also shows that in later releases, much of the maintenance effort (read: cost) is sinking into the legacy, hard to kill, hard to maintain, objects. I propose that data objects are a fair share of that. This implies that designing your data objects well can cut on maintenance costs later on in the project.

The actual technology that produces the data objects isn't under discussion here. I don't care if my CustomerObject comes out as a POJO, entity bean, or as a chunk of xml. The actual data and definition of a customer, that's what I need to know.

In this regard, the REST architecture fits nicely. Within this architecture, most of the design effort is concentrated on the data formats, or resource definition. In contrast, the operations on that data are simple, as in equivalent with HTTP commands (GET POST PUT etc). This way the design effort must be spent at defining meaningful resources and formats.

Another thing comes to mind. The XML folks have over time gained some experience in how to handle evolving specs for their formats. This knowledge is perfectly suitable to 'evolve' entity data objects into more modular forms , so that they do not become legacy (see again the pdf for how that's bad).

Maybe it's worthwhile to think about refactoring data, or designing data for modularity and adaptability?

Thursday, January 10, 2008

How to Sneak Social Media into the Enterprise

How to Sneak Social Media into the Enterprise

The issues organizations usually have with this style of working stem from the rise of networked individualism. This networked individualism is now just developing, but it exists within the current group- and locality-based organization of society (ie. enterprises). Where the links in the networked individual's network cross a group boundary, problems will arise (from the groups perspective) and counter-measures are taken to ensure group-think, thus crippling the networked individual's productivity.

In a group-based society you belong to many groups at once, but in some circumstances (such as when you're at work), you are to behave as if you are in one group only. I think that over time, the group strategy will become less attractive, as knowledge-workers of the networked-individual style will prove to be more productive than their inward looking, group-focused colleagues. The author of the linked article certainly proves my point.

My own belief is that linking to resources (including people) is much more efficient than copying and storing information. The corporate information network is already there and it's called the internet. Lots of expert systems are already at your disposal, they walk on two legs and may or may not work for the same company. In an always-on, high-bandwidth environment, it is probably more efficient to just ask your trusted expert-friends than to gather and hoard knowledge in a corporate cathedral.

Wednesday, January 09, 2008

Performance Appraisals considered harmful

Abolishing Performance Appraisals makes a powerful case for removing this well intended yet ineffective ritual organizations have been requiring for decades. Coens and Jenkins provide solid reason why appraisals have to go, to be replaced with quality feedback mechanisms including coaching and support structures that enable employees to maximize their own potential.
(synopsis by reviewer Carlos Quintero.)

Although there is no 'cookbook' approach for designing an organization that does not need appraisals, in my opinion being democratic is a good start.

Btw, I'm reading the Dutch version.

Tuesday, January 08, 2008

Traci Fenton, WorldBlu CEO, on organizational democracy

Traci Fenton on organizational democracy. The concept of organizational democracy as explained here comes very close to my own opinions about organization.

This brings to my mind Free speech versus bureaucracy, a chapter from Information liberation, challenging the corruptions of information power, by Brian Martin.

Friday, January 04, 2008

Telecommuting has mostly positive consequences for employees and employers, say researchers

Flexible work arrangements give workers more control over their environment, which helps performance and overall job satisfaction.

Apparently that also benefits the company, as the results also contained "...that telecommuters reported more job satisfaction, less motivation to leave the company, less stress, improved work-family balance, and higher performance ratings by supervisors."

I've always wondered why the take-up of telecommuting arrangements has been so slow. One would expect it to at least alleviate the daily rush-hour traffic. Somehow the irony of going into office everyday (I work for an internet provider) escapes most people.

Creative Commons License

Unless otherwise expressly stated, all original material of whatever nature created by razor_nl and included in the 'How We Work' weblog and any related pages, including the weblog's archives, is licensed under a Creative Commons License.