Now it is for shure: "Big Brother is watching us"

At least some people I "worked" with. About 15 years ago I did consulting in a project where all the effort was on finding excuses. I was not part of the team but had a weekly meeting with the team members. The intention was that I solve technical problems but all they asked me was how they can explain that there was no progress. I resigned after a few weeks.
I never found a sitiation as extreme as this one but gradually I see it day-to-day.

rule of testing

When testing your own stuff you never test "everything". All you test is "everything that works"!

To "l" or not to "l"

Already planned for days weeks months years I finally took the time to review my web-sites. On some sites the extension was .htm on others .html. I don't like things to be inconsistent so I changed all to .html. I tested "everything" (see rule of testing), launched the sites and tested everything again.
The next day I found that the traffic for cssmate.com decreased significantly. Most traffic from linking sites was gone because they directly linked to the editor http://cssmate.com/csseditor.htm not to the homepage http://cssmate.com/. As I changed the extension to .html all the visitors just received error 404.
Though switching back would have been easy I looked for another solution and found it in URL rewrite. I added a simple rule to redirect .htm to .html and "everything" works fine now.

Welie.com - Patterns in Interaction Design

Welie.com - Patterns in Interaction Design is a great site if you are looking for ideas or samples on web applications. As it shows patterns you won’t find new things but you find almost all the components used on web sites in one place.
What I like most about this site is how the patterns are documented. Each description has a clear structure:

• Problem
• Solution
• Use when
• How
• Why
• More Examples

With this structure you know where to look for what kind of information and it implements decreasing abstraction (overview -> details).

Why is it read?

This is the question to ask before you write.
Writing is all about answering questions. For a blog questions might be

• What is new and interesting?
• What is worth to spend time and attention on?
• What is worth thinking about?

This post is about the question "How can I meet the readers demands when writing?" and the – short - answer is: "Think about the questions the reader has and answer them!"

The - slightly - longer answer is:
If you want somebody to read what you write you ask him to spend time and effort. It’s more probable that get what you want (attention) if you give to the reader what he wants. That’s why you have to understand the readers needs (i.e. his questions). Answering a specific question is by far easier than “writing on a topic” and the result is more readable. It helps to focus on the reader and prevents you from extravagating.

Here are some questions you can ask yourself while writing:

• Why would someone read what I write?
• Who will read it?
• What are the readers questions?
• Which of the readers question do I want to answer?

What if the client doesn't read the specification?

One purpose of a specification is to verify the communication with the client. But how do you handle situations where the client signs it but refuses to read it? This client has a very specific knowledge but no time to review specifications. I deal with this by discussing a very brief description of the key topics with him.

What would you do?

New Site - Just for Fun

The harder they come the more you need fun. I recently created buyabyte.com the web site where they sell rock solid bytes. It's just for my own fun but maybe it's also an encouraging break for others confronted with the daily lunacy of life.

Two-Step Software Development Methodology

Installation instructions for my WLAN-DSL-Router:

1. Unpack box
2. Insert CD
3. Follow instructions

The last step consists of "some subitems" that describe how the hardware has to be installed in various scenarios and how to set the - about hundred - configuration parameters ...

... and here comes the Two-Step Software Development Methodology:

1. Understand problem
2. Implement solution

Not to mention that both steps comprise "some subitems".
Isn't it all about abstraction?

Software Development:Dr. Dobb's | Quick-Kill Project Management | June 30, 2006

In Dr. Dobb's Quick-Kill Project Management June 30, 2006 Andrew Stellman and Jennifer Greene describe a minimized project management approach. I like the idea to apply it on projects with an impossible schedule. Maybe it's also worth to be considered on those "temporary" mini solutions that are implemented "informal" so far. However, give the article a look. Great content, condense writing.

Software Development:What, How or Why?

Many software development advisors address the topic of asking "What not How". Edsger Dijkstra showed in one of his early publications (197x ?) that "What" is just another level of abstraction compared to "How". On the next level every "What" becomes a "How". Therefore I think that this advise is misleading. It's needed to know the "What" and "How" on every level but to understand the requirements on any given level we have to ask "Why are these requirements specified?". Understanding the reasons may lead to a different design or allows to suggest alternative requirements suiting the goals better.