In class we were asked to look into the survival rates of new businesses. I was able to find a a lot of information on this, but found it most interesting to see some of the international aspects of this data. Here is a brief summary:
US: The US Census Bureau has a huge amount of data, pretty much on any statistic you might want. It also provides some very interesting ways to display this. I found a colored map of the United States where the states to change color based on a given business data as you moved a scroll bar to change the year. It allowed you to see the business trends for all states at once over a wide range of years. I found an artical based on the US Census Bureau data that summrised the survival rates of small busniess from 1992 to 2002 as follows:
1992 - 100 Buisness
1993 - only 75 survived
1996 - only 50 were still in business
2002 - only 29 business remained
I thought that was not bad, only loosing 25% in the first year. I guess that is partly because this data includes all small business types, not just high-tech. I would expect high-tech survival to be much lower.
Canada: Not a good place to start a new business according to the article I read.
First year: only 10% survive (ouch!)
only 25% of those survived another year
36% of those survive past the 5 year point
20% of those make it to the ripe old age of 10 years.
It seems that a start-up business in Canada is not a good deal. Maybe the data is skewed by the article writer, or it was just bad data, but I have not seen any new business out of Canada in quite a while, so maybe its correct.
Internationally: An interesting article from an international business meeting held in Bahrain this last January (must have been before all the political unrest). It stated that internationally about 60% of business survive to 5 years. That seems to jive with the US statics, but indicates that maybe international business have a slightly better survival rate. May be this is because US businessmen might be more willing to take risk and that a lot of that is in high-tech areas that are prone to failure when compared to more traditional businesses (my conjecture, not backed by facts).
Also interesting from the international article is that business are 3 times more likely to merge into a larger corporation than to expand on their own.
Incubated: Lastly I found an article on "Business Incubators". This seems to be in line with what the professor was talking about when he described the concept of "angels" in class. The idea was to provide a safe place for a small business to grow during its first few years. This move the 5 year survival rate from a normal 44% to 87%. It seemed that the "incubating" provider company did well in many cases also. It seems to have a bit of similarity to the old way of doing business with the use of apprenticeships. Maybe what is old is new again, again!
Tuesday, March 8, 2011
Sunday, March 6, 2011
SST Process
The Salmon Spawning Technique (SST) process is a newly emerging software development process. It is gaining popularity amongst collage student who study in the field computer science. Its major features are its short time from start to completion and its realistic approach to life.
Much like the salmon, the young programmer suffers from urges. The desire to procreate (write code) takes full charge of their life in an uncontrollable and unexplainable way. The salmon (programmer) heads upstream against rushes or water, rapids and WATERFALLS. Along the way the salmon faces many other challenges as it manages to escape the claws of hungry bears who would steal the salmons idea of procreation and turn it into sushi.
Eventually the battered salmon, tire from it long journey, reaches the end of its travels. It passes its genes (software release package) off to the next generation......and dies!
I thought I'd put this in my blog just to see if anyone is really reading them.
Much like the salmon, the young programmer suffers from urges. The desire to procreate (write code) takes full charge of their life in an uncontrollable and unexplainable way. The salmon (programmer) heads upstream against rushes or water, rapids and WATERFALLS. Along the way the salmon faces many other challenges as it manages to escape the claws of hungry bears who would steal the salmons idea of procreation and turn it into sushi.
Eventually the battered salmon, tire from it long journey, reaches the end of its travels. It passes its genes (software release package) off to the next generation......and dies!
I thought I'd put this in my blog just to see if anyone is really reading them.
Agile Process
I came to CS-460 to learn about new techniques for software development, particularly in the area of multi-person programming. With that in mind, I am trying to keep an open mind to new techniques, but it is a bit of a stretch for me in some cases.
Perhaps I have been an engineer too many years to have a lot of faith in the agile process. I'm use to engineers providing a very definite path, in the form of drawings and specification, to a construction crew who completes the project. Careful upfront planning can reduce the cost of a project significantly, whereas poor planning is just asking for a disaster. I also recognize that software development is quite a bit different than constructing a building, so maybe other techniques might work better.
In reviewing different software development techniques I ran across an article by Martin Fowler on the general concepts of agile programming. I took a few quotes I found interesting and included them in my blog with my comments below:
I had posted a blog on this issue previous to this post. I find the idea of estimating program development a constant mystery. I've talked with may estimators in other fields and have been a project estimator on hundreds of projects. It seems there is no other technique in other fields of estimating that crosses well into software estimating. Moreover software estimating seems to always come down to guessing the size (time and cost) of black boxes. Maybe because software is almost always a "new creation" unlike construction where a door is a door and a wall is a wall. I guess I'm still looking for that magic software estimating algorithm.
"A consequence of self-adaptivity is that you should never expect to find a single corporate methodology. Instead each team should not just choose their own process, but should also actively tune their process as they proceed with the project."
I can actually see some relevance to this statement. I have rarely found that the "cut and dry" engineering procedures that have been placed on me over the years worked very well. I have always found that I need to modify them, either to suit my needs or the specific needs of the project. I have also found that engineering process are seldom ever self correcting and rarely support the idea of "active tuning". I actually like this concept of the agile process.
"With common guidelines that state that the role of testing is to ensure conformance of software to up-front written specifications, the role of testers in an agile world is far from clear."
The world I live in....So much of the current philosophy of "Quality Assurance" is captured in this quote. Write a specification, develop the product, test to the specification....wait that sounds like Waterfall technique. A major compliant I have had with the current stare of quality assurance is that it prevents (or at least stifles) creative solutions to issues that appear mid-stream. It seems that the agile process actually embraces this concept. The idea that test development flows in parallel with an iterating design seems to make this possible.As will all new ideas, there is almost always a bit of truth in there somewhere (of course that is true of cults also).
Perhaps I have been an engineer too many years to have a lot of faith in the agile process. I'm use to engineers providing a very definite path, in the form of drawings and specification, to a construction crew who completes the project. Careful upfront planning can reduce the cost of a project significantly, whereas poor planning is just asking for a disaster. I also recognize that software development is quite a bit different than constructing a building, so maybe other techniques might work better.
In reviewing different software development techniques I ran across an article by Martin Fowler on the general concepts of agile programming. I took a few quotes I found interesting and included them in my blog with my comments below:
"Estimation is hard for many reasons. Part of it is that software development is a design activity, and thus hard to plan and cost. Part of it is that the basic materials keep changing rapidly. Part of it is that so much depends on which individual people are involved, and individuals are hard to predict and quantify."
I had posted a blog on this issue previous to this post. I find the idea of estimating program development a constant mystery. I've talked with may estimators in other fields and have been a project estimator on hundreds of projects. It seems there is no other technique in other fields of estimating that crosses well into software estimating. Moreover software estimating seems to always come down to guessing the size (time and cost) of black boxes. Maybe because software is almost always a "new creation" unlike construction where a door is a door and a wall is a wall. I guess I'm still looking for that magic software estimating algorithm.
"This doesn't mean that you can't fix a budget for software up-front. What it does mean is that you cannot fix time, price and scope. The usual agile approach is to fix time and price, and to allow the scope to vary in a controlled manner."
Sorry, I just can't buy it, "controlled manner" or not. I have never been on a project where a change in scope did not result in a change in ether time or price. Granted, software is kind of "soft" so it might give a bit on this issue. I'd really have to see this in action to believe it works.
"A consequence of self-adaptivity is that you should never expect to find a single corporate methodology. Instead each team should not just choose their own process, but should also actively tune their process as they proceed with the project."
I can actually see some relevance to this statement. I have rarely found that the "cut and dry" engineering procedures that have been placed on me over the years worked very well. I have always found that I need to modify them, either to suit my needs or the specific needs of the project. I have also found that engineering process are seldom ever self correcting and rarely support the idea of "active tuning". I actually like this concept of the agile process.
"With common guidelines that state that the role of testing is to ensure conformance of software to up-front written specifications, the role of testers in an agile world is far from clear."
The world I live in....So much of the current philosophy of "Quality Assurance" is captured in this quote. Write a specification, develop the product, test to the specification....wait that sounds like Waterfall technique. A major compliant I have had with the current stare of quality assurance is that it prevents (or at least stifles) creative solutions to issues that appear mid-stream. It seems that the agile process actually embraces this concept. The idea that test development flows in parallel with an iterating design seems to make this possible.As will all new ideas, there is almost always a bit of truth in there somewhere (of course that is true of cults also).
Tuesday, March 1, 2011
Class notes for 2-28-2011
Today the professor talked about chain of command. Making sure we have exhausted all resources at a give level before moving up a level.
We also talked about the concept of confessional debugging. I like this new phase. I have done this so many times in my life, but never had a name to put on it.
Rational for the decisions we make in our project should be able to withstand the Define, Defend and Attack scenarios to make them good rational.
We need to start thinking about our self evaluation for our midterm grade.
- Be objective
- Summarize your activities
- Think about the quality of your work
- Consider a matrix of success - quantitative evaluation
- What is your next step and how do I improve
- Probably die the day before spring break
I spent time this evening updating the HAP1 protocol page on the wiki with some UML diagrams of how communications between the HW and WP should flow. I am also getting a new laptop up and running for use on this project. It is truly unbelievable how many updates it takes to upgrade an XP SP1 computer to a current system. Its kind of like how many licks does it get to the center of a tootsie pop...the world may never know! Oh wait, I need to restart it again........
We also talked about the concept of confessional debugging. I like this new phase. I have done this so many times in my life, but never had a name to put on it.
Rational for the decisions we make in our project should be able to withstand the Define, Defend and Attack scenarios to make them good rational.
We need to start thinking about our self evaluation for our midterm grade.
- Be objective
- Summarize your activities
- Think about the quality of your work
- Consider a matrix of success - quantitative evaluation
- What is your next step and how do I improve
- Probably die the day before spring break
I spent time this evening updating the HAP1 protocol page on the wiki with some UML diagrams of how communications between the HW and WP should flow. I am also getting a new laptop up and running for use on this project. It is truly unbelievable how many updates it takes to upgrade an XP SP1 computer to a current system. Its kind of like how many licks does it get to the center of a tootsie pop...the world may never know! Oh wait, I need to restart it again........
Subscribe to:
Posts (Atom)