Hey guys,
Since many of you guys are going out on your own to do your own thing, I thought I'd offer a few words of unsolicited advice. My hope is that you take on board some, if not all, of these things to help you be more successful and therefore generally more happy in life.
So, I'll get to it...
- First off, you really need to know HOW your business makes money. What it is you are selling, how you sell it and how you continue to sell it. Who's your target market? Who is your competition? How are you different? If you can't honestly answer this, you're pretty much dead before you even start. The elevator pitch is good to tease this out.
- Get your legal ducks in a row. Make sure you have a good lawyer though recommendation. You always will need somebody to go to when things get tough or if you need a document written or reviewed.
- Get your financial ducks in a row. Find a good accountant though recommendation. It's worth spending the few hundred pounds a year to make sure your tax returns are in order.
- Get hyper organized from the start. You need to learn this skill. You need to be super anal about keeping track of all documents, receipts, invoices, etc. Ideally, you want to be able to quickly find a document at a moments notice. It's best to have everything both paper and electronic- accessible off-site, like on S3. I have a general folder structure for things if you are interested. You should be hyper organized with your correspondence, like email, etc. (GTD type stuff). Don't be caviler about data security.
EDIT: My online document storage file structure...
You might want to put the financial year folder one level up in the hierarchy, which makes it easier for year-end doc handover to the accountant. Every financial year you add a new folder with the same sub-structure e.g.:
- 2011
--- accounts_payable
------- [vendors listed by folder here]
--- accounts_receivable
------- [client listed by folder here]
--- statements
------- Bank
------- Credit_Card
--- accounting_taxes
more general, high level folders:
- legal
--- NDAs
--- client_contracts
------- [client listed by folder here]
- HR
--- [lastname_firstname (of employee), starting with yourself]
- licenses
--- [software license listed by vendor]
- Know how you will get out of business. All relationships end. The good ones end when somebody dies of old age, but you need know how to resolve partnership issues and an exit strategy up front (this strategy is not hard and fast, just a guideline). The words "cash in" or "beat a dead horse" come to mind here.
- You will be able to set your own hours - you can work any 15 hours in the day you wish ;). Seriously, you need to work at least a 12 hour day to maintain sales, administration and actually do the work. You can't be a slacker.
- Be flexible. Be fair. Be on time. Error on the side of over communication with customers.
- Live in reality, don't bullshit yourself. You are naive sucker - if not, prove me wrong! Learn the scientific method and apply it.
Money Stuff...
- Cash flow is king. Business is simple, you need more money coming in than going out. It doesn't matter that you are owed money down the road if you don't have enough to operate day to day, so you need a balance here, also you need a...
***CASH RESERVE*** - the ONE thing I can't stress enough, is that you have a cash reserve. You need to ideally have at least 6 months of money in the bank that is in reserve. Start with one or two in the beginning and build this up over time. Figure out how much you need to run for a month, then start to save, revise if your costs change. This money should be kept in a separate account and DOES NOT GET TOUCHED for any reason other than complete hardship. This money is not operational money, this is a rainy day fund. On top of this fund, you should also have a few months operational money in the bank.
So, when you start out, you'll say, "woo hoo! I have a sweet new gig and it pay a bunch of money". Don't spend this money. Put it in your cash reserve and don't even think about it. A WORD OF WARNING: my guess is that not having this cash reserve this is where most of you will eventually go wrong.
- Try to close your books quarterly if not monthly. i.e. reconcile all the accounts if you can. If the books are closed, then you have a true snapshot at where you are at.
- Learn how to read your financial reports. Know what a P&L (profit and loss) and a balance sheet is, etc.
- Learn how to spend money. Keep your overheads as low as possible. Do not spend money on anything until you've completely justified it and slept on it. Ask yourself if you would spend your own money on it or not. This is all doublely true for reoccurring expenses, like rent, on line services, etc. Really sweat every penny, because outgoings is 1/2 of the money making equation. You need to live frugally at first until you have that cash reserve. Think about value not overall cost. Know exactly what you want and shop around for the best price.
- When thinking about money, be sure to take off VAT right from the start. In other words, look at all income though the lens of -20% if you are claiming VAT. Also, axe off another 30% for income tax, etc. After you do that, then you have your true income that you can put towards expenses and into reserve. You need to be financially pessimistic so you don't get caught out thinking you have more money they you really do.
- Know what expenses you have coming up, put money away for them. e.g. If you know you have a 300 pound accountant bill every year, then put away 25 pounds a month for it.
- make sure you keep your personal and business finances absolutely separate. Get a separate credit card, keeps separate files, etc.
- Always round down income and round up expenses.
Legal Stuff...
- Understand the risks when looking at any document and the consequences of that risk. My litmus test is 1) Is the contract fair? 2) Is the contract balanced (e.g. risk vs. reward) 3) Is the contract enforceable? With contracts, you want all parties to act selfish because if somebody doesn't play their part and look out for their best interest, then there isn't a natural stalemate that keeps the peace. It's sort of a Cold War mentality you need to have here. Therefore, you need to push and get everything you need out of the contract as well.
- Contracts are only as valid as the ability to enforce them. Therefore, if a lawsuit costs 20 thousand pounds, then there needs to be good reason to fight it out.
- Everybody always looses in a legal fight (except the lawyers). Lawyers are expensive, use them as little as possible, but don't think you can fight it out yourself.
- You would think that US/UK business law is all organized and orderly, but at the end of the day, it's like the Wild West. The law is never clearly defined enough to help, so things are rarely cut and dry. Don't assume the law will be on your side, even if you are on the "right" side of a dispute.
Partnership Stuff...
If you are going into a partnership, be sure you have all the legal mechanisms in place to resolve conflict and allow members to exit cleanly. This is especially true if you are in a 50/50 partnership, because this makes it hard to break voting ties. Therefore, you should have some way to break ties, be it a mediator that has the final say or a flip of a coin, etc. Again, communication is key here. ONLY GO INTO BUSINESS WITH PEOPLE YOU ABSOLUTELY TRUST! You are essentially giving 1/2 your life (if not more) over to somebody else, so don't take partnerships lightly. Good fences make good neighbors - "friends" is a relative term when it comes to partner relationships.
Misc Stuff...
- Avoid hiring employees as long as possible. This complicates things really quickly (taxes, HR, Payroll, etc) and people are a big risk because they are unpredictable. Always hire the absolute best, smartest and AWARE people you can. Never settle for second best people. Avoid nepotism or people too close to customers.
- Good ideas are a dime a dozen. Taking them to market takes a lot of effort.
- It's good execution that is making money right now, not necessarily new innovation.
- Stay customer focused.
*** SLEEP ON IT***- When making any big decision or if you want something, be sure to sleep on it a day or two. Don't make snap decisions. Sometimes you have to tell people you'll get back to them the next day. Patience is another key skill to learn.
- Be honest and don't sugar coat things with your family. I would think most of you already do this, but make sure you are always open and honest about the state of your business because they will be the ones who will be there when things are both good and bad.
... Thus endith my rant...
Sorry, I guess this was a bit longer than I had expected, but take my opinions for what they are. I'm sure there's stuff I missed. I wish you all the best of luck and please keep in touch. I'm always available in case you want to talk about any of this.
All the best,
-Todd
A blog about the trials and tribulations of software development and managing Agile projects.
Wednesday, March 23, 2011
Business Advice From Old Man Anderson
An email I wrote to my former colleagues at Eden Development...
Thursday, February 17, 2011
Cognitive Dissonance, Demonization and Anti-tribalism in Software Development
Here are the notes and links to the media for the "Cognitive Dissonance, Demonization and Anti-tribalism in Software Development" talk I gave on February 15th, 2011 at Eden Development. At Eden, we host Tuesday Talks on both technical and non-technical aspects of development and other interesting stuff. Please follow @edentalks for more information.
Part I: Viewing of PBS Frontline's "A Class Divided"
This is a classic documentary about an inspired teacher in a small town in Iowa teaching her students a lesson on discrimination. It's well worth watching independent of my talk because of it's message and quality, but it is an important way to "prime the pump" for part II.
You can view the program via the following URL. Note: if you do not want to watch the entire program, feel free to stop watching at the point she repeats the experiment with the adults at the prison (you will know what this means when you see it).
http://www.pbs.org/wgbh/pages/frontline/shows/divided/
Part II: Cognitive Dissonance, Demonization and Anti-tribalism in Software Development
The slides used in my talk are in this PDF file.
The video to the talk (if the slides are hard to see, please download them above to follow along). Also, it is recommended that you go to Vimeo to see the HD version of the talk:
If you wish to comment, please comment on this blog post.
Further Reference
Cognitive Dissonance
Stanford Prison Experiment
Confirmation Bias
Richard Feynman
Carl Sagan
Part I: Viewing of PBS Frontline's "A Class Divided"
This is a classic documentary about an inspired teacher in a small town in Iowa teaching her students a lesson on discrimination. It's well worth watching independent of my talk because of it's message and quality, but it is an important way to "prime the pump" for part II.
You can view the program via the following URL. Note: if you do not want to watch the entire program, feel free to stop watching at the point she repeats the experiment with the adults at the prison (you will know what this means when you see it).
http://www.pbs.org/wgbh/pages/frontline/shows/divided/
Part II: Cognitive Dissonance, Demonization and Anti-tribalism in Software Development
The slides used in my talk are in this PDF file.
The video to the talk (if the slides are hard to see, please download them above to follow along). Also, it is recommended that you go to Vimeo to see the HD version of the talk:
Cognitive Dissonance, Demonization and Anti-tribalism in Software Development from Todd Anderson on Vimeo.
If you wish to comment, please comment on this blog post.
Further Reference
Cognitive Dissonance
- http://www.simplypsychology.pwp.blueyonder.co.uk/cognitive-dissonance.html
- http://tierneylab.blogs.nytimes.com/2010/01/27/monkeys-candy-and-cognitive-dissonance/
- http://en.wikipedia.org/wiki/Buyer%27s_remorse
- http://arstechnica.com/science/news/2010/12/this-is-your-brain-undergoing-cognitive-dissonance.ars
- A video that explains the "peg" experiment better than I did in the talk: http://www.youtube.com/watch?v=korGK0yGIDo
Stanford Prison Experiment
- http://en.wikipedia.org/wiki/Stanford_prison_experiment
- Video: http://video.google.com/videoplay?docid=677084988379129606# (also contains a segment on the "shock" experiment mentioned in the talk)
Confirmation Bias
Richard Feynman
- http://en.wikipedia.org/wiki/Richard_Feynman
- Video: "Fun to Imagine" BBC - http://www.viddler.com/explore/josephwouk/videos/92/
Carl Sagan
- Video: "Baloney Detection Kit" with Michael Shermer: http://www.youtube.com/watch?v=eUB4j0n2UDU
- Cosmos (greatest science documentary ever) http://www.hulu.com/cosmos or http://topdocumentaryfilms.com/cosmos/
- Thought provoking YouTube clip: http://www.youtube.com/watch?v=2pfwY2TNehw
- Carl Sagan's book on critical thinking - The Demon-Haunted World: Science as a Candle in the Dark http://en.wikipedia.org/wiki/The_Demon-Haunted_World
Friday, February 11, 2011
Potential Heroku App Data Exploit: Once a Collaborator, Always a Data Collaborator
TL;DR
Heroku apps have an exploit that allows anybody who has ever had access to a heroku app, or has had access to a machine running a heroku app, to view and manipulate live application data from any computer on the internet.
The Issue:
Heroku has an API that allows users to run SQL commands against their live Heroku apps. This service ( https://sql-console.heroku.com/ ) takes in a postgres connection string (DSN) and the SQL query command. Though this service, you can run any command you wish as if you had direct SQL access to the database. It is what the Heroku DB Console add-on uses to execute queries.
The problem with this service is that the only security needed to use the service is the postgres connection string. This connection string can be obtained by any collaborator (or by anybody with access to a collaborator's machine) by running the ENV['DATABASE_URL'] command on the Heroku console:
$ heroku console
Ruby console for xxx.heroku.com
>> ENV['DATABASE_URL']
=> "[EXPOSED DB URL HERE]"
With this URL, anybody (including collaborators, former collaborators, or anybody else) has access to view and manipulate data on your live application via the https://sql-console.heroku.com/. The user does not need to have a Heroku account.
When a collaborator has had their access revoked from a Heroku app their access to the database is not automatically revoked.
The Implications:
The implication of this exploit is that anybody who has ever been a collaborator (even if revoked) or has ever had access to a collaborator's machine, can view and manipulate data on any heroku application. The person using this exploit does not even need to have a heroku account and they can use this exploit from any computer on the internet.
Protective Actions:
Anytime you remove a collaborator, or suspect a collaborator's computer has been compromised, you need to contact Heroku support to get the database keys changes immediately. You might also want to consider changing keys on a regular bases to proactively protect yourself from this exploit.
Also, you should be careful to not leave a machine with access to a Heroku application unattended.
Heroku's Response:
Heroku have been fully informed of this issue and they have acknowledged this exploit is possible. As quoted from their support engineer:
"Thanks for reaching out to use with your concerns for tighter credentials control. We agree that what we currently have is not as good as we would like it to be. As we start building out new features allowing for finer-grained access control to your apps we'll keep these use cases in mind. Currently the only way for someone to gain access to your DB credentials (beyond leaking them) is by adding someone as a collaborator. As such you should only be adding trusted developers and/or contractors as collaborators, much the same as you would grant access to your codebase. In the meantime if you need to have your database credentials updated simply open up a support request and our support team will work with you to roll credentials."
"If your DB credentials are compromised for any reason or you need to revoke them from a former collaborator it is best to have us update the credentials for you. I want to be clear that we do not give out access to your app or any app-sensitive data to any other users unless the application owner authorizes it."
"The only way for someone to gain access to the database credentials is by adding them as a collaborator of if a collaborator (including the owner) leaks the credentials. We offer a means to update credentials should you ever need to. As such this is more of a security best-practices issue than a true security vulnerability.
We are planning on making it easier to manage your credentials but don't have an ETA on these changes."
I have also let them know that I intend to inform the community of this possible exploit via this blog post, of which they have had an advance copy.
What Heroku Could Do:
* Heroku could inform users that DB keys should be re-generated when a collaborator is removed.
* Require credentials to use the https://sql-console.heroku.com/ service.
* Heroku can automate this when there is a change in collaborators, though this would involved a restart of the application.
Heroku is working on more fine grain access. So we'll have to wait and see if this solves this issue.
The Code:
Below is example code to test this out for yourself:
As the code states, you first need to get the DATABSE_URL key from heroku console, then plug the result into the script. If the code does not show up correctly on a syndicated post, then please visit the original post.
One more thing...
This has been covered elsewhere, but it's important to note that your Heroku account username and password are exposed in plain text in your ~/.heroku/credentials file. These credentials can also be used to possibly exploit your application or spoof a collaborator's actions.
From Heroku:
"... we do not store passwords in the credentials file in more recent versions of the heroku gem. There are some older version where this was done but it has since been corrected and we now use an API key instead."
Heroku apps have an exploit that allows anybody who has ever had access to a heroku app, or has had access to a machine running a heroku app, to view and manipulate live application data from any computer on the internet.
The Issue:
Heroku has an API that allows users to run SQL commands against their live Heroku apps. This service ( https://sql-console.heroku.com/ ) takes in a postgres connection string (DSN) and the SQL query command. Though this service, you can run any command you wish as if you had direct SQL access to the database. It is what the Heroku DB Console add-on uses to execute queries.
The problem with this service is that the only security needed to use the service is the postgres connection string. This connection string can be obtained by any collaborator (or by anybody with access to a collaborator's machine) by running the ENV['DATABASE_URL'] command on the Heroku console:
$ heroku console
Ruby console for xxx.heroku.com
>> ENV['DATABASE_URL']
=> "[EXPOSED DB URL HERE]"
With this URL, anybody (including collaborators, former collaborators, or anybody else) has access to view and manipulate data on your live application via the https://sql-console.heroku.com/. The user does not need to have a Heroku account.
When a collaborator has had their access revoked from a Heroku app their access to the database is not automatically revoked.
The Implications:
The implication of this exploit is that anybody who has ever been a collaborator (even if revoked) or has ever had access to a collaborator's machine, can view and manipulate data on any heroku application. The person using this exploit does not even need to have a heroku account and they can use this exploit from any computer on the internet.
Protective Actions:
Anytime you remove a collaborator, or suspect a collaborator's computer has been compromised, you need to contact Heroku support to get the database keys changes immediately. You might also want to consider changing keys on a regular bases to proactively protect yourself from this exploit.
Also, you should be careful to not leave a machine with access to a Heroku application unattended.
Heroku's Response:
Heroku have been fully informed of this issue and they have acknowledged this exploit is possible. As quoted from their support engineer:
"Thanks for reaching out to use with your concerns for tighter credentials control. We agree that what we currently have is not as good as we would like it to be. As we start building out new features allowing for finer-grained access control to your apps we'll keep these use cases in mind. Currently the only way for someone to gain access to your DB credentials (beyond leaking them) is by adding someone as a collaborator. As such you should only be adding trusted developers and/or contractors as collaborators, much the same as you would grant access to your codebase. In the meantime if you need to have your database credentials updated simply open up a support request and our support team will work with you to roll credentials."
"If your DB credentials are compromised for any reason or you need to revoke them from a former collaborator it is best to have us update the credentials for you. I want to be clear that we do not give out access to your app or any app-sensitive data to any other users unless the application owner authorizes it."
"The only way for someone to gain access to the database credentials is by adding them as a collaborator of if a collaborator (including the owner) leaks the credentials. We offer a means to update credentials should you ever need to. As such this is more of a security best-practices issue than a true security vulnerability.
We are planning on making it easier to manage your credentials but don't have an ETA on these changes."
I have also let them know that I intend to inform the community of this possible exploit via this blog post, of which they have had an advance copy.
What Heroku Could Do:
* Heroku could inform users that DB keys should be re-generated when a collaborator is removed.
* Require credentials to use the https://sql-console.heroku.com/ service.
* Heroku can automate this when there is a change in collaborators, though this would involved a restart of the application.
Heroku is working on more fine grain access. So we'll have to wait and see if this solves this issue.
The Code:
Below is example code to test this out for yourself:
As the code states, you first need to get the DATABSE_URL key from heroku console, then plug the result into the script. If the code does not show up correctly on a syndicated post, then please visit the original post.
One more thing...
This has been covered elsewhere, but it's important to note that your Heroku account username and password are exposed in plain text in your ~/.heroku/credentials file. These credentials can also be used to possibly exploit your application or spoof a collaborator's actions.
From Heroku:
"... we do not store passwords in the credentials file in more recent versions of the heroku gem. There are some older version where this was done but it has since been corrected and we now use an API key instead."
Subscribe to:
Posts (Atom)