A picture is worth a thousand words
Showing posts with label Common Sense. Show all posts
Showing posts with label Common Sense. Show all posts
Monday, May 18, 2009
Friday, June 6, 2008
Back to life
Back to business after almost two months, at work life goes as usual, another project after another,but personal life has been changed completely, got married to a beautiful girl, came with her to Aus(yes we made it together!), just got the keys of our new home (moving very soon!) and last (but not the least!) will going to have someone soon who will call me Daddy! (what a feeling!)
So what should I write now? still IT thoughts are trying to make their way into my mind but with not much success
What if we map our lives to Software life cycle? how it would look like? I always love such analogies, they give some interesting knowledge bits, let you look at life from a different angle
We born to our parents,
* software born to business users and development team,
We grow, learn, improve, medical problems, see doctor, cry, laugh,parents feel proud
* software gets rich in feature, get defects (but they don't cry!), eases the pain of the users (but they don't laugh!), see technical support guys, get more stable and stable, business user and developers feel proud(not always though :D )
We socialise, make friends, help others, get benefited from others, create problems for others,
* software starts interacting with other software (ok I mean web services in today's term), relationships established, provide information to other systems, share data, share knowledge, sometimes crash the other systems too, but they don't feel!
We get threats, concerned for our security, financial struggle, move to other places, buy new homes, change lifestyles
* software attacked by viruses, spyware, malware ..., move from one server to another, behind another firewall, get new operating system, new features, work more efficiently (but they never pay themselves, their parents (business or consultants) always pay for them )
We plan our life, start family, Kids, travel and tours, family holidays,
* software , hmmm, sorry they always work, no such luxury , poor dumb systems, they need some AI to think, how crap their lives are!
well, ultimately we die, remembered or forgotten
* software, they die too, replaced by new systems and forgotten,
Conclusion:
I don't want to be a software, I want to be remain human, establish my life but want to work only part of a day not 24x7, enjoy my life, laugh and yes wanna cry too, I want to be remembered, I don't want to be a software
see u soon with some real IT stuff!
So what should I write now? still IT thoughts are trying to make their way into my mind but with not much success
What if we map our lives to Software life cycle? how it would look like? I always love such analogies, they give some interesting knowledge bits, let you look at life from a different angle
We born to our parents,
* software born to business users and development team,
We grow, learn, improve, medical problems, see doctor, cry, laugh,parents feel proud
* software gets rich in feature, get defects (but they don't cry!), eases the pain of the users (but they don't laugh!), see technical support guys, get more stable and stable, business user and developers feel proud(not always though :D )
We socialise, make friends, help others, get benefited from others, create problems for others,
* software starts interacting with other software (ok I mean web services in today's term), relationships established, provide information to other systems, share data, share knowledge, sometimes crash the other systems too, but they don't feel!
We get threats, concerned for our security, financial struggle, move to other places, buy new homes, change lifestyles
* software attacked by viruses, spyware, malware ..., move from one server to another, behind another firewall, get new operating system, new features, work more efficiently (but they never pay themselves, their parents (business or consultants) always pay for them )
We plan our life, start family, Kids, travel and tours, family holidays,
* software , hmmm, sorry they always work, no such luxury , poor dumb systems, they need some AI to think, how crap their lives are!
well, ultimately we die, remembered or forgotten
* software, they die too, replaced by new systems and forgotten,
Conclusion:
I don't want to be a software, I want to be remain human, establish my life but want to work only part of a day not 24x7, enjoy my life, laugh and yes wanna cry too, I want to be remembered, I don't want to be a software
see u soon with some real IT stuff!
Thursday, March 13, 2008
Blogging Tips - Get the most out of your blog
There is a cool blog post by Dave "Tweaking your Blogger blog" that motivated me to share my own thoughts on blogging.
I will add some of my own tips, that I have learned over the past one year or so since I started blogging.
1.Think who will be reading your blog.
For me, I see my blog readers falling in one of two groups. The first group is of the people I know and they get my blog feeds and the other group of the people finds my blog while searching Google (oh yeah I mean Internet, Google is now a synonym to Internet search, something that I do not like, self-prophecy effect, more on this sometime later). So for the second group of people (net searchers) see if you can provide some background information and summary/conclusions. Such additional information might be obvious for first group but it will certainly help others in getting the message right.
2.Write in small paragraphs,
Personally I would close the window if I visit a blog/article with the page long paragraphs. With very less time available to us, it is really hard to read each and every line on such pages. Most of the times we will already have some partial information on the topic and will only be interested in picking up the right pieces from the blog. Breaking down your blog in small para and putting meaning full para headings will make your blog readers quickly pick the relevant information.
3.Write on latest technologies/trends
Attempt to stay ahead of the curve and while browsing net in your free time look what's new and related to your blog. Learn yourself and then share it with others. It is a great way of learning, by writing it down what you have learned. You will also get more hits on such posts. Also if you have some hard found solution for one of the problems you recently faced then that makes it a strong candidate for a blog.
4. Avoid posting your personal activities (for professionals)
Unless the topic of your blog your own/family life avoid posting posts like ' I went to the dinner", "I had great holidays"... and then describing your experience in lengths. Keep your blog focused. It is hard to get someone read your blog so don't bore them with something they are not interested. I mean who cares what I did on the weekend? Few sentences for fun are fine but If you need to put the details then better setup a separate blog for such posts. Don't make your blog a junkyard, full of stuff that is hardly useful for someone.
5. See if you can break lengthy articles into parts
That will help in two ways. First when you plan to write on something in details, you plan , plan and plan and wait for enough time to write it and then you never get chance. Second it will also help the readers in consuming it and they will come back for the next parts if they find it interesting. Another way of writing such lengthy articles is to use a blog writer, I prefer 'Windows Live Writer', it allows me to write long articles in parts, whenever I find sometime I will open up my draft post and add more.
6. Socialising on net, read other people's blog and develop your circle
Almost everyone is aware of the new ways socialising on net. So read the other people's blogs, leave comments, discuss with them topics of interest and increase your network. I love my personalised page http://www.google.com/ig , it allows me to have feeds from a number of blog posts on my home page and also is full of goodies (like feeds from CNET, technology news and funny Reuters:Oddly Enough) that will keep you update on latest trend and technologies.
7. Do some pre-reading
To make sure whatever you are writing is authentic and makes sense, don't write on simply hearing some rumours. Verify the information you are putting on your blog is correct and will provide value to the reader. I prefer to Google and verify the contents of my blog before posting it.
8. Be informal
You are not writing a report for your client, so relax and have a friendly tone in your blogs. Attempt to simulate as if you were talking to your close friend. It really makes blog interesting and fun reading.
9. Use your spare time to think about blog
Do you drive too far to reach work? do you take long train/bus rides? If you spend your time in looking outside window or taking a nap then see if you can think of something interesting for your blog. If you carry laptop/pda then you can blog then and there.
10. Blog regularly
Avoid disappearing from your blog for long periods, blog regularly, even one para each week/fortnightly would make you appear a serious a blogger (and you want to be a serious blogger!) .
Tuesday, December 11, 2007
SOA everywhere - Delivery nowhere
Well, the title of this post is bit exaggerated, SOA is definitely good but implementation is hard and a number of times we end up in creating a mess, took ages to develop but failed to deliver success.
What is good about SOA?
As we know when we say SOA we mean that we need something that would be driven from business model and functions, would reuse existing functionalities with minimal impact on existing applications and making them interoperable with other systems so that we could save time in redevelopment in future.
Also when we develop new systems for future we attempt to make them 'SOA Ready' i.e. designed in a way that any business function can be made available to other systems/consumers without or minimal coding. Of course the idea is fascinating and it does work.
so what doesn't work?
Here the problem I want to address is that having a vision of SOA when technical people sit together and design a framework + lifecycle for the entire business apps and then if they force all development work to follow the same framework for all new developments in order to have consistent development practices, SOA ready applications, potential long term time saving in new developments, etc, there are some serious issues arise from application delivery perspective, particularly slow delivery of solution due to huge investment of efforts upfront for making applications 'SOA Ready'.
But do we really get all those benefits in future? The answer is context driven i.e. it may be or not depending upon the nature of business and development projects. But what I have seen a number of times you can not apply one solution to all your problems.
Take this example, you have got a very nice framework, a framework labelled as SOA based framework, with all nice components, this block, that service, this interface, that data contract and this and that etc. Now you have got a small application to develop for a small group of users in your environment. Would you go for an SOA ready application?
The mistake, in my opinion, people make is that they will go straight after a SOA based architecture while in principle the application is not a right fit for SOA. They do it becuase it is the standard architecture and practice of the organisation now. As a result, developers spend a lot of time in fulfilling framework requirements by developing interfaces, layers, services etc with very less probability of any reusability in future.
so what to do?
In my opinion whenever we design a SOA ready framework we have to consider following points
1. First SOA based architecture should not be a mandatory for all new applications to follow
2. Every application will have to be evaluated to see if there is any real benefit in developing it as an SOA ready application. This depends a lot on how business processes work and not the technology. If the new application is for a small group of users, who are working in isolation with less probability of exposing their functions as services, then we can use very simple architecture and forget complex SOA based architecture.
3. Also, the framework should have pre-defined cut down versions for medium and small applications with lesser number of layers/services/interfaces in order to reduce development overheads. The application will be judged and right model should be picked and applied
4. If using agile methodology, then future reusability can be left over to refactoring. What I mean is that instead of investing time today, leave it to the time when it is required to expose its services and at that time refactor the application and deploy it as an SOA service.
5. As a general rule core systems should be strong candidates of SOA style development. For example, customers database, core sales operations, main financial systems etc. While the systems like some feedback capturing application, some monthly computing application with short expected life span (2-4 years) etc are bad candidates and should be developed in a quick and easy way.
in summary,
We should focus more on delivery without investing too much time in provisions for 'future reusability scenarios'. For instance, once it happened to me that my team put a lot of effort in developing an application with SOA based architecture and ending up with the situation where business users discarded the application, never went live as the business owner of the application had left the organisation and the new owner did not see any real benefit in the application. All our efforts for a 'highly flexible and reusable service based SOA style' application go in vein.
question to ask yourself,
So next time you get an application to develop, ask yourself, does it really need to be developed as an SOA application?
What is good about SOA?
As we know when we say SOA we mean that we need something that would be driven from business model and functions, would reuse existing functionalities with minimal impact on existing applications and making them interoperable with other systems so that we could save time in redevelopment in future.
Also when we develop new systems for future we attempt to make them 'SOA Ready' i.e. designed in a way that any business function can be made available to other systems/consumers without or minimal coding. Of course the idea is fascinating and it does work.
so what doesn't work?
Here the problem I want to address is that having a vision of SOA when technical people sit together and design a framework + lifecycle for the entire business apps and then if they force all development work to follow the same framework for all new developments in order to have consistent development practices, SOA ready applications, potential long term time saving in new developments, etc, there are some serious issues arise from application delivery perspective, particularly slow delivery of solution due to huge investment of efforts upfront for making applications 'SOA Ready'.
But do we really get all those benefits in future? The answer is context driven i.e. it may be or not depending upon the nature of business and development projects. But what I have seen a number of times you can not apply one solution to all your problems.
Take this example, you have got a very nice framework, a framework labelled as SOA based framework, with all nice components, this block, that service, this interface, that data contract and this and that etc. Now you have got a small application to develop for a small group of users in your environment. Would you go for an SOA ready application?
The mistake, in my opinion, people make is that they will go straight after a SOA based architecture while in principle the application is not a right fit for SOA. They do it becuase it is the standard architecture and practice of the organisation now. As a result, developers spend a lot of time in fulfilling framework requirements by developing interfaces, layers, services etc with very less probability of any reusability in future.
so what to do?
In my opinion whenever we design a SOA ready framework we have to consider following points
1. First SOA based architecture should not be a mandatory for all new applications to follow
2. Every application will have to be evaluated to see if there is any real benefit in developing it as an SOA ready application. This depends a lot on how business processes work and not the technology. If the new application is for a small group of users, who are working in isolation with less probability of exposing their functions as services, then we can use very simple architecture and forget complex SOA based architecture.
3. Also, the framework should have pre-defined cut down versions for medium and small applications with lesser number of layers/services/interfaces in order to reduce development overheads. The application will be judged and right model should be picked and applied
4. If using agile methodology, then future reusability can be left over to refactoring. What I mean is that instead of investing time today, leave it to the time when it is required to expose its services and at that time refactor the application and deploy it as an SOA service.
5. As a general rule core systems should be strong candidates of SOA style development. For example, customers database, core sales operations, main financial systems etc. While the systems like some feedback capturing application, some monthly computing application with short expected life span (2-4 years) etc are bad candidates and should be developed in a quick and easy way.
in summary,
We should focus more on delivery without investing too much time in provisions for 'future reusability scenarios'. For instance, once it happened to me that my team put a lot of effort in developing an application with SOA based architecture and ending up with the situation where business users discarded the application, never went live as the business owner of the application had left the organisation and the new owner did not see any real benefit in the application. All our efforts for a 'highly flexible and reusable service based SOA style' application go in vein.
question to ask yourself,
So next time you get an application to develop, ask yourself, does it really need to be developed as an SOA application?
Tuesday, November 6, 2007
The fear factor
Just a couple of quotes to start with
The above quotes just talk about fear factor in general, but I will go and talk about fear factor in software development.
You fear => You Fail,
This is an observation that I have made consistently in my career, if you fear then you will fail, and recently I have observed the same again, making me write this blog. Doesn' t matter whatever technical skills we have got but too much fear of uncertainty can spoil our hard work and progress.
By nature we tend to avoid taking risks, we attempt to follow a path with higher level of certainty and when it comes to software development then we translate this in having well defined requirements, using tested and proven technology, following well practised and adopted development life cycles etc. Particularly if we have spent working years and years in an environment following typical water fall life cycle models. So when we move from such an environment to a dynamic environment where all variables 'requirements', 'technology', 'timelines' and 'resources' continuously changing, we start fearing
- I can't suggest this technology, what if we fail?
- I can't develop this feature, what if doesn't provide value to business
- I have to commit to the deadline provided by my manager, otherwise....
- I have to provide all what my users/business ask, otherwise....
- I have to follow the current practices and procedures religiously and rigorously, otherwise...
- I have to do all documentation
- I am uncertain about requirements, I have to wait and get all clarifications
- I have to save my back
- I could be kicked out if I fail
the list goes on
Agilists don't fear,
One of the core characteristic of some agile development life cycle is that we try to get rid of the fear factor i.e. Agilisits don't fear (but they are not stupid too!). They take the decision early on, they believe that the total cost of pending your decisions too long will be higher than making a wrong decision (among other correct decisions) and rectifying it later. To illustrate this just read this fictitious challenge
A fictitious challenge,
Task: You have to reach your destination 'City A' as soon as possible. You have got two options.
1. Take the safe road that will take 24 hours to get you there.
2. Take a short off road trip, that will take you there in 4 hours.
What would you do?
A risk avoiding person will take the first option. Spending more time and money in reaching the destination, fearing the second option will have unforeseen risks and he will face a lot of trouble
An agilist will take the option 2. BUT as I said Agilists (supposedly and should be) not stupid. He will get a 4WD, with spare tyres, GPS device and a satellite phone, other tools and equipment necessary to rescue himself if something goes wrong and then begin the journey.
well, hmmm...,
You don't agree?? What if this and what if that...? Well it just a fictitious scenario and yes if reaching the destination is a 'do or die' sort of thing I myself will take option 1. But in general I should go for option 2.
The agilist might fail reaching the destination but if he takes such decision 10 times (and are used to taking such challenges and well trained on using his tools) he will probably reach the destination 8-9 times and when he fails to reach the destination he might have to come back and take the safe route, 1-2 times. The point is that the overall cost of failures would be less than the cost of late decisions and lengthy processing times.
So how we map it to software development?
In typical agile development we train ourselves
on techniques like
- User stories
- Automated unit testing
- Continuous integration
- Refactoring
- Iterative development
- Just enough documentation
- Strong communication
-etc etc
using tools
- Nunit/Junit
- Cruise control
- Codegenerators like Codesmith
- Resharper
- Task management tools that support iterative development (JIRA, Gemini, MS TFS)
- communication tools
- etc etc
The message,
The message I want to convey is that when you develop software in today's world, accept challenges and prepare yourself, take initiatives and get ready to mitigate the risks. Take stand on technical and quality grounds. Ask why this way and not that way. don't accept something in the environment just because it was defined in the past.
Challenge yours and others decisions. If you BELIEVE in something then stick to it and make other people change their course of action.
It is better to be kicked out of you organisation on taking stand on quality rather than being kicked out because of not taking initiative and appearing as a dumb person.
"Fear makes the wolf bigger than he is."---- German Proverb "
“Each time we face our fear, we gain strength, courage, and confidence in the doing.”
The above quotes just talk about fear factor in general, but I will go and talk about fear factor in software development.
You fear => You Fail,
This is an observation that I have made consistently in my career, if you fear then you will fail, and recently I have observed the same again, making me write this blog. Doesn' t matter whatever technical skills we have got but too much fear of uncertainty can spoil our hard work and progress.
By nature we tend to avoid taking risks, we attempt to follow a path with higher level of certainty and when it comes to software development then we translate this in having well defined requirements, using tested and proven technology, following well practised and adopted development life cycles etc. Particularly if we have spent working years and years in an environment following typical water fall life cycle models. So when we move from such an environment to a dynamic environment where all variables 'requirements', 'technology', 'timelines' and 'resources' continuously changing, we start fearing
- I can't suggest this technology, what if we fail?
- I can't develop this feature, what if doesn't provide value to business
- I have to commit to the deadline provided by my manager, otherwise....
- I have to provide all what my users/business ask, otherwise....
- I have to follow the current practices and procedures religiously and rigorously, otherwise...
- I have to do all documentation
- I am uncertain about requirements, I have to wait and get all clarifications
- I have to save my back
- I could be kicked out if I fail
the list goes on
Agilists don't fear,
One of the core characteristic of some agile development life cycle is that we try to get rid of the fear factor i.e. Agilisits don't fear (but they are not stupid too!). They take the decision early on, they believe that the total cost of pending your decisions too long will be higher than making a wrong decision (among other correct decisions) and rectifying it later. To illustrate this just read this fictitious challenge
A fictitious challenge,
Task: You have to reach your destination 'City A' as soon as possible. You have got two options.
1. Take the safe road that will take 24 hours to get you there.
2. Take a short off road trip, that will take you there in 4 hours.
What would you do?
A risk avoiding person will take the first option. Spending more time and money in reaching the destination, fearing the second option will have unforeseen risks and he will face a lot of trouble
An agilist will take the option 2. BUT as I said Agilists (supposedly and should be) not stupid. He will get a 4WD, with spare tyres, GPS device and a satellite phone, other tools and equipment necessary to rescue himself if something goes wrong and then begin the journey.
well, hmmm...,
You don't agree?? What if this and what if that...? Well it just a fictitious scenario and yes if reaching the destination is a 'do or die' sort of thing I myself will take option 1. But in general I should go for option 2.
The agilist might fail reaching the destination but if he takes such decision 10 times (and are used to taking such challenges and well trained on using his tools) he will probably reach the destination 8-9 times and when he fails to reach the destination he might have to come back and take the safe route, 1-2 times. The point is that the overall cost of failures would be less than the cost of late decisions and lengthy processing times.
So how we map it to software development?
In typical agile development we train ourselves
on techniques like
- User stories
- Automated unit testing
- Continuous integration
- Refactoring
- Iterative development
- Just enough documentation
- Strong communication
-etc etc
using tools
- Nunit/Junit
- Cruise control
- Codegenerators like Codesmith
- Resharper
- Task management tools that support iterative development (JIRA, Gemini, MS TFS)
- communication tools
- etc etc
The message,
The message I want to convey is that when you develop software in today's world, accept challenges and prepare yourself, take initiatives and get ready to mitigate the risks. Take stand on technical and quality grounds. Ask why this way and not that way. don't accept something in the environment just because it was defined in the past.
Challenge yours and others decisions. If you BELIEVE in something then stick to it and make other people change their course of action.
It is better to be kicked out of you organisation on taking stand on quality rather than being kicked out because of not taking initiative and appearing as a dumb person.
Friday, October 19, 2007
It is patent nonsense
I like to patent
- the way I walk, smile, eat and talk
- the way I carry my bag, mow my lawn, arrange my house, clean my house,
- the way I arrange my work desk, run my meetings, conduct interviews,
strange? keep reading
- the way I create a web page, name it, upload it,
- the way I sell products on my web page
- the way I wrap up gifts, Sorry already patented
- the way my customers Click and Buy, Sorry you can't do this too, it has been patented by Amazon
but thanks to a kiwi, not any more
I am writing all this to vent my frustration over these ridiculous patent laws. Probably you might have heard about the recent news story when Amazon has been successfully challenged for its 1-Click patent by a NewZealender. It is some great news. I read about this some time ago and couldn't believe how clicking buttons in some sequence on a web page could be patented? but that was done for Amazon. Not only that, Amazon was also making money from the web sites who were using the similar process, well it is law, they are the patent holders.
Another ridiculous example is 'Buy it now' button on eBay, yes it is patent by someone and that means on my own web site I can't name a button/functionality similar to "Buy it Now". How silly, then what should we do for 'Submit it Now', Check-out it Now', 'Close it Now', 'Cancel it Now', 'Sing-up now' ?? Can I get them patented for me, if some one hasn't already got them?
I am not an expert on laws, but I have done some research on net to understand this drama.
Patent laws originated to protect inventions so that someone investing money in some new technology should be able to get return on his investment/achievement before others start copying the technology, fair enough, no issues. The core problem is that these laws were primarily designed for mechanical (and later electrical/electronics) inventions. With the advent of software the same laws were used to protect software process and methods and here we ran into trouble. The software world is whole different world and patent laws have been misused by those were the first in getting the patent for some simple things/processes (which a layman can think of when faces the similar problem)
If you search net , you will find that there is a lot of noice from people protesting such misuse but what is not good is I couldn't find if there were some serious steps taken by Governments (well basically US Govt, there is one hope) to alter the laws. (In EU first it was recommended and then blocked by Parliament ). Also the bad thing about Amazon case is that the lawsuit against Amazon was won not on logical basis but on the fact that similar process exist before Amazon got it patented. What it means is that if someone could prove that I was the one who first used some process similar to 1-Click then he/she will have the patent, which I object. This is some common sense, the 1-Click sort of thing is not an invention , it shouldn't be get patented.
Few interesting comments against patent laws for software, from wikipedia
Microsoft Granted Patent for Creating Insecure Software
I hope when I do some web development as my hobby I won't be getting some legal notice from someone sitting in another corner of the world 'hey you have just violated my patent', fingers crossed,
- the way I walk, smile, eat and talk
- the way I carry my bag, mow my lawn, arrange my house, clean my house,
- the way I arrange my work desk, run my meetings, conduct interviews,
strange? keep reading
- the way I create a web page, name it, upload it,
- the way I sell products on my web page
- the way I wrap up gifts, Sorry already patented
- the way my customers Click and Buy, Sorry you can't do this too, it has been patented by Amazon
but thanks to a kiwi, not any more
I am writing all this to vent my frustration over these ridiculous patent laws. Probably you might have heard about the recent news story when Amazon has been successfully challenged for its 1-Click patent by a NewZealender. It is some great news. I read about this some time ago and couldn't believe how clicking buttons in some sequence on a web page could be patented? but that was done for Amazon. Not only that, Amazon was also making money from the web sites who were using the similar process, well it is law, they are the patent holders.
Another ridiculous example is 'Buy it now' button on eBay, yes it is patent by someone and that means on my own web site I can't name a button/functionality similar to "Buy it Now". How silly, then what should we do for 'Submit it Now', Check-out it Now', 'Close it Now', 'Cancel it Now', 'Sing-up now' ?? Can I get them patented for me, if some one hasn't already got them?
I am not an expert on laws, but I have done some research on net to understand this drama.
Patent laws originated to protect inventions so that someone investing money in some new technology should be able to get return on his investment/achievement before others start copying the technology, fair enough, no issues. The core problem is that these laws were primarily designed for mechanical (and later electrical/electronics) inventions. With the advent of software the same laws were used to protect software process and methods and here we ran into trouble. The software world is whole different world and patent laws have been misused by those were the first in getting the patent for some simple things/processes (which a layman can think of when faces the similar problem)
If you search net , you will find that there is a lot of noice from people protesting such misuse but what is not good is I couldn't find if there were some serious steps taken by Governments (well basically US Govt, there is one hope) to alter the laws. (In EU first it was recommended and then blocked by Parliament ). Also the bad thing about Amazon case is that the lawsuit against Amazon was won not on logical basis but on the fact that similar process exist before Amazon got it patented. What it means is that if someone could prove that I was the one who first used some process similar to 1-Click then he/she will have the patent, which I object. This is some common sense, the 1-Click sort of thing is not an invention , it shouldn't be get patented.
Few interesting comments against patent laws for software, from wikipedia
Bill Gates (Microsoft) 1991
Internal memo
"If people had understood how patents would be granted when most of today's ideas were invented and had taken out patents, the industry would be at a complete standstill today...The solution is patenting as much as we can. A future startup with no patents of its own will be forced to pay whatever price the giants choose to impose. That price might be high. Established companies have an interest in excluding future competitors."
(though Gates had slightly different view in 2005, when Microsoft needed patent laws)
Oracle Corporation 1994
Submission to USPTO
"Oracle Corporation opposes the patentability of software. The Company believes that existing copyright law and available trade secret protections, as opposed to patent law, are better suited to protecting computer software developments..."
Few more ridiculous patents
Someone claiming 'Most ridiculous patent application ever"Microsoft Granted Patent for Creating Insecure Software
I hope when I do some web development as my hobby I won't be getting some legal notice from someone sitting in another corner of the world 'hey you have just violated my patent', fingers crossed,
Subscribe to:
Posts (Atom)