Tuesday, February 09, 2010

What, Why and How

What you want ?

Why you want that ?

How this accomplishes that ?

These 3 questions surface fluffy stuff for direct discussion.

Thursday, January 14, 2010

Context

Definition: the set of facts or circumstances that surround a situation or event

Per mind map, the context can be looked as a node in a hierarchy of contexts.

Depending from organization of the mind map, 2 people can have 2 different contexts even with same original data.

hidden

Tuesday, January 12, 2010

Stretching

Communication is NOT what you do. Communication is what the other person understood.

You want to stretch yourself to connect with the other person.

If Software groups would stretch themselves to connect with Marketing groups, then better requirements can get squeezed out. And vice versa, Marketing can stretch to Software to ensure that product is understood as communicated.

During stretching interesting things can happen at different places at different times.

Thursday, December 31, 2009

It Depends

Sometimes you hear answers such as “It Depends whom you ask”, “It Depends what is required”, “It Depends who said it”, “It Depends where you are”, “It Depends from a time”, “It Depends how often”, “Depends It is”.

It comes down to “It Depends”. It depends from a context.

How dependable your answers are ? How sharp are you ?

Thursday, December 10, 2009

YesterdaY

Remember opening that expensive 10 year old wine yesterday? Imagine it. You take a sip of this wine. You are tasting a Past by finishing all the wine. This is a physical connection to that Past.

What do you take from Past?  Whatever happened, happened? This is my new today? Troubles faced in past were just unluck? Maybe Past seems as magical, interesting, unreal place? So maybe you look far   away from Past?

Agile Methodology experts have scientific experience with people and projects. They mention the point of Past far often. 

Maybe questions and answers for today can be found in YesterdaY? Taste the Past.

Thursday, December 03, 2009

the Other side

From left side, users interacting with the screen. Users assume meanings of icons, buttons. Users anticipate cause and effects.

Users are doing this: a=b and x causes y.

And you, developer, on the other hand implementing the same a=b and x causes y logic.

Developers and Users are sharing the same interaction logic.

The first one who will know how complex the interaction logic is will be the Developer.

Fluffy Fuzzy Friend

Are you unclear about the final goal of your task? Don’t have specifics and fuzzy on outcomes?

The only feasible goal looks primitive, feels trivial and sounds childish.

Which way you are going to go? The senior way or childish way?

introducing Fluffy Fuzzy Friend:

This friend will bite you when you proceed the senior way, it always did, and you might not have noticed it.

Try the senior way, this time pay attention and see when it bites.

Thursday, November 05, 2009

Wind Power

NO wind blows in the right DIRECTION

FOR people that have different DESTINATIONS

FOR people that have no DESTINATION

Wednesday, September 09, 2009

Decision, Data, Reasoning

Decision is Data processed with Reasoning.

Decision gives insight on the Data and Reasoning.

When starting with Data or Problem, you apply Reasoning and come up with a Decision.

Sometimes Decision appears first while Data and Reasoning are invisible.

Sometimes Data and Decision are apparent while Reasoning is fuzzy.

Sometimes Reasoning is obvious, Decision is suggested, but Data is absent.

Thursday, August 27, 2009

Why?

Go for context. Ask “Why?”

Context is important. By knowing context, you can align your thinking along the branch.

Look at a cup of water.

Why cup of water? Because something is inside the water.

Define problem first, define data first. Solutions start appearing out of blue.

Why are you reading this?

Friday, August 07, 2009

Reality Check with Virtual Decision

Remember real first engineers, Physicists. Physicists prove their formulas with indirect measurable factors. Temperature, weight, chemical reactions, reflections, light…

But how can virtual engineers observe the quality of their virtual work? How can software developers compare 2 different competing solutions? How can you map your code to reality?

Some measureable indirect indicators for decision quality:

 
• Number of “important” lines of code.
 
• Number of defects that happened from existing code.
 
• Number of classes, less classes make system simpler.
 
• Number of relationships, again less relationships make system simpler.
 
• Duplicated functionality, big nono.
 
• Performance.
 
• Other reports that can get generated by third party analyzers.
 
• Any other ideas?

Do you see that these criteria items can give some reality checks to software design decisions?