After a short hiatus from the series, I am proud to say we are back with another new business model. This week we are going to take a look at the data mining business model. Using this model means that revenue is generated as a result of data mining through the usage of a product. Nearly every business can use data mining as a way to increase revenue, but there is a growing trend to use data mining as a principle revenue stream. However, this approach does not come without its pitfalls.
Why bother spending the time and effort to create a clean, compelling resume? Is it really all worth it? After all, my code and projects speak for themselves. Right. Right? Besides, who else can write an orange peeling script in Bash that directly translates to assembly for deployment to my mechanical “peel a wizard” device.
It really is not a very difficult thing to master the art of salary negotiations. I spoke about some of the myths of software development salaries that were told to me when I applied for positions. Now, I will take a look at negotiating your salary during the employment process. The biggest mistake any applicant makes is filling in the area labeled “expected salary.” This is a question with no good answer, so it is best just to avoid answering. If you ask for too little the company will pay you that salary, but if you ask for too much they may pass over your resume all together.
Graduating from college can be a stressful time for any software developer. If your experience is anything like mine, you are told different theories from every person when it comes to salaries to expect from your first job. Well, let me tell you that these theories are rarely accurate. It all breaks down to the company and position that you end up being offered. Once you know this, the art of negotiation comes into play and if you do not know what you’re doing it ends up being very disappointing. Hopefully after reading this you will be better prepared to duke it out on your next offer.
For the series this week, we are going to take a look at a version business model. The main principle behind this model is providing different versions of the same software. The idea of creating multiple products out of a single application has been the most popularly adopted model for over a decade. Now, just like any business model there are some serious pitfalls and benefits of this approach. Luckily with many real world examples we can create a very accurate idea of this model.
I have been telling myself this every single day that I have been doing software development. It seems that there will never be a shortage of zealots pushing the next big language. They will tell you that there are some great new features that you cannot live without and you’re missing the boat if you don’t change. These outside comments make it very difficult to select a language for any upcoming project that you plan on starting. No matter what the concept, whether it be a copy cat of an existing application or completely original and innovative, you will have a line out the door of people telling you why their language is the best for your application. I have one thing to say to those people that never miss an opportunity to plug their favorite language, “If you knew anything, you would realize that your language is not the best.”
To kick off this series, I figured a good place to start is with the acquisition business model. This has become one of the more popular business models for web services. The reason this works is because there are big companies (ie. Microsoft, Google, Yahoo, etc) that are acquiring startups at an alarming rate. Like any business model, basing your company on the sole idea of being acquired is risky. If done right however, it can be a very lucrative approach to a startup business.
After talking with our editor, I have decided to start a series on business models. Each Thursday for the next couple weeks I will be taking a look at different business models for development startups. In each article there will be an overview of the model, when to use it, its advantages, and disadvantages. Each post will be filed under the series category so you can view the entire set of posts by selecting it from the right column. The series has yet to have a name and I am open to suggestions so post a comment if you have an idea! We want to get some discussions going on around here.
There is an announcement about Twitter potentially moving away from the Ruby on Rails framework and looking for alternatives. In the article it suggests that Twitter is looking to migrate toward a Ruby only architecture. All this is no shock to anyone who has attempted designing a Rails-based application as a flagship product.
Every startup is focused on the same thing and that is getting a product out the door at a minimum amount of cost. The easiest way to ensure low cost is to cut down on physical development time. What I mean by physical development time is the actual time it takes to go from paper to final product. This is where Ruby on Rails has found its niche. Rails has been hailed as being the best thing since sliced bread when it comes to rapid development. I am not going to debate this fact because this is exactly why I use the framework myself. The highly debated topic I am here to weigh in on is the points of scalability and performance. These are exactly the same two points employees at Twitter have very publicly commented on.
Stumbling around the internet today I noticed that there is a resounding movement toward the usage of UML diagraming applications. I agree that these programs like Microsoft Visio are cool and a required tool of most business development cycles, but they are a waste of time. There hasn’t been anything that can replace the tried and true methodology of diagramming on paper. Visio can never add enough features to match a developers artistic skills. So here I am to teach you in the next two paragraphs how to take an idea and turn it into code the easiest way possible.
Add Ri to Favorites
Follow us on Twitter
Add Ri on Facebook
See our Stumbles
See our Diggs
Check our bookmarks