Getting shit done

1617 words

A quick note - in case you didn't realise when you read the title of this article there's a bit of profanity. This is because when it comes to getting shit done, there's a lot of passion involved, and the emphasis can sear the lessons into your mind. They seem obvious but they will serve you well. You have been warned.

The scenario

When we are building awesome software with limited resources, we end up having to make tradeoffs and sacrifices. Sometimes these sacrifices come at the cost of your end user in the form of reduced functionality, making an MVP is the classic example of this. Sometimes this comes at the cost of having nice, flexible, maintainable code. Most of the time it's a mix of the two.

Chances are if you're working on an MVP you need to get something out the door as quickly as possible. That was how it was with Connexin's fibre launch. We had to get it done as ASAP, with only the absolutely core features, and make sure it worked well doing that before adding new features (we've since beefed it up considerably). Making sure it worked was the most key part because if it doesn't work for the user you're fucked. That's pretty much the case with all projects after you've been working on hyping everyone up to buy your product and need to follow through on your promises.

if it doesn't work for the user you're fucked

When you have hard decisions to make about what to do and who's going to do it - you've got to come up with a plan that balances the present and the future. Your present need to get shit done, and your future need to get more shit done.

The critical path

When planning work, you need to get your start and end goals and work towards the middle. What absolutely needs to be done to get from the start to the end here? Let's say you're making an e-commerce website, and you want the following.

• Frontend wireframe
• A checkout system
• A basket system
• A catalogue of products
• Email marketing
• User accounts
• Loyalty points
• A blog
• Discounts and sales
• An advertisement setup
• A record of sales
• User analytics to see what people look at and buy

There's a lot to process here but what do we actually need here? Go read it again. If you're being agile, you will create the absolute minimum you need to see if you're on the right path. I think we can narrow this down a bit. Firstly, we don't absolutely need a blog to run a website, so let's get rid of that for now. Same with sales and discounts, as well as email marketing, user accounts and loyalty points. When you're making those things you're actually making a lot of assumptions about how people are going to interact with your site, starting with the assumption that people are going to interact with your site at all.

Even if you have time and resources to get all these bullet points done, I still wouldn't recommend doing all these for release day 1. I would want to invest a bit in building a reliable framework for building, deploying and testing your codebase, as once you've got your MVP out you're going to want to ramp up feature production anyway. Best to be prepared for that and only work on the things you have evidence are going to work.

• Frontend wireframe
• A catalogue of products
• A basket system
• A checkout system
• An advertisement setup
• A record of sales

Once you've been thinking in terms of "what we want to make" think about "can this work without feature X and still be a bearable user experience?" - where you draw the line may be different to where I did, and when that happens you just need to talk it out and come to an agreement. If you can't come to an agreement, start with the features that are shared and go from there. Once you've had a crack at it you'll all understand the problem better.

Executing the plan

Chances are you're in a hurry, and if you aren't the main stakeholder, the main stakeholder is wanting results fast. Here is the absolute key thing to bear in mind:

keep the plan simple

I am guilty of making things more complicated than they need to be, it was the main constructive feedback in my last performance review. When you're making something in a rush, you don't have the luxury of complicating things, and the more you complicate things, the more technical debt you pile up. I was talking to a friend who said when technical debt piles up, you end up having to spend ages to pay it back, or go bankrupt and abandon your project and start again. Both of those would be really bad for morale, stop your team from being productive for a long time, and screw up your business big time.

Work out your dependencies

When you're developing you've got to break things down into smaller and smaller chunks, and you can work out what order they need to be done. For example, you don't need to have a full catalogue of products done before you can get started on the UI for the website. You can just create a few example products in a JSON object or something and use that instead. Similarly, we don't need the full checkout process to be complete before we develop the system we use to keep records of our sales.

I made a flowchart to visualise how I would break down this into dependencies, it's important not to overthink it. The more you think about it the more complicated it gets. As long as you know you've got all the right pieces you can work out the rest as it comes up.

This shows you how much you can parallelise the development. If you have one brain working on this, then it just lets you know what you need to do to get to the end, if you have more brains, it lets you know what you can split up. For example, if you had 2 people, you can have 1 person doing the basket and checkout, with the other working on the catalogue and frontend styling, and so on.

One key thing to note here is that you can sort the advertising at any point in the process, it just needs to be done before launch. You could even sort it before development, or make it the last thing before launching. The point is it doesn't depend on anything else, each is just a stream that feeds into the greater project flow.

Divvy it up

if it takes one dev 9 months to make a baby, does it take 9 devs 1 month?

Just because you have 2 people working on something doesn't mean that it will take half as long, but it will have other benefits, like being able to use the strengths of each developer, shared code review and therefore a better and more reliable end product. Another benefit to working out the dependencies is that when you finish you know where you can get cracking on something else without stepping on anyone else's toes.

Get shit done

Enough messing around, time to get into the action. Depending on how long you have, you might want to cut a few corners when it comes to keeping your website flexible, for example, you could hardcode product names and prices into your code and store images in the public folder on your repo. You could also rely on manual testing to make sure things keep working. All of that is fine if you're up against it, but it's not sustainable.

Icarus flew too close to the sun and ended up in the sea, think you'll be any different?

Try to get at least something set up in terms of testing, some unit testing can't go amiss and some website simulation testing can help a lot when it comes to making sure your key processes keep working. In an ideal world you'd be using test-driven development and locking everything down with unit tests but that's not really always feasible in the real world with real deadlines. The flip side is at some point you'll end up with a garbage product that you spent a lot of time and love crafting that now falls over like a Jenga tower as soon as you try to change anything. If you don't set it up for the MVP, set it up for the release after MVP. The business will thank you by continuing to run smoothly.

Every task you do without setting up proper maintenance and unit testing is taking a block out of the Jenga tower. Once it falls over you can't really blame the person whose slip brought it down. I've worked on projects where the production system suffered a major problem that would have been solved by adequate testing, and it's frustrating for everyone involved. I think most people who've been moving fast have broken things. The point is to make sure it doesn't happen again.

Moving onwards

Congrats, you made it to the MVP launch, now as you wait for initial feedback, shore up your systems, and get the team ready to work on the next set of features, the real work is about to begin.

The difference in work style between trying to get something out of the door and becoming the best in your class is stark. Once you have something out you can have a much more methodical approach to things. I've worked on frantic projects in getting shit done mode with limited resources and also on much bigger teams, bigger output, and bigger projects where we can think in bigger timelines. Both are great fun, and both can be very hard.

At Connexin we've been growing the team considerably and shoring up our codebase, doing major refactors and getting things ready for the next big push. It's going to be great.