A Metaphor a day, keeps me on my toes

Metaphors or visuals to describe the application is a very powerful technique to avoid catastrophes in software development life cycle. Use as many metaphors as possible so that everyone on the project is aware of the concept, the main intent, the ‘ask’. I myself have used images where I was not able to explain in words or where there was less clarity on the requirement, so I drew it, and asked the customer “Is this what you are looking for? the answer was “yeah, but slight changes here and there”, and there you go. You now know the expectations and better clarity on requirements; you know the entities, rules, interactions, interfaces and flows. Probe the customer, and you’ll realize it was so easy and the soon you will be taking snaps smiling with your customer.
Its surpising to know how easy and efficient the process becomes when the intent is clear, so lets first figure out what is the ‘ask’, and provide a solution for that ‘ask’ and just not provide any solution that we know of.
I love metaphors
a==b==c implies a==c, though a bit of logic needs to be in there.

Trying to change something? Its fun, its a challenge.

I face challenges at workplace trying to bring change, but I realized the trick is communication – communicate, communicate, communicate. If your idea for change is not feasible or just impossible, you’ll instantly know from your feedback mechanism. I get an idea and I feel as if sitting on a pin; they click, I yak it – feasible? accepeted, now lets work on it  – naah?  move on … there comes another idea! Thomas A. Edison said “To have a great idea, have a lot of them”. I wonder why we hold ourselves back when there are so many opportunities out there to-improve to-innovate to-demonstrate to-renovate. Don’t worry about people stealing your ideas. If your ideas are any good, you’ll have to ram them down people’s throats.
So, communicate its better being a fool for five minutes instead of being a fool forever.
That was a communication lesson for a change.
Change is hard and the rewards are worthwhile. What better way do we have to spend our lives?  —Ken Schwaber

Requirements are the Software

What does it really take to convert requirements into working software? I think the trick is getting the requirements right; if you do not understand the requirements, no matter what skill/technology you master, your effort goes to trash. The best way is asking for clarifications and getting a clear picture of what the user or customer really wants the software to do!, do not say ‘yes/ok’ to everything without really understanding. Sometimes this can test your patience but you should at all costs know what the requirements are. The customer asks for apple and you give him oranges, do you still expect him to come back to you?
Always make sure you:-
  • Get the requirements right (not the right requirements!) thats called customer facing.
  • Design for ‘the given’ requirements. Create a Model.
  • Code for ‘the’ design.
  • Test the code ‘within the’ system.
  • And take responsibility for your code!
Remember that quality has to be caused not controlled!
Here are 3 golden questions in software development that should tinkle in our heads all the time, it does in my head for sure :-
  1. Why are we buiding this software?
  2. What should this software do?
  3. How do we develop it?

All about Design


I happened to read following in a blog.

    • The appearance of the device must provide the critical clues required for its proper operation – knowledge has to be both in the head and in the world.
    • What makes design a highly challenging and rewarding discipline is that it grapples with the need  to accommodate apparently conflicting requirements. All great designs have an appropriate balance and harmony of aesthetic beauty, reliability and safety, usability, cost and functionality.
    • Art and beauty play essential roles in our lives.  Technology changes rapidly, people change slowly.
    • Humans do not always err, but they do when the things they use are badly conceived and designed.
    • The psychology of everyday things demonstrate the importance of visibility, appropriate clues and feedback of one’s actions.
    • Affordance refers to the perceived and actual properties of the thing, primarily those fundamental properties that determine just how the thing could possibly be used.  For instance, a round object is assumed to have an affordance of a ball.

      Something that happens right after an action appears to be caused by that action.

      Two fundamental principles of designing for people are : 1. provide a good conceptual model and 2. make things visible.

    • Good designs have good mappings between the controls and the things controlled by them. For instance, the "next" button on a screen/wizard should be either on the right or bottom of the screen and not on the top left.
    • Errors should be easy to detect, they should have minimal consequences, and, if possible, their effects should be reversible.  Errors can sometimes be prevented by using forcing functions.
    • Designers can use three methods to prevent users get into an erroneous state:
      1. Intelocks – by forcing operations to occur in a particular order
      2. Lockin – by keeping an operation active, preventing someone from prematurely stopping it
      3. Lockout – by preventing someone from entering an erroneous state
    • Ask the following seven design questions while designing – How easily can one:
      1. Determine the function of the device?
      2. Tell what actions are possible?
      3. Determine mapping from intention to physical movement?
      4. Perform the action?
      5. Tell if system is in desired state?
      6. Determine mapping from system state to interpretation?
      7. Tell what state the system is in?

real good insight for those stuck in design web!

Sounds cool…