Ground-Up Rewrite = Flush Your Company

Standard

Software engineers love rewriting old code.  I’m a software engineer, and whenever I look at my own older code (as in more than  a month or so) I get an instant itch to rewrite it.  I’m a bit embarrassed by it, and I think that for various reasons, I can do it better now.  It happens even more when I look at somebody else’s code, because I also assume they must not be nearly as clever as I.  When something’s WORKING we still want to rewrite it, so when a product or component is causing maintenance or performance issues, there is usually a very strong case being made that it needs a ground-up rewrite.  We say things like “we won’t be able to improve the graphic performance unless we completely rework it with a different set of libraries” or “this should have never been developed in Perl, we can’t scale unless it gets redone in C++” (direct quote, by me several years ago).  Or just “this program/class is an incoherent mess, I’m writing a replacement”

Don’t do it.  This will probably kill your company.

Even if it has issues, your production code is the result of say two years of development, of which something like 20% was the fun part of writing shiny new code to solve a problem, and the other 80% was a long slog of tweaks and bug fixes.  Guess what, when you replace that ugly code with your new shiny code you just gave up hundreds if not thousands of man-hours spent improving things.  You re-introduced old bugs and, worse, added new ones that you don’t know about yet.

And the more strategically horrible part of this, is say you spend 2 months writing the new version.  Don’t forget, it will take you twice as long as you think.  During those two months you continue running the old code, but you stop maintaining it because it’s going to be replaced by something amazing “any day now”.  In my experience, you end up with a legacy system that has fallen way behind where it should be, thanks to lack of attention, and a new system that can’t be successfully rolled out because in a production environment it’s not performing as expected.  You now need to invest another significant chunk of time finding and fixing the bugs in it, which you had already done on the old version.

Now you just wasted huge amounts of your most precious resources – time and momentum.  Your customers have wandered off and your competitors just ate your lunch.

The other trigger for this, where there is a legitimate need to do a rewrite, is usually for performance issues.  Such as replacing the Perl code with C++ (bad Jeff).

What should be done instead?  Both situations will arise…

REFACTOR.

When you have legacy classes/components/scripts that are so full of special cases that they can’t be maintained without causing stability problems you DO NOT REWRITE THEM, you pull out functional parts bit by bit, and you name variables and functions bit by bit until it’s clear and well-organized.  And at no point did you add or remove a single line of code that was not there previously.  The code is unchanged, it’s just laid out much better and you can now work in it with confidence.  All of the little fixes and special cases are still there and, perhaps most importantly, there was NO point in time when the code being edited could not be used in production.

Similarly, when you have to replace a program or component in its entirety, you approach it with a refactoring mindset but it’s a bit more complex and has a bit more risk.  In this case, sooner or later you’re going to replace the component with a new one, and it might be in a completely different language, so you can’t use the classic code refactoring techniques.  Instead, you get as close to that as you can.  First, you work to lock down the real functionality of the legacy code with an exhaustive test suite.  This will likely take you longer to do than actually writing the new one, but it’s the only way you can ensure you stay true to the current behavior.  Look at the code as you set up the tests, ensuring that all the funny special cases and outliers are tested.  Generate tests from three months of live usage, ensuring that you handle everything that users/environments actually try.  Next, keep in the refactoring mindset by making the minimal changes possible.  For example, if I were moving a program from Perl to C++ I would actually have the legacy Perl program call a new C++ program and use its output.  This way I can refactor my code from Perl to C++ line by line and function by function, until eventually I still have a Perl program that actually calls a C++ program to perform ALL of its functionality.  All the Perl program does is invoke the new version and return its output.  Now you can take the final step of replacing the tiny Perl with the new C++ and everything should continue as before.

This process allows you to accomplish BIG architectural changes without ever having code that could not be in live use.  If something unrelated breaks, you can fix it on the latest version and push it out, and you’re not maintaining “production” and “future” versions separately.

If I were undertaking this right now, I would also like to pair it with continuous deployment, so that as I made each tiny, safe, change it went live and any errors would be detected immediately.  Also, as mentioned, refactoring is best done with the safety net of a great unit and integration testing framework.

If you want to learn more about refactoring, most learn from The Bible: “Refactoring: Improving the Design of Existing Code” by Fowler, Beck, and (apparently) a dozen others.  I’ve also learned some great techniques on using this practice to improve architecture from “Refactoring to Patterns” by Josh Kerievsky.  Also, Martin Fowler has a website about refactoring at refactoring.com that appears to have some good resources.  Let me know of any other favorite resources in the comments.  I follow Kent Beck at @kentbeck.

Joel Spolsky (@spolsky) wrote a fantastic article on these problems TEN YEARS AGO and I still see this happening.  I think people need reminded of it regularly.

Joel On Software: Things You Should Never Do, Part I

If you write software or manage people who do, you need to go read his old posts now.  It’ll make you look smart 🙂

Agile Budgeting – Followup

Standard

Here’s a few more resources that have surfaced since my post on Agile Budgeting / Startup Cash Flow Management:

Geof Harries (@geofharries of subvert.ca) pointed me at Pulse (pulseapp.com), which encapsulates much of my process in a nice web tool.  I haven’t had the chance to try it out, but it looks like it captures the key steps of estimating, scheduling, repeating, and editing.  One benefit of using our Excel spreadsheet was that we could do 30-second “what-if” experiments.  Move a customer payment to a later date and see if you still make payroll.  Increase your monthly billing by 10% and see if you can hire another developer.  This flexibility and control is key to this being something you are willing to use.

Fred Wilson’s (@fredwilson) excellent MBA Mondays series has included a few posts that introduce the basic accounting reports of balance sheet, profit & loss, and cash flow.  My post focused on the cash flow, as it’s the most important real-time report for a bootstrapped / low-capital startup.  He also has his own post on Budgeting in a Small, Early-Stage Company.  I’ll explain why I disagree with his recommendation (at least for the very early stages) but you should go read everything he’s written.

I still think that annual budgeting, as he recommends, is not useful in the early stages, when your business plan, revenue model and cost structure are changing frequently.  Focus on your market fit, your repeatable revenue model, and watch your cash.  Once you’ve accomplished those (reaching the Optimize and Scale levels of the Startup Pyramid @seanellis) then your company will be static enough to spend the time on annual or semi-annual budgets.

Moving forward, I hope to crank out a few more posts on lean processes that I’ve used in the past so we can get away from old BDUF time wasters throughout the company.

Startup Reading – Do better in stressful conversations

Standard

Startup Reading is an ongoing reading list of articles and resources that I think will be of great value to startups and entrepreneurs.

Taking The Stress Out of Stressful Conversations

full PDF $6.50 from HBR

There are three common patterns of stressful conversations in this article, and I’ve had the pleasure of experiencing each of them, almost exactly as they play out in the examples.  Stressful conversations aren’t something that can be avoided, but in fact are probably some of the most important conversations you will ever have with your co-workers, partners or employees.  The times when emotions are running high and important information needs to be heard are critical make-or-break moments for your relationships and, over time, your company.

Luckily, there are a few key findings from behavioral research that give us tools to use when preparing for a stressful conversation or managing one that’s gone seriously sideways.  The situations and tactics are well described in the article, but a few brief extractions are:

– Disarm by acknowledging responsibility for your part of a problem, even if it’s in the form of “I feel like I’ve let you down by not bringing this up in the past, because I value our relationship and your contributions here, but we need to rectify this issue…”

– Disarm by restating your intentions – often people hear something completely different from your intentions, so it’s not necessary to give ground but instead work to clarify what you really mean: “I can see how you took that from what I said.  That wasn’t what I meant though, so let’s go through this again.” – Don’t argue with them about their perceptions, instead take the responsibility for aligning your words with your intentions.

– Fight tactics, not people.  Some people use aggressive “thwarting” tactics that prevent you from making your points.  The best way to neutralize a tactic like this is to name it, as people are generally not comfortable raising the bar and continuing to be aggressive once it’s out in the open.

A worthwhile read, that pretty much anyone can use to improve their conversational abilities where it’ll do the most good.

Agile Budgeting For Startups – Cash is King

Standard

Budgets are a waste of time.

In startups and small companies, the business or strategy can change every few months and the revenue and expenses can swing wildly monthly. In an environment of constant change, it’s a complete waste of time to put the effort into an annual, quarterly or even rolling budget. What you can do instead is implement a few monitoring and control systems, so that you always know exactly what the financial picture is but you spend the minimal time on the processes. I’d like to put together a few standard tools that startups can use to manage their finances in an agile way – continuous improvement, low process overhead and immediate feedback. Let’s work on Agile Budgeting.

UPDATE: I should note here that, as we discuss in the comments, this post and this process really apply mostly to bootstrapped operations with small amounts of capital.  Doesn’t have to be early-stage, I used this process in years 8-10 of my company.  Use it when you don’t have huge amounts of padding.

The most critical piece is your cash flow management. You need a system that will give you an accurate picture of your bank account balance right now, as well as at various points in the future. Will you make payroll on the 15th? Will you make rent on the first? When in the next two months should you buy those Aerons? I’m going to describe a process that should give you this transparency without spending more than a few minutes a day on it.

Before starting: Get a bookkeeper as early as possible. They’re inexpensive compared to software engineers or biz dev folks, and they should keep your finances up to date with few mistakes. Both are critical to your company’s success. No amount of light process will save you from doing hours of data entry without a bookeeper.  This model is something that you should (we did, at least) update every day, so when there’s a decision to be made you can pull up the spreadsheet and know that the numbers were accurate this morning.

Before working on your cash flow, you need a clear view of your situation today.  A worksheet like this can be quickly updated from your online banking by your bookeeper every morning, and as cheques are written and payments received.  The available balance calculated at the end here is the starting balance for your cash flow, so it must be accurate.  That’s why we include outstanding cheques and undeposited payments.  We made a policy of keeping a minimum balance in our main account, shown here as $5,000 to guard against bounced cheques or variances in timing.

Once you have an available balance, you can start forecasting your cash flow.  As with anything else, start with the big blocks and work your way to the little bits and pieces.  Here’s the basic framework, starting with today’s balance and a few of the big monthly items.  We always start with that accurate balance so that as it gets updated you see where your planning went wrong and you’re going to run out of cash 🙂

We always preferred to use a separate account for tax liabilities, so here you see the payroll witholdings going on when payroll is made, and coming back out before the payment is due the next month.  Things are pretty red here!  But that’s ok, we haven’t entered any income yet.

Next step is to get a clear picture of your expense patterns. Summarize ALL of your expenses for the past few months and identify the things that happen regularly. This spreadsheet lists the expenses, recent monthly sums (doesn’t have to happen in every month, but often enough to be a normal part of your operation), and what dates you usually pay it on. Things without set payment dates I’ve split evenly between the first and second halfs of the month (eg. Lawyer).  The only things being left out of this list are the ones we’ve already entered on the cash flow.

I split the expenses into month-halfs because generally it’s not important what date it happens on, but whether it happens before or after your big fixed-date expenses: rent and payroll. Also you’ll see in a minute that we can fine-tune this much more.

In this list you have captured all of your outflows in the past three months.  This spreadsheet goes into your cashflow Excel file and gets updated probably twice a year.

Now, depending on the level of detail you want, you pull out the regularly recurring and fairly fixed stuff and enter it as new row items on the cashflow sheet.  I would enter items such as Dell Lease, Health Insurance, Hosting, etc… because they happen monthly, I know what date they happen on, and I have a good idea of the amount.

The rest of them get bundled into “Misc Expenses”, which you enter twice a month.  Once before the 15th payroll and once before the month-end payroll.  Now our cashflow worksheet looks like this (new rows highlighted):

These numbers are based on the averages from the previous three months, but when the expense rows are being entered for a new month, use the expected value.  For instance, LocalHost should be entered at the recent rate of $1,800 not the average of $1,467.

Do the same process for your revenue.  Make a list of your regular customers, the normal payment amounts, and when in the month they usually arrive (customers tend to have a pattern of how long they take to pay, and of course it depends on the payment method).  Fill in the expected payment dates and amounts and you have a complete cash flow prediction for a typical upcoming month:

Now comes the process part.  You’ve constructed a great starting point, now you make it repeatable, and you ingrain it as part of your routines.

Update balances – Usually performed every morning, the bookkeeper will check the online banking and update the balances sheet of this workbook.  The updated Total Available carries through to the Cash Flow sheet, perhaps significantly departing from what was expected for this point in the month.  Preferably he would also scan the Balance column of the Cash Flow sheet for any red numbers and bring them up for discussion.  In our case he also updated the current exchange rate.

Pre-fill months – Done monthly by the bookkeeper, the template rows (the set of standard expenses and revenues) are filled in to keep the timeline extending about two months out.  The owners should review after this to see how realistic the numbers are – the goal here is that the template set should be a pretty good picture of reality, and there will frequently be tweaks needed.

Enter specific numbers when known – The bookkeeper will update the template rows when they learn of the real amount for any of the transactions.  For example, you may receive the invoice for your hosting and update the amount for the payment row that occurs a few weeks later.  The bookkeeper should also enter any additional transactions that they learn about, and flag them for discussion or review (surprise payments are no fun).

Move the horizon – As you go through the month, the bookkeeper should be removing (or hiding – sometimes you need to look back) rows that have actually happened, leaving any that haven’t, and updating the “Misc Expenses” rows with new amounts as some of those component transactions occur.

Use it – If these are happening, you will be able to pull up the spreadsheet at any time, see where cash crunhes occur in the next month, and shuffle things around.  Most cash flow issues are related to timing, so opening up the sheet and seeing a red balance in a few weeks allows you to get on the phone with a client and speed up their payment.  You’re reacting in real time to accurate information about the future. When we used this at my company, my partners and I would pull it up a few times a week, adjust the entries with what we knew, and check for cash crunches as far out as two months away.  This is invaluable.

Some of the expenses are more for padding than anyting, such as the Lawyer row.  It doesn’t happen every month, but if you’ve budgeted a normal amount you’ll never get caught without the money to pay.  You’ll never be annoyed by having some extra money in the bank.  In fact, we would usually enter specific padding transactions in our monthly template for expenses that only happened annually, such as an amount for the annual tax preparation.  These can be entered as a monthly transaction for a portion of the amount, which is then put into a different account, or added as a running “earmark” item on the Bank Accounts spreadsheet (like the “Minimum $5,000 balance” item in my example at top).

If you can make this group of worksheets a part of your (well, your bookkeeper’s) daily routine, the ongoing effort is very small and the accuracy is very high.  Depending on your needs, I’m sure it would also work fine being updated weekly, but I find it’s best to have it accurate continuously as the situation changes.

PLEASE let me know if you apply this, I’d love to hear what modifications you make to the framework in your situation.  Let’s keep improving on this model and passing it around.

Here’s the sample workbook I’ve been using for this post:

Agile Budgeting – Sample Workbook

UPDATE: This process and this workbook are both released under CC – Attribution Share Alike.

UPDATE: I’ve posted some followup comments and resources here: Agile Budgeting Followup

Schedule some slack

Standard

I was having a beer with a friend yesterday, discussing how I’ve crammed my life close to the bewaking point with a toddler, a new baby, an MBA program, a job search, some mentoring and networking, and he asked me what pearls of wisdom I could bestow on him for when he finds himself in a similarly hectic spot.  And I came up blank.  It’s not that I haven’t found shortcuts and processes that let me handle this without losing my head, it’s that I haven’t stepped out of the flow, gone to a 10,000 foot view and checked out what’s going on.  This reminded me of something one of our profs said when discussing innovation and creativity: there can be no innovation without organizational slack.  If you (I) don’t stop fighting fires or attacking your task list, you’ll (I’ll) never improve our abilities/capacity to deal with the situation.  No matter how busy you are, if you don’t stop to breathe and evaluate your activities and formulate some strategy, you’re going to get demolished by something you didn’t see coming.  Keep your head up!

So today’s advice / resolution is to create time for slack.  Even with my schedule being crammed to 30-second intervals (I’m working out, doing dishes and debating preschool with my wife while I write this – partially kidding) I figure I can make the time to sit alone at a coffee shop or my front stoop for an hour every week and let myself think about bigger pictures than my todo list.  In fact, if you’re busy like me, I think it’s required that you put it in the schedule. That’s what they tell us about workouts and it applies here – put it in the calendar, make an appointment to do it.

Sometimes though there just isn’t time.  And I think when that happens, in a lot of cases, you can move towards it incrementally.  If you’re fighting fires 18 hours a day, and your organization or family is always in crisis mode, there’s probably something wrong.  You might not be able to go ponder what that is without seeing something else blow up, so just ask five questions when you fix the problem.  Address the immediate fire, sure, but also use this technique to tease out the root causes and commit to making a corrective action at each level of the analysis.  This way you slowly, incrementally improve your processes and behaviors, instead of just dousing a single flame.  Over a few iterations you will start to see the number of fires decreasing, and you can pop up to 10,000 feet for a few seconds for a clear view.

The Startup Library

Standard

I love books.  I’ve done almost all of my learning from books and web pages.  So following up on a post by Boris about finding startup books in Vancouver, I wondered what would be the required reading list for a startup (or a Bootup cohort company).

Here’s my tentative list, from personal experience.  What else needs included?  Is there a great Drupal book?

Business

  • Four Steps to the Epiphany – Steve Blank – on my TO READ list, the bible of customer development.
  • Startup Lessons Learned – 2008-2009 – Eric Ries – I’m not listing blogs on this post, because there’s plenty of resources for that.  But I get to cheat and include this book form compendium of Eric’s posts.  This material is invaluable, for the detailed discussion of continuous deployment practices and the lean startup business model.

Engineering

  • Test Driven Development by Example – Kent Beck: the how-to book for applying test-driven development (a great Extreme Programming technique for rapid reliable code, and very applicable to continuous deployment) and unit tests.
  • Refactoring to Patterns – Joshua Kerievsky: if you’re writing a lot of code hopefully you’ve read both Refactoring and Design Patterns, but this book puts the two together and gives you strategies for migrating spaghetti legacy code to nice patterned code.
  • Facebook Cookbook – Jay Goldman: this is a great book that covers all aspects of Facebook platform and Connect programming, from ideation and planning to viral marketing and API code samples.  The only downside is that the API is constantly changing and portions of this were already out of date when I bought the book last year.

Personal

  • Getting Things Done – David Allen: on my TO READ list – sounds like the least gimmicky, most lean and effective way to stay focused on what’s important and cut out your wasted cycles.
  • Getting To Yes – Fisher,Ury: how to negotiate effectively in all areas of your life (with employers, investors, spouses, fishmongers) by avoiding positions and addressing underlying interests.
  • The Seven Principles for Making a Marriage Work – John Gottman: <preach>Some things are more important than your next round or release.  Without strong support at home you can’t succeed, and whether your startup succeeds wildly or flames out, you will have failed if you lose what’s important to you.</preach>

Please, let’s fill this in with more.  And then get Chapters or Amazon to sponsor a set for new cohort companies 🙂

Motivate with PROGRESS

Standard

In a recent HBR article (What Really Motivates Workers) it was revealed that workers are motivated less by the usual suspects (incentives, recognition, …) than we thought and that in fact progress in their work is the key driver of daily satisfaction.  How can we take advantage of this in software development to crank up real and perceived progress, and keep workers happier on a daily basis?

First, it seems we’re an industry uniquely situated to take advantage of creating perceived progress.  I don’t mean false progress, but with the real time metrics available such as compile errors, bug databases, unit tests passed or test runtime, we have the tools to demonstrate progress in several ways depending on the project.  The trick may be to identify the ones that are most valuable to your product, and to keep some perspective on how much you emphasize them.  If you keep cheering up your team by pointing to the diminishing bug list, you’ll have a hard time rallying them when a large dump of bugs comes in from new testing.  Keep it focused on customer satisfaction and percent of code under testing.

Second, there are methodologies and tools for software engineering that support constant progress and prevent the kind of backslide that kills morale and motivation.  Specifically, I’m thinking of agile methods that cut out time spent on exhaustive planning and requirement specifications that doesn’t feel like progress to the person writing it, and creates the opportunity for big negative progress when it turns out they’re misguided.  Then tack on test driven development to allow constant, incremental additions while locking out the possibility of backsliding again, and continuous integration and deployment to keep your work rolling forward instead of halting and going back.

These are very pragmatic, and well tested methods that, used together, will hugely increase the number of days your team can go without a big backslide, adding incremental improvement or capability day in and day out.  And, according to the article, this is a key driver of motivation.  So in addition to the benefits we already knew about (faster results, less wasted time, better tested code, no ‘ocean boiling’ integration and release cycle) we can now say that agile methods keep your team happy and motivated.

What other techniques support constant progress?

The need for authenticity in startups

Standard
The need for authenticity in digital media companies
As we begin to trust more and more of our private data to cloud companies such as Dropbox, Mint and Facebook it is becoming critical that the companies clearly communicate their intentions and principles, and then unfailingly act on them.  They must be authentic.  In the current online ecosystem of small, single-function companies such as Dropbox and Mozy the relative anonymity of the company hasn’t slowed adoption by users.  It seems that when it comes to trust, no information is just as good as positive information.
This can’t be sustained as the company grows though, as sooner or later the public will get more information about a company and its owners, executives either through direct communicatin or the press.  Once this happens, the trust will only be maintained if the personality of the company is trustworthy (think “Don’t be evil” over a chair-throwing Ballmer) and they act authentically to support their personality.
For small companies, the trust seems to start at a tangible level, based on things like privacy policies and practicalities.  I trust my data to Dropbox because really, with 3M+ users, they’re not going to dig through my docs.  As the company develops more personality, their actions and communication need to be authentic to that initial trust in order to sustain it.  I trust my email to Google and my friends to Facebook because I know that while they analyze my data to show me ads, they won’t jeapordize my trust by acting inauthentically.  In both cases, their trustable personality has become their greatest asset.
What do small companies need to do?
1) Establish tangible trust.
Have a privacy policy.  Clearly communicate how you store and use people’s information and data.  In all of your communication, stay in alignment with those policies, and
2) Always communicate authentically
Authentically means you act in accordance with the trustworthy policies you established in (1).  This is where your corporate personality starts to take shape, and you need to work to communicate in a professional, trustworthy way.  I’ll trust data to a few kids in a garage, but only if I thnk they have a long view that values retained customers and pride in their work over a quick buck from a marketing company.
3) Recognize that trust as your most valuable asset.
Once you have company that customers implicitly trust, you have to protect that with everything you’ve got.  Your employees and communications all will impact your ‘personality’ in a postive or negative way.

As we begin to trust more and more of our private data to cloud companies such as Dropbox, Mint and Facebook it is becoming critical that the companies clearly communicate their intentions and principles, and then unfailingly act on them.  They must be authentic.  In the current online ecosystem of small, single-function companies such as Dropbox and Mozy the relative anonymity of the company hasn’t slowed adoption by users.  It seems that when it comes to trust, no information is just as good as positive information.

This can’t be sustained as the company grows though, as sooner or later the public will get more information about a company and its owners, executives either through direct communicatin or the press.  Once this happens, the trust will only be maintained if the personality of the company is trustworthy (think “Don’t be evil” over a chair-throwing Ballmer) and they act authentically to support their personality.

For small companies, the trust seems to start at a tangible level, based on things like privacy policies and practicalities.  I trust my data to Dropbox because really, with 3M+ users, they’re not going to dig through my docs.  As the company develops more personality, their actions and communication need to be authentic to that initial trust in order to sustain it.  I trust my email to Google and my friends to Facebook because I know that while they analyze my data to show me ads, they won’t jeapordize my trust by acting inauthentically.  In both cases, their trustable personality has become their greatest asset.

What do small companies need to do?

1) Establish tangible trust.

Have a privacy policy.  Clearly communicate how you store and use people’s information and data.  In all of your communication, stay in alignment with those policies, and

2) Always communicate authentically

Authentically means you act in accordance with the trustworthy policies you established in (1).  This is where your corporate personality starts to take shape, and you need to work to communicate in a professional, trustworthy way.  I’ll trust data to a few kids in a garage, but only if I thnk they have a long view that values retained customers and pride in their work over a quick buck from a marketing company.

3) Recognize that trust as your most valuable asset.

Once you have company that customers implicitly trust, you have to protect that with everything you’ve got.  Your employees and communications all will impact your ‘personality’ in a postive or negative way.

Entrepreneur’s Creed

Standard

From the book New Venture Creation, which lists common responses when entrepreneurs are asked an open ended question about what they believe to be the most critical concepts and skills:

  1. Do what gives you energy – have fun.
  2. Figure out what can go right and make it.
  3. Say “can do” rather than “cannot” or “maybe”.
  4. Illegitimi non carborundum: tenacity and creativity will triumph.
  5. Anything is possible if you believe you can do it.
  6. If you don’t know it can’t be done, then you’ll go ahead and do it.
  7. The cup is half full.
  8. Be dissatisfied with the way things are – and look for improvement.
  9. Do things differently.
  10. Don’t take a risk if you don’t have to – but take a calculated risk if it’s the right opportunity for you.
  11. Businesses fail; successful entrepreneurs learn – but keep the tuition low.
  12. It’s easier to beg forgiveness than to ask permission.
  13. Make opportunity and results your obsession – not money.
  14. Money is a tool and a scorecard available to the right people with the right opportunity at the right time.
  15. Making money is even more fun than spending it.
  16. Make heroes out of others – a team builds a business, an individual makes a living.
  17. Take pride in your accomplishments – it’s contagious!
  18. Sweat the details that are critical to success.
  19. Integrity and reliability equal long-run oil and glue.
  20. Accept the responsibility, less than half the credit, and more than half the blame.
  21. Make the pie bigger – don’t waste time trying to cut smaller slices.
  22. Play for the long haul – it is rarely possible to get rich quickly.
  23. Don’t pay too much – but don’t lose it!
  24. Only the lead dog gets a change of view.
  25. Success is getting what you want, happiness is wanting what you get.
  26. Give back.
  27. Embrace sustainability.
  28. Never give up.

A few old chestnuts in there, and a few that really ring true.  I especially like 8, 11 and 16.

<a href=”http://www.amazon.com/gp/product/0071276327?ie=UTF8&tag=riverstyxnet-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0071276327″>New Venture Creation: Entrepreneurship for the 21st Century</a><img src=”http://www.assoc-amazon.com/e/ir?t=riverstyxnet-20&l=as2&o=1&a=0071276327″ width=”1″ height=”1″ border=”0″ alt=”” style=”border:none !important; margin:0px !important;” />