Jeff Magnusson

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

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.

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

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.

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