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........
Monday, February 28, 2011
Wiki up and running
Not to many blog posts right now. Most of my time has been spent on the team Wiki rather than here.
We had our first team meeting last Saturday with Katherine conferenced in via cell phone. We were going to use google video, but the sound would not work. We used it for video, but the sound would not work so we used a cell phone for the audio. It worked somewhat but it was not ideal. We need to work on a better way to do this. As the professor said today, failure is not an option.
I was bale to share my original thouhts on how the system would go together based on my proposal. We talked about changes to the proposal, but the only real change that was accepted was the idea of moving the trending from the HW to the WP part of the project.
We got a fair distance on defining the HAP level 1 protocol. Unfortunately we are still refining it as we had to break up the meeting after several hours. The wiki has a good start on the HAP1 definition.
We had our first team meeting last Saturday with Katherine conferenced in via cell phone. We were going to use google video, but the sound would not work. We used it for video, but the sound would not work so we used a cell phone for the audio. It worked somewhat but it was not ideal. We need to work on a better way to do this. As the professor said today, failure is not an option.
I was bale to share my original thouhts on how the system would go together based on my proposal. We talked about changes to the proposal, but the only real change that was accepted was the idea of moving the trending from the HW to the WP part of the project.
We got a fair distance on defining the HAP level 1 protocol. Unfortunately we are still refining it as we had to break up the meeting after several hours. The wiki has a good start on the HAP1 definition.
Friday, February 25, 2011
Class notes from 2-25-11
Today in class we talked about setting up software revision control. Apparently SVN has been used on previous projects in other classes so it has a large appeal to the rest of the students. I'll have to get caught up on this part as I have never used this software before. I've used other revision control products, just not this one.
We also talked about how to run a meeting, specifically Roberts Rules of Order. Although this works, it will probably be a bit formal for most of our meetings. I expect that we can water it down a bit and get a working set of rules for our meetings. This will need to be worked out when we meet on Saturday.
An agenda has been set for our first meeting, thanks to Ekaterina. She was also helpful in pulling together team members contact info and availability as well as establishing the SVN account on the CS servers. Thanks for the team support!
In class we were also told to establish a wiki for our class, Katherine has agreed to take this on because she has had experience doing this.
All in all it seems the team is already starting to work together!
One last requirement is that we prepare, as a team, a 10 minute pitch for out project that will need to be presented to the "venture capital hat" starting next week. We'll need to refine the proposal in preparation for this presentation to incorporate input from team members.
We also talked about how to run a meeting, specifically Roberts Rules of Order. Although this works, it will probably be a bit formal for most of our meetings. I expect that we can water it down a bit and get a working set of rules for our meetings. This will need to be worked out when we meet on Saturday.
An agenda has been set for our first meeting, thanks to Ekaterina. She was also helpful in pulling together team members contact info and availability as well as establishing the SVN account on the CS servers. Thanks for the team support!
In class we were also told to establish a wiki for our class, Katherine has agreed to take this on because she has had experience doing this.
All in all it seems the team is already starting to work together!
One last requirement is that we prepare, as a team, a 10 minute pitch for out project that will need to be presented to the "venture capital hat" starting next week. We'll need to refine the proposal in preparation for this presentation to incorporate input from team members.
Subscribe to:
Posts (Atom)