Podcast: Play in new window | Download
Subscribe: iTunes | Android | RSS
Justin and Jason discuss Pluggio’s scalability challenges, password hashing problems in PHP and whether Appignite can generate itself, the danger of working on more than one problem at a time, Justin’s outrageous idea of erecting a pay-wall window for the podcast, how Justin is making a tech love connection, comparing Walmart to Microsoft, the power of commitment, an update on Jason’s TV show idea, Justin’s new apartment and Jason’s upcoming trip to Scandinavia, an update on Justin’s outsourcing experiment, what Justin is doing for Pluggio in terms of marketing, how to detect when a customer is about to drop their account, the cancellation of Stargate Universe, solving the memory leaks in the new Uber dispatch system and whether it’s hard to bootstrap a startup that makes $1,000 per month.
Heh… looking forward to this. I was pondering the other day if appignite was self hosting. Usually that’s a bad sign as you have something too generic 🙂
Hi Justin, Jason,
Thanks for mentioning Totango on your podcast. You are right, we can definitely help in understanding your customers and deliver insights to grow your business, based on their usage.
Let me know if you want to test our product, I’ll be happy to send you a Beta invite.
Cheers,
Omer
Well Jason if your TV show doesn’t make the cut, both of these looked like they might be good:
http://en.wikipedia.org/wiki/Awake_(TV_series)
http://en.wikipedia.org/wiki/Alcatraz_(TV_series)
Maybe one of them can replace LOST 🙂
@Matt – Well, I need something to replace LOST and SGU, so I’ll probably give them both a shot. Event is barely making the cut, but mostly just because there are so few options at the moment.
The discussion about scalability was interesting. In some ways its a chicken and egg scenario i.e. do you build your application to scale from day 1 in hope that its worthwhile or do you concentrate on getting something working and worry about the scaling problems if you get to the point of having worry about it.
I don’t think there is a right answer, it just depends on each application.
Personally, I’ve concentrated on building scaling in from day 1 – just because I wanted to see how performance was affected and because it was easy to generate a pretty large data set and simulate large amount of server load to stress the server. Its just a case of running my test harness.
Another thing that came out of stress testing was the issue of dealing with failures e.g. what happens when you run out of disk space/RAM, loose connectivity etc.
Jason and Justin,
A quick explanation on “marketing”. The narrow (Jason’s) meaning of marketing as promotion is the common, layman understanding. The broader (Justin’s) meaning of doing everything around the product that makes people buy it is a professional term.
It’s like the infamous “hacker”. If you hear it on CNN, you know they mean bad people breaking into computers. When you hear it in a conversation between IT professionals, you know they mean a guy that likes to tinker with stuff and find non-standard solutions.
I think the idea of a 24 hour pay wall would be damaging for the podcast. I know I’d resent it and be less likely to catch the show. I’m not sure it is a bad idea for shows older than a few months. I would probably have paid a small fee to get access to 100+ shows from the past after sampling the last couple of months.
I tend to fall on Justin’s side of the marketing argument even if it was just about semantics. Experiencing a launch to the sound of crickets chirping will do that for you. I think reading Seth Godin, Al Ries, and Jack Trout’s books have given me this sort of perspective. Everything is marketing.
I think the hard thing about launching a $1000/mo bootstrapped tech startup the same thing that is difficult about most things in life. Weight loss, managing money, managing time, happy marriages, and raising kids are all easy in the small things you do. It’s easy to skip dessert once. It’s no problem to cut back on eating out for a month. When you have no choice but to cram things in….the time you have is enough. Changing diapers, buying flowers…easy. But, all this stuff takes discipline, persistence, commitment and sustained action over time to see rewards. The rewards are not immediate and not even always apparent. The small things add up. You have bad days. It’s easy to lose heart. It’s hard.
Great show, gents! I had a couple of thoughts on your topics:
1. When Justin mentioned the task he had given to his developer, the estimate in my head was 2-4 hours from a cold start. So I was more inline with Jason’s estimate. I also know that Jason’s suggestion of adding an expectation works, along the lines of “If this takes you longer than 2 hours, let me know.” I use this with success with my VAs and devs.
2. Jason brought up a customer satisfaction index, and I think he was referring to Dharmesh’s CHI (Customer Happines Index). He’s spoken about it in both of his last 2 BoS talks. The concept of CHI is brilliant; anyone with a SaaS app should look into it (Dharmesh has also mentioned it in a few blog posts on OnStartups.com).
3. Finally, regarding what “marketing” really means…I’m a firm believer that it includes improving conversion (split testing, removing funnel friction, optimizing copy). I’m not sure what else you would call this if not marketing.
Enjoyed the show; thanks for continuing to produce quality material.
Hey Justin, your twitter idea sounds pretty much like DataSift.
You raise a good topic regarding how much time you should allocate for a certain task when outsourcing or working with remote developers. I think there should be a relation between the cost per hour, for example setting a limit say 3 hours for that XML task considering that you are paying X/Hr, but if paying more to another developer , maybe that should be 2 hour task,.
Dirty unholy baby lol.
Hey guys, great show! It’s nice to listen to a podcast about real technical problems that startups are dealing with and I am looking forward to hearing more about your journey and overcoming startup hurdles.
Justin, any particular reason you picked Rackspace over Amazon?
My 2 cents on your segment on mysql… From personal experience dealing with mysql powered applications, you will be surprised how much you can do with the database if you hire an expert or even dive into documentation yourself. So I am all for your “hire a pro for a few hours” idea. There are also a bunch of books on high performance mysql setups if you want to experiment.
It helps to keep in mind that mysql is not really a “default install fits all sizes” solution as far as configuration goes as it will change based on your needs. So good luck and it will be interesting if you share more details about evolution of your app and maybe some of the listeners will have good tips here and there.
Oh and on array_diff, as I was listening, all I could think of is: select ids from table1 where ids not in(select ids from table2), which is horribly slow as well. A much better option, over array diff, would be either Left Outer Join or Not Exists. You can look at stats in your particular case and I am sure you will find a good mysql based solution.
Yes! to indexing INT or any other column types if you want better performance so not all data in the column is being scanned.
Jason, I like your surgeon analogy, hits so close to home for many I am sure, permission to use it!?! And you did make me dizzy talking about auto generating code for application that auto generates that code…. ok … dizzy again. Loved it.
Keep on casting guys and thanks for the hard work.
Sincerely,
Oleg
@Rob Walling +1 on if it takes you longer than, let me know
Also, it is very reasonable to expect it done in 15 minutes but only if your job description that you used to qualify developers has: Must have knowledge and experience of XML parsing with any of the following libraries ….
Justin,
A couple of thoughts on your Pluggio database performance issues:
1. Think about running all resource consuming queries on a copy of your main production database. You don’t want to impact your user experience when they do any kind of routine operations by a big slow analytical query.
2. Consider re-architecting that copy for better performance (better indexing, partition and denormalize it if it’s needed) at the expense of some latency. Mature enterprises have long embraced this division of database usage patterns and has created some lovely acronyms for them: OLTP (for transactional stuff) and OLAP (for queries). Wikipedia would probably explain it better than me at 1 am on Saturday night.
3. Forget about what I said in 2. Use Redis for the heavy analytical stuff – it’s dead simple to use and it’s very fast. It supports set operations such as union, intersect and difference that you need. It will take some time to readjust to the way you do things in Redis, but the result will be rewarding.
My day job is in Data Warehousing and Analytics for big corporations and I have been breathing and living SQL for the past 12 years but I love how Redis makes a lot of things very simple. I’m using it in my startup extensively.
Cheers,
Telman
@Telman Yusupov – Thanks very much for your comment. There are some really excellent insights that you have give there. @Oleg, also thank you very much for taking the time to write up your thoguhts. Very helpful. 🙂
Hey JV, just listening to TZ:128 today and thought I’d share some help regarding your questions on MySQL.
Regarding doing a diff on these huge arrays: one option would be to get the hash value of the array and store that too. Then instead of the next day doing a diff on the arrays, compare the hash of the new array to the old one and see if there’s any difference. If the hashes are different then you will at least know that you need to proceed with the diff otherwise you can skip it.
Also, I’m pretty sure you need to make indexes on number fields. Rows aren’t necessarily inserted in numerical sequence so an index will be needed.
And lastly, regarding the huge caching tables: why back them up at all? If they literally are just for caching, then if a disaster happens and you lose you DBs I’m sure reloading just the important data which you can’t replace is your number one problem so back only that stuff up. The caching tables can be recovered from a Rackspace image and can be a day our of date. Or maybe just let the empty caching tables refill over time again?
Just my 2 cents!
Alex
Oh! You mentioned about putting me in contact with Kevin O’Connor!! That was funny to hear you talk about that!
Sadly Kevin needs someone right away and I am looking to arrange a sponsorship job for when I move out to L.A. in September 2012. So unfortunately it’s not going to happen.
But if anyone else out there is thinking ahead to 2012 and needs an experienced coder then contact me!
😉
Alex