One of the most popular dating sites, which claims to be chasing Match.com this year, is run by one man out of his home. PlentyOfFish.com claims to generate over $10,000 a day in ad revenues, as documented in this video. In the video you can see a check from Google, which he also posted a picture of, for just under $1M, which was earned in about 2 months, as claimed on his blog. The Wall Street Journal reported that Google did indeed verify that this was a valid check.
I must be in the wrong business. With technologies like Bungee Labs now making web development "so easy a caveman can do it", and with Google paying out the wazoo for ad placement, just about anyone can make a website and make themselves a ton of cash-ola.
Sounds a lot like the dot-com boom all over again...only this time the cash is flowing. I guess I need to come up with a great idea that I can support with AdSense revenues...
Wednesday, May 23, 2007
Tuesday, May 22, 2007
Agile and the "Big Picture"
Software Quality News posted an interview with Alistair Cockburn regarding Agile and how it has been implemented (or not) by companies since the creation of the manifesto. I really like the interview, but the thing that really hit a nerve with me was one of his top ten ways you can tell you are NOT doing Agile. Number 9 is as follows:
I believe these are all-too-frequent rationalizations when people attempt to adopt an Agile methodology. Since Agile de-emphasizes documentation, people jump on the cowboy mentality bandwagon, and begin coding without ANY documentation, hoping that their architecture, and their "big picture" system, will slowly emerge from the clouds as their project comes together.
This is a recipe for disaster. If anyone tells you that because you are "doing Agile" you cannot document the big picture or design an over-all architecture, that is a clear indication that this individual doesn't really understand the Agile methodology.
Jumping into solution space and writing code before you have a well-defined architecture and big-picture goal is like taking off in an airplane before you have a flight plan.
Using agile methodologies in this environment will only help you get the wrong solution released faster.
They have itty-bitty requirements on the order of "here's what happens when you click here," but they don't have long-term vision for what they're trying to accomplish.This reminds me of a discussion we had in the last the CTO Peer to Peer regarding how some groups expect their architecture to "emerge" from their agile processes, so they rationalize that there is no need for formal architecture in the project.
I believe these are all-too-frequent rationalizations when people attempt to adopt an Agile methodology. Since Agile de-emphasizes documentation, people jump on the cowboy mentality bandwagon, and begin coding without ANY documentation, hoping that their architecture, and their "big picture" system, will slowly emerge from the clouds as their project comes together.
This is a recipe for disaster. If anyone tells you that because you are "doing Agile" you cannot document the big picture or design an over-all architecture, that is a clear indication that this individual doesn't really understand the Agile methodology.
Jumping into solution space and writing code before you have a well-defined architecture and big-picture goal is like taking off in an airplane before you have a flight plan.
Using agile methodologies in this environment will only help you get the wrong solution released faster.
Monday, May 21, 2007
Mac vs. Vista
OK - I have to admit, while I am not a Mac user, I love their ads. They are very well done, and hit the nail on the head when poking fun at Vista. I have not converted to a Mac yet, but I am seriously considering making my next laptop a Mac.
With that backdrop, I read today that Mac sales are up 35% in the first quarter over the same period last year. The same article also stated that the Vista uptake rate is less than had been expected (no surprise there).
This begs the question: Why? What is driving people to buy a Mac and not Vista?
It has long been a well-known fact that Mac users have a religious fervor to their support of that platform. Back in the 80's and even the early 90's, Mac users were well known for their zeal in support of the freewheeling, innovative Apple over the stifling corporate-focused Microsoft.
However, I cannot believe that the "corporate culture" difference is the cause of this zeal today. Rather, here are some ideas that I have heard that would make more sense:
I really don't know what single thing is driving Mac sales, nor why Apple has been able to create such a religious following - or if you can even boil it down to one or two key points. But, if other companies can figure out their magic recipe, we might find many more small companies building extremely innovative solutions and gaining extremely loyal customers.
With that backdrop, I read today that Mac sales are up 35% in the first quarter over the same period last year. The same article also stated that the Vista uptake rate is less than had been expected (no surprise there).
This begs the question: Why? What is driving people to buy a Mac and not Vista?
It has long been a well-known fact that Mac users have a religious fervor to their support of that platform. Back in the 80's and even the early 90's, Mac users were well known for their zeal in support of the freewheeling, innovative Apple over the stifling corporate-focused Microsoft.
However, I cannot believe that the "corporate culture" difference is the cause of this zeal today. Rather, here are some ideas that I have heard that would make more sense:
- The OS X is simply a better designed product. I referred to this in an earlier post, but the concept that Steve Jobs simply has a vision of how his OS should work, and requires nothing less than perfection from his employees in the creation of this vision. He maintains strict control over the implementation, and ensures it meets his high expectations.
- People are getting tired of being disappointed by Windows. They start with high expectations for significant improvement, but end up with an operating system that is only slightly incrementally better than the prior incarnation. The Mac is the natural place for these people to migrate to, since Linux desktops are still only for the "techies".
- Sales of the Mac are being driven by the iPod.
- You need a Dictator with vision to run your software company
- Be the only viable alternative to the Goliath
- Create a market via horizontal expansion that will drive sales of your product
- Have some cool ads and a good marketing strategy
I really don't know what single thing is driving Mac sales, nor why Apple has been able to create such a religious following - or if you can even boil it down to one or two key points. But, if other companies can figure out their magic recipe, we might find many more small companies building extremely innovative solutions and gaining extremely loyal customers.
Friday, May 18, 2007
E-mail signatures?
Interesting article in the Journal today regarding E-mail signatures. It mentions services like Meez where you can create your own "avatar" and include it in your e-mail signature. Evidently, this is a craze that is catching on - they report over 1 million registered users, with half of them joining in the first quarter of 2007. Crazy - I guess that is another entrepreneurial idea that passed me by.
I have to admit, I used to attach pithy comments to my e-mails, but have not done so for quite some time. This article makes me wonder, though, if we have now gotten to the point where the signature holds more "meat" than the e-mail message itself. I have noticed a trend recently where the signatures on e-mails are becoming more and more obvious and "in-your-face" than in the past, with graphics and company logos and such. It almost draws your attention to the signature before you read the message. And, my "pithy comments" didn't suck up extra bandwidth.
The article also mentioned John Edwards website, where it offers a download of an image that shows your support for his campaign. Great - more unsolicited advertising in my e-mails, only now it is coming from people I know, embedded in e-mails I want to read (or maybe not anymore...).
How far will this go? Maybe we need a new e-mail product that will strip e-mails of anything that is extraneous to the message in the body. Now that is a service I would pay for.
I have to admit, I used to attach pithy comments to my e-mails, but have not done so for quite some time. This article makes me wonder, though, if we have now gotten to the point where the signature holds more "meat" than the e-mail message itself. I have noticed a trend recently where the signatures on e-mails are becoming more and more obvious and "in-your-face" than in the past, with graphics and company logos and such. It almost draws your attention to the signature before you read the message. And, my "pithy comments" didn't suck up extra bandwidth.
The article also mentioned John Edwards website, where it offers a download of an image that shows your support for his campaign. Great - more unsolicited advertising in my e-mails, only now it is coming from people I know, embedded in e-mails I want to read (or maybe not anymore...).
How far will this go? Maybe we need a new e-mail product that will strip e-mails of anything that is extraneous to the message in the body. Now that is a service I would pay for.
Wednesday, May 16, 2007
How much testing is enough?
It really doesn't matter when you plan to release, nor how much testing has occurred - someone will always be worried that it was not enough. Whether you are on an agile schedule of releasing every 4 - 8 weeks, or a more traditional waterfall process of 6, 12 or 18 month releases, it always seems that there was not enough testing time to really feel comfortable shipping a product. If you test too long, you will miss your window of opportunity in the market, and if you don't test enough you risk shipping a bad product.
So, how much is enough, and when do you know it? Test automation helps, but still nothing compares to putting hands on the product and getting a good feeling about it. There is much more subjectivity to testing than most people realize.
It has been said that good managers make decisions when they have only 40% - 60% of the data needed for that decision. The reason being that if they wait for all of the data, they usually miss the opportunity, but if they make the decision with less than 40% of the data, they risk making the wrong decision.
So, does this concept apply to testing as well? It certainly seems to fit (if you wait too long, you miss the window) - but then, if you ship a product where only 40% - 60% of the features have been tested, that doesn't sit well with anyone.
The bottom line here is that the decision to ship a product always comes with risk. You can never test all possible scenarios, because you never know exactly how someone will use your product. And you really never know exactly what features have been affected by the recent code changes, even though you might think you do. You can mitigate that risk with automated testing that has significant coverage, and you can also reduce the risk with acceptance-level tests that cover the most-often used features in the product.
However, there will always be risk when shipping new code - regardless of whether you are using agile methodologies or not. But, the agile world gives you two significant benefits: first, the amount of code change for any release is minimized, so the risk of something slipping through is smaller, and secondly with short iterations you can react faster to a "bad" release - which you hope you never have to do, but the reality is that there are just too many variables in todays software environments to avoid it completely.
So, how much is enough, and when do you know it? Test automation helps, but still nothing compares to putting hands on the product and getting a good feeling about it. There is much more subjectivity to testing than most people realize.
It has been said that good managers make decisions when they have only 40% - 60% of the data needed for that decision. The reason being that if they wait for all of the data, they usually miss the opportunity, but if they make the decision with less than 40% of the data, they risk making the wrong decision.
So, does this concept apply to testing as well? It certainly seems to fit (if you wait too long, you miss the window) - but then, if you ship a product where only 40% - 60% of the features have been tested, that doesn't sit well with anyone.
The bottom line here is that the decision to ship a product always comes with risk. You can never test all possible scenarios, because you never know exactly how someone will use your product. And you really never know exactly what features have been affected by the recent code changes, even though you might think you do. You can mitigate that risk with automated testing that has significant coverage, and you can also reduce the risk with acceptance-level tests that cover the most-often used features in the product.
However, there will always be risk when shipping new code - regardless of whether you are using agile methodologies or not. But, the agile world gives you two significant benefits: first, the amount of code change for any release is minimized, so the risk of something slipping through is smaller, and secondly with short iterations you can react faster to a "bad" release - which you hope you never have to do, but the reality is that there are just too many variables in todays software environments to avoid it completely.
Developers are their own breed
I recall having a conversation with one of my peers when I was working at Intel many years ago. We were discussing what motivates Software Developers, and how to best manage them. I have often thought back on that conversation, and thought I might share some thoughts about that this morning.
In the end, most developers just want to work on "cool stuff". They want to know that people like their software, and that their baby isn't ugly. Some developers don't even care if the end-user likes their code - they are motivated by knowing that they have "slayed the dragon", and came up with some really cool way to connect the dots under the covers of the application - the end-user will never even know just how cool it is.
So, how do you motivate developers? Personally, I have learned two things that I believe are invaluable:
1. Learn how THEY like to be managed, and change your management style to match it. Some developers prefer to talk out each step of their solution, and get your approval of everything they do. They like to me micro-managed, although that term has a bad connotation in today's management theory. If they are more successful because they talk through their solutions with you, then you need to be happy to do so.
On the other hand, some developers simply want to take an assignment and run with it. In this case, make sure you have clearly identified the desired outcome, and leave them to it. You hired them to solve the problems, so let them do it - and judge the results based on how well it solves the problem - not on whether it was the way you would have done it or not.
Which leads us to the second lesson:
2. There is not "one best way" to solve any problem. When I was a developer, I was quite arrogant, and really thought that I knew the best way to solve any problem. If someone else didn't do it my way - well, it might work, but it won't be as good, or last as long, be as maintainable, or as user-friendly as my solution.
I remember vividly when I realized just how wrong I was. I had been assigned to work as an Architect, and had to learn and understand three different product lines with the intent of bringing them together under one architecture. As I sat down with the top technical minds behind each product line, I realized that they were all solving the same problem, and had to answer the same questions as they went along. Of course, they all answered them differently (some with java, some with C++, some with client-server, some with SAAS, etc). I remember one day thinking that no one actually came to work one day and said "how can I really screw this up?" - they all had solid reasons for making their design decisions - and they all were now working on very successful products, based on very different architectures and technologies. They had all looked at many of the same technologies and architectures, but had made different decisions along the way. In the end, they all had happy customers and great products.
Developers, especially the good ones, tend to be a bit arrogant, and believe that there is really only one way to solve a problem. This reminds me of Abraham Maslow's comment that "he who is good with a hammer tends to think everything is a nail."
Bottom line is that in order to understand developers, you need to know what motivates them and help them achieve that goal. For some it will be more money, for others it will be a technical leadership role, for others it will be public recognition, and for others it will be to just work on cool stuff and have happy customers.
Regardless of what motivates them, however, the most important thing you can do as a leader is let them do what you hired them to do. They are smart people, and you hired them for a reason - don't try to do their job as well as yours or you will both fail.
In the end, most developers just want to work on "cool stuff". They want to know that people like their software, and that their baby isn't ugly. Some developers don't even care if the end-user likes their code - they are motivated by knowing that they have "slayed the dragon", and came up with some really cool way to connect the dots under the covers of the application - the end-user will never even know just how cool it is.
So, how do you motivate developers? Personally, I have learned two things that I believe are invaluable:
1. Learn how THEY like to be managed, and change your management style to match it. Some developers prefer to talk out each step of their solution, and get your approval of everything they do. They like to me micro-managed, although that term has a bad connotation in today's management theory. If they are more successful because they talk through their solutions with you, then you need to be happy to do so.
On the other hand, some developers simply want to take an assignment and run with it. In this case, make sure you have clearly identified the desired outcome, and leave them to it. You hired them to solve the problems, so let them do it - and judge the results based on how well it solves the problem - not on whether it was the way you would have done it or not.
Which leads us to the second lesson:
2. There is not "one best way" to solve any problem. When I was a developer, I was quite arrogant, and really thought that I knew the best way to solve any problem. If someone else didn't do it my way - well, it might work, but it won't be as good, or last as long, be as maintainable, or as user-friendly as my solution.
I remember vividly when I realized just how wrong I was. I had been assigned to work as an Architect, and had to learn and understand three different product lines with the intent of bringing them together under one architecture. As I sat down with the top technical minds behind each product line, I realized that they were all solving the same problem, and had to answer the same questions as they went along. Of course, they all answered them differently (some with java, some with C++, some with client-server, some with SAAS, etc). I remember one day thinking that no one actually came to work one day and said "how can I really screw this up?" - they all had solid reasons for making their design decisions - and they all were now working on very successful products, based on very different architectures and technologies. They had all looked at many of the same technologies and architectures, but had made different decisions along the way. In the end, they all had happy customers and great products.
Developers, especially the good ones, tend to be a bit arrogant, and believe that there is really only one way to solve a problem. This reminds me of Abraham Maslow's comment that "he who is good with a hammer tends to think everything is a nail."
Bottom line is that in order to understand developers, you need to know what motivates them and help them achieve that goal. For some it will be more money, for others it will be a technical leadership role, for others it will be public recognition, and for others it will be to just work on cool stuff and have happy customers.
Regardless of what motivates them, however, the most important thing you can do as a leader is let them do what you hired them to do. They are smart people, and you hired them for a reason - don't try to do their job as well as yours or you will both fail.
Tuesday, May 15, 2007
Microsoft claims patents on Open Source code
The Wall Street Journal today reported that Microsoft has claimed that 235 of its patents are being infringed upon by the Free and Open Source Software (FOSS) movement, specifically mentioning the GUI, e-mail programs and Open Office as violators.
My first thought was "how did Microsoft get patents on GUI and e-mail programs?" I didn't know you could patent an idea that you "borrowed" from someone else...OK - maybe I'm being too harsh on Microsoft.
My next thought was "What took them so long?" These open-source projects have been around for quite a while - why did they wait until now to claim infringement? Maybe they thought that the best way to fight the Open Source movement was to ignore it, and that by claiming patent infringement would lend credibility to the movement. It has now gotten to the point that they cannot ignore the momentum of Open Source (actually, it got to that point quite a while ago...it is just like MS to play catch-up with the rest of the industry).
Of course, Microsoft has been on the other end of this battle many times. Gee, the first to come to mind is the Zune...doesn't that infringe on some patents by Apple? A large company like Microsoft is happy to enter the market knowing they are infringing on patents, and will simply take the "oops - my bad" approach when sued later for it.
I have to admit that I have not yet jumped completely into the Open Source world. I like Linux, and I actually have Open Office installed on a couple of computers at home, but I have yet to really dive into the Open Source movement with both feet. I am not a Microsoft hater, but I certainly would not personally like to ever work for them.
So, I consider myself a fairly objective outsider in this battle. I love to watch the open-source community eat into the strong-hold that Microsoft has on the operating system market, as well as any other market that they can gain a foothold in.
Having said all of this, the most surprising comment from this short article, and possibly the most troublesome comment, was from the legal counsel to the Free Software Foundation identified as Eben Moglen. He was reported to have said that software in general is a mathematical algorithm, and as such is inherently non-patentable.
We all know that the patent system is in trouble, and needs an over-haul. However, having spent many years in the software world, I believe that software patents do indeed provide some protection for small start-up companies. Not necessarily as a deterrent to large companies, but rather as a recourse if/when the large company infringes on the small companies technological patent. If we do away with software patents altogether, then the software industry as a whole will suffer. Innovation will be stifled, and the companies like Microsoft will continue to dominate in their non-innovation mentality.
Maybe Eben should re-think the defense for Microsoft's contention. If they win using the "software is not patentable" approach, it will increase Microsoft's stronghold over the competition rather than weaken it.
My first thought was "how did Microsoft get patents on GUI and e-mail programs?" I didn't know you could patent an idea that you "borrowed" from someone else...OK - maybe I'm being too harsh on Microsoft.
My next thought was "What took them so long?" These open-source projects have been around for quite a while - why did they wait until now to claim infringement? Maybe they thought that the best way to fight the Open Source movement was to ignore it, and that by claiming patent infringement would lend credibility to the movement. It has now gotten to the point that they cannot ignore the momentum of Open Source (actually, it got to that point quite a while ago...it is just like MS to play catch-up with the rest of the industry).
Of course, Microsoft has been on the other end of this battle many times. Gee, the first to come to mind is the Zune...doesn't that infringe on some patents by Apple? A large company like Microsoft is happy to enter the market knowing they are infringing on patents, and will simply take the "oops - my bad" approach when sued later for it.
I have to admit that I have not yet jumped completely into the Open Source world. I like Linux, and I actually have Open Office installed on a couple of computers at home, but I have yet to really dive into the Open Source movement with both feet. I am not a Microsoft hater, but I certainly would not personally like to ever work for them.
So, I consider myself a fairly objective outsider in this battle. I love to watch the open-source community eat into the strong-hold that Microsoft has on the operating system market, as well as any other market that they can gain a foothold in.
Having said all of this, the most surprising comment from this short article, and possibly the most troublesome comment, was from the legal counsel to the Free Software Foundation identified as Eben Moglen. He was reported to have said that software in general is a mathematical algorithm, and as such is inherently non-patentable.
We all know that the patent system is in trouble, and needs an over-haul. However, having spent many years in the software world, I believe that software patents do indeed provide some protection for small start-up companies. Not necessarily as a deterrent to large companies, but rather as a recourse if/when the large company infringes on the small companies technological patent. If we do away with software patents altogether, then the software industry as a whole will suffer. Innovation will be stifled, and the companies like Microsoft will continue to dominate in their non-innovation mentality.
Maybe Eben should re-think the defense for Microsoft's contention. If they win using the "software is not patentable" approach, it will increase Microsoft's stronghold over the competition rather than weaken it.
Subscribe to:
Posts (Atom)
Posts
