Visits ...

Sunday, November 25, 2012

Process A to Process B


Recently, i went into some trouble. Not for some design that i have done but design someone else has done. Yet i'm responsible, (which is something, i would like to discuss more later).
A vital process did not get executed, but was not known until months passed. Process so important, once a min owe thing has gone in to proportions, needless to say putting me in great trouble. 
My CEO taught me and/or reminded me something, that i would like to keep in mind rest of my career. Processes are sequential which means one depends on another to finish to start-up. this is a continuous process which ends when either meeting the target or ended up in error and terminates. 
What should be happened in between two processes, where one is taking control from the previous one. One thing and one thing only, it should pass the ownership. previous owner should make sure it has passed to the next with confidence of completing successfully its objective and current owner should make sure that he received the control with no strings attached, another words no errors or issues been inherited.
Suppose there are errors in one process, rather progress with hiccups, inaccuracy and inefficiently, it would stop just limiting the situation to mere convenience rather than to a cut-throat blame game and data corrections. worse things could happen to a designer.
let me summarize you in simple graphical format.



Saturday, November 17, 2012

Requirements 1-0

We rely on requirements have our designs. Designs are results of processed requirements. that it self shows the dependency our designs relies on requirements. 
so undoubtedly, requirement gathering is the most difficult aspect of software development. Every other stage in development cycle is made difficult by our actions. Specialty of requirement gathering is it contain elements of surprise or/and actions goes beyond your control.
No one is supposed to collect the all the requirements or in a perfect way and it is not human nature to achieve such good results.
But there is one thing that we all can follow on with respect to requirements. Irrespective of whether they turn up to your face before, during or after the cut off date, there could be only two statuses. 0 and 1. 1, you know about it or 0, you don't.
now not hard as it looks right, but it gives you the base line for next course of actions. how do you identify it is either 0 or 1, is just being thorough with the requirements you have collected like no one including the very people gave you the details, should be able doubt you.
biggest danger or risk, a designer would mount on is, developing a doubt about your own work. once let that come to you, everything else would be easily be fallen apart.