Dealing with Technical Debt

Technical debt is something that every software company has to deal with at some point. Whether it’s from bad architectural designs or just changing business needs, as some point technical debt will need to be refactored. Here’s a few tips that I’ve pulled from my experience on how to remove technical debt.

Take Inventory

The first thing you need to do to deal with technical debt is to take inventory of the entire codebase. Knowing the extent of the codebase is necessary before you can start to remove or rewrite parts of it. Using Google Analytics to understand which parts of the code get used the most can provide an easy jumping off point for web apps. Refactoring the most used portions of the website can often lead to quick wins.

Once you’ve taken inventory of your codebase it’s important to understand how certain functions get used and how they interact with other pieces of the code. If your project has tests I find that looking through these tests can provide invaluable information. Unit tests are often great at seeing the expected inputs to functions and understanding how the code is supposed to be used. If the tests are properly written it can also help you understand what interacts with what.

Taking inventory also gives you a basic checklist that you can use to keep track of what you still have left to refactor.

Have a Plan

Now that you have an inventory of everything that’s in your codebase you can start to formulate a plan on how to refactor your technical debt. I like to start this plan with a list of all the functions that are coupled together. This list gives me an idea of the functions of code that need to be refactored together and from there I can start to get an idea of the amount of time each chunk will take.

Once you have the coupled functions you can start thinking about whether or not the code needs to be refactored. In general, if something works well and still meets the needs of the users it probably doesn’t need to be changed. If it’s no longer relevant, runs poorly or is dangerous from a data integrity standpoint you should refactor it. Look for any functions that are no longer being used or have been duplicated for different inputs and see if you can remove or combine them.

Create Realistic Timelines

While you’re creating the plan to deal with the technical debt always keep in the back of your mind a running tally of how long this will take. Removing technical debt often takes a long time, especially when you do it properly. If you’re refactoring entire sections you may have to consider porting the legacy data over to the new system. This might mean creating scripts that maps your old data to your new models or if the old data models still make sense just copying the data over.

A big part of removing technical debt is talking to your users. Making sure you understand their needs and how the old code fails to meet those needs can help you understand what’s needed from your system and how you should go about refactoring the code. As you’re talking to your users make sure they’re comfortable with the proposed plan. What may work for you in your mind might not work for your users and knowing this beforehand can help lessen the friction of change.

Execute and Launch

Once you’ve determined the technical debt that you need to refactor, came up with a plan for how to get rid of it and created realistic timelines for dealing with the debt you now have to execute and launch the changes. From past experience I find that doing small changes and quick launches help ease the pain of change with your users. When you code in a silo and release large functionality all at once there’s a much bigger area for failure. Making sure you have proper test cases for all the different use cases can help mitigate some of the risk of launching large features.

Launching to a small subset of users is a great way to test the new functionality and get feedback on the changes before releasing to everyone. This allows you to validate your new code and make sure that it works. It also gives you time to create more documentation and make sure that the migration between the old system and the new is as flawless as possible.

Once everything’s ready it’s time to launch to everyone and iterate on those changes.

Preventing Technical Debt

Once you’ve refactored your code you’re going to want to future proof your codebase. The best way to do this is to make sure you have a comprehensive set of unit tests. Unit tests allow you to deploy your code with confidence, knowing that you’ll catch any regression errors. Along with tests, making sure you use common coding standards will ensure that your code will last. Finally, thinking about the future of your code base as you architect new features will help you design your code to be more future proof. When you take the time to think about your code it inevitably becomes less prone to becoming technical debt in the future.

How I Launched My First Startup

One of my goals in life was to start a company and on July 31, 2013 I launched Steep.ly. When you subscribe to Steep.ly we ship you 4 different teas every month. This allows people to easily experience new teas and flavours.

Here are a few tips I learned while creating and launching Steep.ly that I thought would be useful for people wanting to launch their own companies.

Sleep on the Idea

I had the original idea for Steep.ly 2-3 years ago. At the time I wanted to ship out bags of coffee instead of tea, but for various reasons the timing wasn’t right and I never executed on the design. Every few months I’d think about how I could get to work and I constantly thought about it. I started drinking tea a lot and in May of 2013 I knew I was ready to start this company. Having that long-lasting idea helped me finish Steep.ly. Short term ideas are often not important enough to finish.

Research

The most important part of starting a business is researching the feasibility of the company. You can have the most amazing idea fail if nobody is willing to pay you for it. Once you’ve found people willing to pay you for your idea you need to research whether you can be profitable from it. I know there are stories of companies not being profitable until year 2/3/4 but that’s not the norm. I wanted to make sure that Steep.ly was profitable from almost day one and that took a lot of research into the costs of shipping, packaging, buying the tea, etc…

Researching your company first can save you a lot of time building something that won’t succeed.

Use Tools your Comfortable With

For me, launching my first company meant removing as many barriers to launch as possible. One of these barriers was technology. It’s exciting learning a new language, using the latest and greatest framework or technology but these things take time to learn and ultimately delay the launch of your company. I stuck to what I knew (Python, Django, PostgreSQL) so I could launch quickly. Using these tools also let me fix 14 separate things that weren’t working correctly after I launched. If I had used the latest and greatest tool it would have taken me longer to fix those problems.

Just Launch

There’ll always be missing features and nice to haves that you want to add. I could easily have procrastinated the launch of Steep.ly until 2014, then 2015, then never if I had tried to put every single bit of polish on the design and every feature that I wanted. Figure out the absolute minimum that you need to launch with, do those things and then launch.

For example, Steep.ly still doesn’t have a great logo, or labels for the first shipment, or even shipping envelopes. I knew I could do all of those things once I launched and got customers.

Content is greater than Features

The biggest oversight I had when launching was not to have as much content as I should have. The number one criticism about the site was that my tea section was empty. I initially thought that didn’t matter because each month the tea selection is chosen by myself and my team but I quickly learned that people want to see what they could be buying.

Next time I’ll make sure I’ll have all the content I need and potentially pass of some features that aren’t necessary.

Leverage your Network

Once you’ve launched your company you need to market it and get the word about about it. One of the best ways I found to do this was to leverage my social network. I created a Facebook page and a Twitter account and told all of my friends, family, acquaintances and pretty much anyone I could about it. Ask people to sign up, ask people to give you money, do whatever you can to get people to sign up and tell their friends about it.

I’m still learning about running my own company so if you have any tips or tricks I’d love to hear about them. Also if you haven’t seen the copious amounts of links, sign up for Steep.ly now!

7 Musings on Minion Management

So, you’ve just been promoted to the dark side of management but you don’t know how to lead your minions? Here are a few tips on keeping your plebeians in line:

Make your Minions do the Dirty Work
You shouldn’t worry yourself about work that’s underneath you, you get paid way to much. You’ve hired coder monkeys to handle everything from downed servers at 3am to documentation to those pesky clients. All you have to do is sit back and make sure they don’t lose focus.

Don’t give any Praise
Your minions just put in 100 hour weeks to get the feature launched on time? They get paid to do that work so there’s really no need to tell them they’re doing their job. Work horses don’t need to be told they’re doing a good job every time so why should your employees? As soon as you’re done you should give them more work since that’s what they need.

Belittle your Minions
You’re the manager so that makes you better than everyone else. If they were as good as you, they’d be managing people themselves. This means you’ve earned the right to make the others know that they aren’t as good as you.

Always Leave before your Minions
Your time is way more valuable and you don’t want to wear yourself out. This means you should come to work later and leave earlier than your team. Besides, as long as you’re doing a good job guiding your newbies they should be able to carry on their work when you’re gone.

Avoid all Responsibility
If your staff messes something up it’s their fault not yours. Why should you be held responsible for something they’ve done. When the top brass asks you what happened make sure they know exactly who screwed up. This also secures your position because you’ll never do anything wrong.

Believe that your Job is more Valuable
Obviously the people underneath you wouldn’t be able to do their job without you. Who would lead them? You get paid more so that means you’re way more valuable than them. Make sure that they know you’re more valuable to the company.

Always think you are Right
Again, you’ve probably been there longer and you get paid more so that means you’re always right. When someone tries to tell you otherwise make sure you make them look bad to their co-workers; this will show them who’s boss.

If you’ve gotten to this point and haven’t realized you shouldn’t do any of these things you probably shouldn’t be managing people. If you realized that you should be doing exactly the opposite than go forth and manage! If you have any suggestions on things you shouldn’t do as a manager feel free to leave them in the comments.

Getting Ready for a Hackathon

Three or four times a year I take part in hackathons for various reasons such as networking, learning new technical skills and getting new ideas on things to work on. Every time I go to a hackathon I have a list of things that I do to get ready and I thought I’d share them with you today.

Personal Checklist:

  • Water
  • Clothes (single day/multiple days)
  • Sleeping Bag/Pillow (if overnight)
  • Advil/Tylenol
  • Deodorant
  • Toothbrush and Toothpaste
  • Business Cards

Hardware Checklist:

  • Laptop and Charger
  • Phone and Charger
  • Projector Adapter
  • Headphones
  • Pens/Pencils and Paper
  • Keyboard and Mouse

Software Checklist:

  • Technical Stack (VM’s, local machine, favourite programming language)
  • Github Repository
  • Domain Name (or at least a registrar you’re familiar with)
  • Server (Heroku/Webfaction)
  • Any SDK’s or Frameworks installed
  • Agreed upon standard tools (IRC, Editor, Trello, etc…)

Idea Checklist:

  • Basic Idea
  • Knowledge of any needed APIs
  • Checklist of Features

I’ve shown up with just a laptop and a charger before and still placed relatively high. Planning before hand just gives you that little extra advantage over the other people there. What tools/things do you bring to a hackathon?

Django Meetup – March 21, 2013

Today I had the pleasure of talking about how my team switched from PHP to Python (Django) and the realizations that I had after the process.

I learnt a lot about web development in the process and had a great time making the site better for our users.

Crafting your Conference Talk Proposal

With the voting period over for DjangoCon Europe talk proposals I wanted to take a couple of minutes and go over what I think makes a good conference talk proposal and a couple of things that you shouldn’t do.
Continue reading

Why I Became a Programmer

When I was in grade 9 I wanted to be a lawyer. I didn’t really know what that entailed and I had no idea how many more years of schooling I’d have to complete to realize my dream. In grade 10 I took my first law class and absolutely hated my teacher. From that moment on I knew I would never become a lawyer. I dropped out of law class and took computer science and fell in love. Over the years I’ve learnt more and more and I thought I’d take a few minutes to talk about “Why I Became a Programmer”.

Continue reading

Merry Christmas and Happy Holidays

Merry Christmas

Merry Christmas and Happy Holidays! I can’t believe 2012 is already wrapping up and with New Years just around the corner I wanted to wish everyone a Merry Christmas and a happy New Year.

I’ll have a “Year in Review” post up in the first week of 2013 and I’m looking forward to writing a number of great technical posts next year.

Thanks for reading and I’ll see you in 2013!

Announcing Clip – Your Easy CLI Clipboard Manager

Yesterday I finished up the first version of Clip, the easy command-line interface clipboard manager. Currently it’s OS X only but I plan to make it platform agnostic over the coming weeks. Here’s how you can get started using Clip.

Continue reading

Founders Bolt Cutter Review

bolt_cutter

Name: Bolt Cutter
Brewery: Founders Brewing Company
Style: Barely Wine
ABV: 15%

Birthdays are a special time for everyone and when a brewing company turns 15 something special happens. Founders Brewing Company hit 15 years old this year and released a monster of a barley wine. At 15% Bolt Cutter is still very drinkable with a little heat from the booze coming on at the end. This was my second offering from Founders and I’m very excited to review it.
Continue reading