I've got outlook on my machine. I've got sticky notes on my desk (also at home, which were stolen from office after office hours). I've got a things-to-do diary. What else is required to remember that I need to deliver what I committed? Only thing left is to write tattoos all over the body like tiny memos to remind myself that I've got to do the same shit on different days.
Thursday, July 23, 2009
Thursday, May 28, 2009
IT's NOT rocket science..
Well, all you there in the IT world. Just understand that it's not rocket science. I am not trying to discourage but that's the truth, and sooner it is accepted the better it is. Here simple layman ideas find a better place because the people you are serving don't like rockets and scientists. All they are interested in is 2 + 2 = 4 and NOT how it is calculated. And when time budget and resources are burrying the projects and your tired IT arse further down in the ground you don't think about rockets, you think how to escape.
It sounds sh** but I am talking from my experience. So we are going through a data migration exercise and we have to migrate addresses from one system into another. And in the source system the addresses are present in free text format which can hold 4 lines and 160 characters in all. But the target system accepts the data in a particular format - Street in one field, Building in one field, Town, Region, Post Code etc etc - and can hold only upto 120 characters. And no existing functionality had to be changed in the target system. So these sources addresses had to be formatted and accommodated in the target format.
And since the source addresses were free form text and users being ethnically, psychologically and emotionally different, each of those 20,000 addresses had their own way of being written there.
So yours truly thought why can't we clean such addresses and migrate them across to target system by automating the cleaning process instead of asking the users to clean the whole data. I thought like a rocket scientist. While entering an address how a person usually thinks? He writes city the last, before that street, before that building and before that first line of address like c/o So and So. Oh no. There can be just two lines of address also, not necessarily all the lines will be present. Wait, some lines may be more than 30 characters, some more than 20. Some lines will have explicit house (Flaunders House, Westminster House..) or street (Fleet Street, Dame Street, Park Road..) phew!
And so I started building this cleaner routine in REXX and the code kept on becoming fatter and fatter. At last out of those 20,000 addresses this routine cleaned up around 90% of the addresses. Phew! I thought this will be my magnum opus of this year. Two days before production rollout, business users tell me - we are not able to map the address of source system properly to the target system. I said what the f*** (in my mind) - that may not happen always because addresses are not structured properly and need lot of readjustments before they are migrated across. They say - no, we want one to one mapping because our dim brains cannot understand what you are talking about. Somehow, we escaped saying "You didn't recognize this during UAT and previous testing sprints, now suddenly you are waking up from your slumber when we are two days away from going live. We cannot change code at this stage and this has to go the way it is now." We had to hold them on ransom and get them to accept it the way it was.
But it triggered in me a thought that we shouldn't really think so much when it comes to data migrations. There should be one to one mapping. Forget about intelligent address deciphering routines which might have taken inputs from psychology, ergonomics, ethicity or even evolution. Ultimately what matters is your audience should understand what's really happening.
It's true. Because now when I look at my magnum opus, I myself cannot understand what it does!
Keeping the logic simple and understandable is very important, so that in future if someone looks at the code things become clear in just an instant. That's the reason, I think, someone once said - it is very easy to write in difficult words, but very difficult to write in simple words.
It sounds sh** but I am talking from my experience. So we are going through a data migration exercise and we have to migrate addresses from one system into another. And in the source system the addresses are present in free text format which can hold 4 lines and 160 characters in all. But the target system accepts the data in a particular format - Street in one field, Building in one field, Town, Region, Post Code etc etc - and can hold only upto 120 characters. And no existing functionality had to be changed in the target system. So these sources addresses had to be formatted and accommodated in the target format.
And since the source addresses were free form text and users being ethnically, psychologically and emotionally different, each of those 20,000 addresses had their own way of being written there.
So yours truly thought why can't we clean such addresses and migrate them across to target system by automating the cleaning process instead of asking the users to clean the whole data. I thought like a rocket scientist. While entering an address how a person usually thinks? He writes city the last, before that street, before that building and before that first line of address like c/o So and So. Oh no. There can be just two lines of address also, not necessarily all the lines will be present. Wait, some lines may be more than 30 characters, some more than 20. Some lines will have explicit house (Flaunders House, Westminster House..) or street (Fleet Street, Dame Street, Park Road..) phew!
And so I started building this cleaner routine in REXX and the code kept on becoming fatter and fatter. At last out of those 20,000 addresses this routine cleaned up around 90% of the addresses. Phew! I thought this will be my magnum opus of this year. Two days before production rollout, business users tell me - we are not able to map the address of source system properly to the target system. I said what the f*** (in my mind) - that may not happen always because addresses are not structured properly and need lot of readjustments before they are migrated across. They say - no, we want one to one mapping because our dim brains cannot understand what you are talking about. Somehow, we escaped saying "You didn't recognize this during UAT and previous testing sprints, now suddenly you are waking up from your slumber when we are two days away from going live. We cannot change code at this stage and this has to go the way it is now." We had to hold them on ransom and get them to accept it the way it was.
But it triggered in me a thought that we shouldn't really think so much when it comes to data migrations. There should be one to one mapping. Forget about intelligent address deciphering routines which might have taken inputs from psychology, ergonomics, ethicity or even evolution. Ultimately what matters is your audience should understand what's really happening.
It's true. Because now when I look at my magnum opus, I myself cannot understand what it does!
Keeping the logic simple and understandable is very important, so that in future if someone looks at the code things become clear in just an instant. That's the reason, I think, someone once said - it is very easy to write in difficult words, but very difficult to write in simple words.
Tuesday, May 5, 2009
what next..
When a project is nearing its end and your role is fading away in the overall work, you are faced with a strange sense of insecurity and a frequent question - "what should I do now?" - buzzing inside your head. This is the right time to give your thoughts a correct directions - which is what I once called "Vector Instrospection" (Instrospection with a direction). Following are some dos and don'ts fitting this period of dilemma which I found here.
Do:
* Find out what jobs are currently out there by using job portals like naukri.com.
* Register for jobs by email, and get the latest vacancies sent direct to your PC.
* Register your CV with job portals, that recruiters can take a look online at what you can offer them.
* Think about where you want to be in the long-term, and consider what jobs will help you to get there.
* Consider a new sector to avoid being stuck in a rut. How can you use your transferable skills? Which employers are recruiting at the moment?
* Consider the skills and experience you need to reach your career milestones. What skills are in demand?
* Research the major employers in your sector who might help you to achieve your career goals. It is increasingly unlikely that you will remain with the same employer for the next 20 years. Find out more with our company directory.
* In the short-term, assess what you want from your next job. Consider:
o salary;
o increased responsibility;
o opportunities for training and development;
o more time with your family, friends, hobbies;
o to continue living in the same area;
o to move to another part of the country.
* Money may not be your motive for changing jobs, but work out what you need to earn to cover any extra costs such as travel, childcare, loss of benefits such as pension, or a company car.
* Also, think about your work:life balance. Do you really want to be the boss's boss if it means giving up leisure time, long holidays or seeing your kids during the week? It is becoming more common to want to balance your home and work responsibilities. See our flexible working advice.
Don't:
* Wait until you resign or lose a job before you work out your future career plan. Start now so you're ready when the time comes.
* Apply for jobs without a career plan or goal in mind. You are wasting your own time and that of potential employers.
Do:
* Find out what jobs are currently out there by using job portals like naukri.com.
* Register for jobs by email, and get the latest vacancies sent direct to your PC.
* Register your CV with job portals, that recruiters can take a look online at what you can offer them.
* Think about where you want to be in the long-term, and consider what jobs will help you to get there.
* Consider a new sector to avoid being stuck in a rut. How can you use your transferable skills? Which employers are recruiting at the moment?
* Consider the skills and experience you need to reach your career milestones. What skills are in demand?
* Research the major employers in your sector who might help you to achieve your career goals. It is increasingly unlikely that you will remain with the same employer for the next 20 years. Find out more with our company directory.
* In the short-term, assess what you want from your next job. Consider:
o salary;
o increased responsibility;
o opportunities for training and development;
o more time with your family, friends, hobbies;
o to continue living in the same area;
o to move to another part of the country.
* Money may not be your motive for changing jobs, but work out what you need to earn to cover any extra costs such as travel, childcare, loss of benefits such as pension, or a company car.
* Also, think about your work:life balance. Do you really want to be the boss's boss if it means giving up leisure time, long holidays or seeing your kids during the week? It is becoming more common to want to balance your home and work responsibilities. See our flexible working advice.
Don't:
* Wait until you resign or lose a job before you work out your future career plan. Start now so you're ready when the time comes.
* Apply for jobs without a career plan or goal in mind. You are wasting your own time and that of potential employers.
Thursday, March 19, 2009
let there be bugs...
Programmers! Always in a battle against infinite possibilities and limited lines of code, limited time, limited budget and limited patience! And on top of them all limited brain.
We start development. We think we can do it all. We think we can code a perfect program. Huh! What's the big deal.
We start testing. We think those bugs are fixable. Ah! How silly. We will fix them rightaway. Tiny bugs - here we come.
We start integration testing. We think, other programmer's code sucks. We think - she must change her code - dim wit! But then compassion takes over and we believe in hope. We change our own code and move on. Don't look back - no regrets.
We start system testing. We think, we need a break. But then we change the code, add new lines to it, but we know we are slowly losing it to anonymity.
Users start testing. We wish we could go on a long vacation which would never end. Can do no more. We have already run the scripts 107 times. Someone take it away from us. We don't do anything anymore. Someone pushes us - do it! do it! do it!
Code goes live - and we say - Never again. It's ok to be imperfect. Let's just evolve. Don't be perfect. Let there be bugs.
We start development. We think we can do it all. We think we can code a perfect program. Huh! What's the big deal.
We start testing. We think those bugs are fixable. Ah! How silly. We will fix them rightaway. Tiny bugs - here we come.
We start integration testing. We think, other programmer's code sucks. We think - she must change her code - dim wit! But then compassion takes over and we believe in hope. We change our own code and move on. Don't look back - no regrets.
We start system testing. We think, we need a break. But then we change the code, add new lines to it, but we know we are slowly losing it to anonymity.
Users start testing. We wish we could go on a long vacation which would never end. Can do no more. We have already run the scripts 107 times. Someone take it away from us. We don't do anything anymore. Someone pushes us - do it! do it! do it!
Code goes live - and we say - Never again. It's ok to be imperfect. Let's just evolve. Don't be perfect. Let there be bugs.
Monday, March 16, 2009
team meat...
Believe me, this is from a real life incident. There exists a cabal of very high profile managers, drawing millions of vanilla rupees with chocolate toppings of perks every year, who when want to send a meeting request to their team to discuss a burning project show stopper send a note something like this:
Ironical as it may seem - the gathering actually turns out to be nowhere near to a team meeting. It actually justifies the words which appeared in its coming - TEAM MEAT. There is no agenda, there are no meet me details or a room - a perfect aspirant of the book "101 ways of how not to set up meetings".
Here is how such meeting's life cylce goes - first attendee will ask second attendee about the meeting details, surprised that they both don't know - they will go to third attendee to see if she knew. Until all attendees are covered (except the geeky ones, who like to think that it is their prerogative not to attend any team meeting) this process continues and become a meeting unto itself to discuss why the meeting details were not sent. When nothing comes out of this discussion - everyone decides to go for a short break to get a cup of coffee to ward this interim meeting's after effects.
Five minutes before the actual meat (meeting) - everyone's looking at each other's face to find where the meeting is. And then suddenly - like the 'Big Brother' reality show, an akaashvaani (annoucement) happens 'Big Brother ne aap sabhi ko so-and-so room mein ikattha hone ko kaha hai' (Big Brother wants all of you to gather in so-and-so room). There is tension of a vote-out in everybody's face - 'aaj kiska watt lagega' (who gets the beating today). Everyone's making their excuses in their minds, everyone's thinking of what to say in the meeting without any agenda, where anything can be expected.
After gathering his flock in the room and making them wait for a few minutes - the saddist, the voyeurist Big Brother appears in hisincorrigible unmistakable appearance. In a two hour call - first 20 minutes go in deciding what the agenda should be. Next 20 minutes go in deciding who will speak what and how much and about what. And also, who will not be allowed to speak at all. Then next 20 minutes go in finding out and targetting a bakra (scapegoat) who can silently take up all the insult and aspersions which are coming his or her way.
After one hour - some sincere guy loses his or her patience and says something which nobody likes and next 20 minutes go in settling the dirt down. Last 40 minutes are the most crucial ones. Because this is the time when the Big Brother asks the most difficult question - 'Who is preparing the MoM'? At this time - some people wish the earth tore in two parts beneath their feet and swallowed them, and some wish a meteor fall on Big Brother's dim head. Then some poor fresher has to open her notepad and start pretending that she will do it (but in her mind she is thinking what the heck did we discuss here.)
Now the last 20 minutes - everyone looks at the sincere guy and try to make some sense out of his subject matter expertise displayed very vaguely by his poor communication skills. Big Brother with his big mouth says 'great analysis Sincere Guy' and then blurts out actions on each of the team members as if giving a sermon on the mount and the poor girl jotting down as if writing another new testament.
Even after so much ofblamebrainstorming - 10 minutes are left out of alloted 2 hours for the meeting. Then Big Brother takes a soft stand and asks the question which everyone was waiting to hear - is there any other issue? - because this question marks the coming of end and people who were holding their bladders for last two hours can go out and spill their frustration on to the toilet, thinking of how they would want to beat the sh** out of You-Know-Who.
Alas! Life is unfair. Skills are so unfairly scattered. When will I get to become the Big Brother!
Ironical as it may seem - the gathering actually turns out to be nowhere near to a team meeting. It actually justifies the words which appeared in its coming - TEAM MEAT. There is no agenda, there are no meet me details or a room - a perfect aspirant of the book "101 ways of how not to set up meetings".
Here is how such meeting's life cylce goes - first attendee will ask second attendee about the meeting details, surprised that they both don't know - they will go to third attendee to see if she knew. Until all attendees are covered (except the geeky ones, who like to think that it is their prerogative not to attend any team meeting) this process continues and become a meeting unto itself to discuss why the meeting details were not sent. When nothing comes out of this discussion - everyone decides to go for a short break to get a cup of coffee to ward this interim meeting's after effects.
Five minutes before the actual meat (meeting) - everyone's looking at each other's face to find where the meeting is. And then suddenly - like the 'Big Brother' reality show, an akaashvaani (annoucement) happens 'Big Brother ne aap sabhi ko so-and-so room mein ikattha hone ko kaha hai' (Big Brother wants all of you to gather in so-and-so room). There is tension of a vote-out in everybody's face - 'aaj kiska watt lagega' (who gets the beating today). Everyone's making their excuses in their minds, everyone's thinking of what to say in the meeting without any agenda, where anything can be expected.
After gathering his flock in the room and making them wait for a few minutes - the saddist, the voyeurist Big Brother appears in his
After one hour - some sincere guy loses his or her patience and says something which nobody likes and next 20 minutes go in settling the dirt down. Last 40 minutes are the most crucial ones. Because this is the time when the Big Brother asks the most difficult question - 'Who is preparing the MoM'? At this time - some people wish the earth tore in two parts beneath their feet and swallowed them, and some wish a meteor fall on Big Brother's dim head. Then some poor fresher has to open her notepad and start pretending that she will do it (but in her mind she is thinking what the heck did we discuss here.)
Now the last 20 minutes - everyone looks at the sincere guy and try to make some sense out of his subject matter expertise displayed very vaguely by his poor communication skills. Big Brother with his big mouth says 'great analysis Sincere Guy' and then blurts out actions on each of the team members as if giving a sermon on the mount and the poor girl jotting down as if writing another new testament.
Even after so much of
Alas! Life is unfair. Skills are so unfairly scattered. When will I get to become the Big Brother!
Monday, March 2, 2009
quick and dirty...
I am currently a small drop of tasteless technical skill in the large ocean of strategic migrations. Among big waves of business process analysts, programme managers, solution architects, implementation managers and project managers, I exist as a tiny insignificant and expendable ripple that’s called a developer. By a random divine decree, which some people call fate and others coincidence, this tiny wave got a chance to whirl along with big waves and behold the glory with which they exist in this corporate valley.
Data cleansing is an important part of any migration exercise. It’s like letting go of the old and useless, and adapting to the new and useful. Migrating from an old technology to a new technology, from an old business model to a new business model always requires data cleansing to be performed on the source data.
Some of the data currently under the scope of migration needs to be migrated ASAP because it has intricate dependencies with timelines and budget. To clean and data-migrate this piece, a poor developer (not me) had come up with a ‘quick and dirty’ approach. As soon as projector projected the slide on the wall with ‘QUICK & DIRTY’ written on it, there was a burst of laughter among the members of the elite solution club. Visibly, everyone could comprehend the hidden vulgarity. For those of you who are naïve and unaware of the latent dilettante (which I hope will be very few) when someone says ‘quick & dirty’ in an American accent, it feels more like coming directly from the Sunny Leone’s or Sativa Rose’s mouth from an X rated movie. (WARNING: Please be careful if you get curious and start google-ing these names in your office systems.)
Dirty minds, if you ask me. Or may be naive big-shots who don't have knowledge of programming terms. Because according to Wikipedia, “Quick-and-dirty is a term used in reference to anything that is an easy way to implement a kludge. Its usage is popular among programmers, who use it to describe a crude solution or programming implementation that is imperfect, inelegant, or otherwise inadequate, but which solves or masks the problem at hand, and is generally faster and easier to put in place than a proper solution.”
Well, the poor person who made the slide had other intentions, in line with the wikipedia definitions. Intentions were to “quickly” set up the data even if that meant data was “not so clean” or “dirty”. Well, obviously he was misunderstood by the elite cabal. Idea was simple – given the data has no use for future processing, is static and drives no revenues or reports and needs to be set up one-off just for the reference in the database, there is no point spending time and money on cleaning the data to give it a correct & meaningful shape. After intermittent bursts of laughters and grins among all big waves, the plan is (still under review) to keep it quick and dirty, until ofcourse the management cabal comes up with some "calm and clean" ideas!
Data cleansing is an important part of any migration exercise. It’s like letting go of the old and useless, and adapting to the new and useful. Migrating from an old technology to a new technology, from an old business model to a new business model always requires data cleansing to be performed on the source data.
Some of the data currently under the scope of migration needs to be migrated ASAP because it has intricate dependencies with timelines and budget. To clean and data-migrate this piece, a poor developer (not me) had come up with a ‘quick and dirty’ approach. As soon as projector projected the slide on the wall with ‘QUICK & DIRTY’ written on it, there was a burst of laughter among the members of the elite solution club. Visibly, everyone could comprehend the hidden vulgarity. For those of you who are naïve and unaware of the latent dilettante (which I hope will be very few) when someone says ‘quick & dirty’ in an American accent, it feels more like coming directly from the Sunny Leone’s or Sativa Rose’s mouth from an X rated movie. (WARNING: Please be careful if you get curious and start google-ing these names in your office systems.)
Dirty minds, if you ask me. Or may be naive big-shots who don't have knowledge of programming terms. Because according to Wikipedia, “Quick-and-dirty is a term used in reference to anything that is an easy way to implement a kludge. Its usage is popular among programmers, who use it to describe a crude solution or programming implementation that is imperfect, inelegant, or otherwise inadequate, but which solves or masks the problem at hand, and is generally faster and easier to put in place than a proper solution.”
Well, the poor person who made the slide had other intentions, in line with the wikipedia definitions. Intentions were to “quickly” set up the data even if that meant data was “not so clean” or “dirty”. Well, obviously he was misunderstood by the elite cabal. Idea was simple – given the data has no use for future processing, is static and drives no revenues or reports and needs to be set up one-off just for the reference in the database, there is no point spending time and money on cleaning the data to give it a correct & meaningful shape. After intermittent bursts of laughters and grins among all big waves, the plan is (still under review) to keep it quick and dirty, until ofcourse the management cabal comes up with some "calm and clean" ideas!
Friday, February 20, 2009
case study...
This is a real life incident which happened this morning.
Context: Last night Developer 1 (D1) sent across a mail saying task XYZ cannot be done because current code (which is reused from an existing code base with minor tweaks) doesn’t have those pieces of instructions which can handle the inputs we are receiving and so we are ignoring the inputs as of now and we will need a discussion on the same.
Manager 1 comes in.
M1: Hi D1! What is it I am hearing? Why can’t we do that?
D1: Hi M1. Current code is taken from the existing code base which doesn’t handle what we expect. Also, we had conveyed the same earlier that this would not be possible to customize the accounts with current code and that all accounts will inherit their parent’s characteristics.
M1: But why aren’t we handling that? That means the design was flawed? B1 (M1’s boss) had clearly told that the code has to be reusable. Then the code should be able to do that. Why is it not doing that then?
D1: Well, because it is built that way. If we want that code to do extra tasks then it will require extra development work.
M1: slightly pissed off look… B1 will push it blah blah blah… (D1 doesn’t understand the lingo…) Costs are blah blah blah… Timelines are blah blah blah…
D1: startled look… silent...
M1: startled look… silent for a while... Ok! Can you just do some analysis and let us know why it was not done and what would it take to do it?
D1: hiding frustration behind a poor smile… Sure M1. I will let you know.
M1 goes and D1 puts his ear phones back and starts listening to Linkin Park.
Manager 2 comes in.
M2: Hi D1, how are you! I hope you are aware of the new requirement with respect to the accounts. Before we discuss anything, let me just say I am totally with you in and I totally agree that current code cannot do what it is expected to do.
D1: Hi M2.
M2: Can you just tell me, what’s the problem we are facing?
D1: Yes M2. The new inputs expect the new accounts to be customizable at child level. Till now, the code has been built in such a way that all the accounts inherit the characteristics of the parent account. In order to do that, we will have to do some extra development.
M2: Can you tell me, what are the extra attributes that are required to be customized at child level?
D1: Attributes, like billing frequency, billing currency, billing addresses and contact persons.
M2: Do you have any idea how many such clients are there?
D1: Nope. I will confirm with D2 and let you know.
M2: I think, just suggest what you feel… will it be a good idea to load all the accounts as current code does. And then write a small add-on script which will then take those additional attributes and write into the database.
D1: M2! D2 has confirmed that there are 14 such accounts.
M2: Will it be possible to set them up manually, instead of writing a script especially for them? D1! Can you please analyse both the options – setting them up manually, or writing an add on script to load only account specific data after main script runs, and let us know which option will be quicker, cheaper and better?
D1: Sure M2. I will get back to you in next 2 hours.
M2: Thanks D1.
D1: No probs M2.
M2 goes and D1 closes his windows media player and starts analysing the problem.
Context: Last night Developer 1 (D1) sent across a mail saying task XYZ cannot be done because current code (which is reused from an existing code base with minor tweaks) doesn’t have those pieces of instructions which can handle the inputs we are receiving and so we are ignoring the inputs as of now and we will need a discussion on the same.
Manager 1 comes in.
M1: Hi D1! What is it I am hearing? Why can’t we do that?
D1: Hi M1. Current code is taken from the existing code base which doesn’t handle what we expect. Also, we had conveyed the same earlier that this would not be possible to customize the accounts with current code and that all accounts will inherit their parent’s characteristics.
M1: But why aren’t we handling that? That means the design was flawed? B1 (M1’s boss) had clearly told that the code has to be reusable. Then the code should be able to do that. Why is it not doing that then?
D1: Well, because it is built that way. If we want that code to do extra tasks then it will require extra development work.
M1: slightly pissed off look… B1 will push it blah blah blah… (D1 doesn’t understand the lingo…) Costs are blah blah blah… Timelines are blah blah blah…
D1: startled look… silent...
M1: startled look… silent for a while... Ok! Can you just do some analysis and let us know why it was not done and what would it take to do it?
D1: hiding frustration behind a poor smile… Sure M1. I will let you know.
M1 goes and D1 puts his ear phones back and starts listening to Linkin Park.
Manager 2 comes in.
M2: Hi D1, how are you! I hope you are aware of the new requirement with respect to the accounts. Before we discuss anything, let me just say I am totally with you in and I totally agree that current code cannot do what it is expected to do.
D1: Hi M2.
M2: Can you just tell me, what’s the problem we are facing?
D1: Yes M2. The new inputs expect the new accounts to be customizable at child level. Till now, the code has been built in such a way that all the accounts inherit the characteristics of the parent account. In order to do that, we will have to do some extra development.
M2: Can you tell me, what are the extra attributes that are required to be customized at child level?
D1: Attributes, like billing frequency, billing currency, billing addresses and contact persons.
M2: Do you have any idea how many such clients are there?
D1: Nope. I will confirm with D2 and let you know.
M2: I think, just suggest what you feel… will it be a good idea to load all the accounts as current code does. And then write a small add-on script which will then take those additional attributes and write into the database.
D1: M2! D2 has confirmed that there are 14 such accounts.
M2: Will it be possible to set them up manually, instead of writing a script especially for them? D1! Can you please analyse both the options – setting them up manually, or writing an add on script to load only account specific data after main script runs, and let us know which option will be quicker, cheaper and better?
D1: Sure M2. I will get back to you in next 2 hours.
M2: Thanks D1.
D1: No probs M2.
M2 goes and D1 closes his windows media player and starts analysing the problem.
Subscribe to:
Posts (Atom)