An intro to breaking big things into small things

Around 430 BCE, the Greek philosopher Democritus had a thought: that something can only be divided so many times, until it becomes something indivisible – or “atomon” (where we get “atom”). Nearly two thousand, five hundred years later, the developers at TwoPi Code have a similar thought: how do we divide what  a client wants into its smallest parts, so we can best understand what they need, and how we can deliver it to them?

You see, developers at TwoPi Code are more than just a group of talented writers of code; almost more importantly they are masters of taking the expansive vision that our clients present to us and breaking it down so that not only we can understand it, but so that the client can understand it in greater detail themselves.

But why should we do that? Surely a client should be able to say to us “I want to make an online store”, then we crack our knuckles and start hammering away at our keyboards.

Well yes, we could do that; but let me tell you the fates of projects that have dove head-first into the doing before handling the breaking.

1. They’re almost always over budget, and out of time.
2. They don’t scale, and sometimes require a rebuild to implement new features
3. They’re often missing important (or sometimes essential) features
4. The client doesn’t know what’s going on

When clients come our way with the horrifying aftermath of these types of projects (what we call rescue projects), we try our best to revive them; but more often than not it’s more cost-effective to start  the project from scratch instead of trying to frankenstein’s-monster something that was dead from the start.

The TwoPi Code Method – A practical example

Why does this happen? Well, the best way to show why something  is terrible, is to show how the alternative – the TwoPi way – is better. Let’s start with the same premise: A client comes in and says “I want to make an online store.”

What does a store consist of?

1. Products
2. A Cart
3. A Checkout
4. A Confirmation/Reciept

That’s not so bad, it’s only four things. Except we’ve only just gotten started.

What does a product (in relation to an online store) consist of?

1. Name
2. Price

But now, before we’ve started writing any code, we’ve got questions. We’ve seen and worked on stores before, and they have many different things. So we’d go back to the client and ask:

• Do products have descriptions?
• Do products have categories?
• Do products get discounts?
• Do products have images?
• Do products have options (like size, or colour)?

… and so on and so forth. Now the client has thought of some of these things, they likely have an idea of what products they’re selling. So they tell us at TwoPi that what they’re selling are subscriptions to things, and these things would indeed be grouped by categories, and sometimes these subscriptions would get discounts.

So we go and break things down again (this time in relation to categories), and come across more questions!

• Can things belong to multiple categories?
• Are categories able to be renamed?
• Does the client want to be able to add their own categories?
• Can discounts be applied to whole categories, or only to individual subscriptions?

Now the client has to think, they haven’t considered these questions. The process of breaking down the project has helped reveal functionality that the client didn’t even know they needed. But the client has a relatively strict budget, so they need to know how long the options would take, so they ask for some time comparisons.

Now, since we’re experts and have worked on similar things before, we at TwoPi know that to be able to add and modify categories would require an interface, its own set of functions, and so on. Having products fulfilling multiple categories needs an extra table in the database. So TwoPi gives some options:

1. Having a list of unchangeable categories will take 15 minutes
2. Having a list where you can modify and add categories will take 2 hours
3. Products having only one category will 15 minutes
4. Products having multiple categories will take 30 minutes

Seeing the estimates, the client  thinks… while adding and editing new categories would be nice, it doesn’t happen that often so it’s not urgent; but it is necessary to have multiple categories for a product. So we can put a number on the category feature – 45 minutes!

Now we’ll skip ahead to the end of this breaking down phase. TwoPi and the client have worked hand in hand fleshing out the system and its intricate details; and in the process have helped the client realise some features that are essential for their online store to be successful. We can total up the estimates for all the small, individual modules of work to get a final ballpark  figure of (let’s say) 120 hours of work. The client’s a little nervous, their budget can only handle 105 hours, and they express their concern.

Not to worry! Because the project has been broken down, we know how long each feature will be. We walk through some of the extraneous items, reducing the scope of the project. Maybe instead of afterpay, paypal, credit card and direct debit integration in the checkout, we strip it down to just credit card and paypal for the release. Perhaps the cart doesn’t need to be dynamically draggable to any edge of the screen at launch. After some pruning, the ballpark has been reduced to 100 hours, and the client gives the go ahead to get started.

The project runs, and each portion of work (or ticket) is now visible and trackable by the client, and one by one they see the work get marked as completed. Some things take a little less time than estimated, some things a little longer. Halfway through implementation, the client decided that they really did need  afterpay after all, and requests for it to be added back into the project’s scope, knowing it will take another seven hours to implement. To compensate for the additional time, the client gives the go ahead to remove a coupon code feature that wasn’t actually necessary at launch time.

Finally, at the end of 100 hours of time spent, the online store is launched and the client is making some money. With revenue coming in, the client now has cash flow to pay for those additional features that had to be stripped out before; already tasked up and time-estimated and ready to be implemented.

The risk of not breaking down a project – the ThreeDee story

So what happens when you don’t break down a project? Let’s refer to a non-TwoPi development team – let’s call them ThreeDee. The client has told them to make a store, said they’ve got a budget for 105 hours. ThreeDee confirmed that they can get it done in 105 hours, cracked their knuckles, and gotten straight into it. After a week, the client has no clue where they’re up to, and rings to find out.

“It’s going fine, everything’s on track.” Says the ThreeDee developer.

“What are you up to?” Asks the client.

“Just defining products now… oh, a quick question, do they need categories?”

“Yes, they do.”

“Alright.”

They hang up.

Two weeks have passed, the occasional question has come to the client by email, along with assurances that everything is going fine. Finally they get an email, ThreeDee’s inviting them for a quick demo of some features. Excited, the client accepts, and travels to the ThreeDee office to see the demo. They show off the new “categories” feature, you can add, edit, delete categories, change the colour, the font. You can give a product several categories. It’s a little buggy (it’s still in QA according to ThreeDee), but it looks nice.

“How’s the cart going?” Asks the client.

There’s a pause, “We’re working on that next.”

“Oh… alright, what about payment? I was hoping to have afterpay and paypal integration.”

Another pause, “We were thinking of using PaymentProviderX for payments.”

“Do they do paypal and afterpay?”

“We’ll get back to you on that.”

ThreeDee assures the client that everything is going well, and they’re still on track to hit that 105 hour estimate, and the client leaves, a little more nervous than before; but they’re already 70 hours in, so it’s too late to pull out now.

It’s been a month, and the client has received their bill for the month’s work – 130 hours. They call up, asking for an explanation. Apparently a few features took longer than expected, and it was difficult getting Paypal and afterpay working with PaymentProviderX. The cart’s still not done, and checkout still needs work. They’ve also seemed to have added a completely unnecessary login system for customers, and there’s no way to add discounts to products! The project continues to spiral out of control, more and more hours get spent trying to get something workable out the door.

This scenario may seem like an exaggeration, but unfortunately it is not. Clients and companies that think that jumping into the code writing immediately will save them time and money in the long run end up with cobbled together, bloated messes that are filled with bugs and are very costly to improve upon. I’ve had to work on the aftermath of such projects, and it can take dozens, if not hundreds of hours to get these projects to the state that the client is satisfied with before launch.

Why does this happen?

When you don’t break down a project, you open yourself up to three opportunities for failure. Using the ThreeDee example, I’ll outline them.

105 hours seems like a lot of time… until it isn’t.

Without breaking down a project into its smallest parts, developers don’t actually know how long something will take. Everyone has had a school project, one that’s due in a month, and you start confident; after all the deadline is month away. Then you’ve still got plenty of time, it’s still two weeks to go! One week? I can get it done, easily! Then it’s the night before and you’re scrambling to finish the project before morning.

While the ThreeDee developers weren’t just sitting around, they were looking at their time allotment in too broad a way. They spent a large allocation of their time focusing on a feature (the categories feature) without realising how it would take away time from the other necessary features of the project. After all, they still had 70 hours left, that feels as though it’s enough time, right?

A TwoPi breakdown is the opposite. TwoPi’s developers know how long something should take, and even how long small parts of a feature should take; so we use our budgeted time efficiently and effectively. There’s no risk of spending a disproportionate amount of time on a single feature, because we’ve already determined the length of time beforehand. We minimise the risk of going over the client’s budget, and the client can track work as it’s being completed.

A client knows exactly what they want… until they don’t.

Without breaking down a project into its smallest parts, there’s a decent likelihood of something being overlooked. In all my years as a developer, there has never been a client who knows exactly what they want, not a one! Clients have a picture in their minds, they’ve thought about their project, and they have an idea about what the end result is going to be. The details, however, are always fuzzy around the edges.

The ThreeDee developers had surely made an online store before, but without diving deep into what each part of the project consisted of, they relied on their own assumptions and past experiences to fill in the blanks, and ultimately deliver something that – even though the client may not have known exactly what they wanted – once it was put in front of them, they just knew it wasn’t that.

A TwoPi breakdown isn’t a one-way street, we’re going to be asking questions to not only paint a clearer picture for ourselves, but also assist the client in realising the details in their project that they would have otherwise overlooked. It’s not uncommon for a TwoPi breakdown to identify potential errors in the system and security issues before we’ve even gotten to testing, and even more often we reveal additional features that the client will want to add after the project is done! Most importantly, we’re not going to be wasting time implementing things that the client doesn’t want or need; and the client will know exactly what features they’ll be getting ahead of time.

A project is complete… until it’s not.

Without breaking a project down into its smallest parts, you can’t determine your minimal viable product. Rome wasn’t built in a day, and neither were any of the largest and most successful websites or digital solutions. The real work of a project is, funnily enough, after it first gets out the door. A minimal viable product, or MVP, is exactly what it sounds like – the minimal amount of features for a project to be viable for release. This helps keep projects slim and streamline, scalable, and gets them released faster, and the client getting their cashflow sooner.

ThreeDee didn’t have a future-facing plan when tackling the client’s requirements. They saw an end goal, and nothing beyond it; so the project quickly became bloated and over-budget as features were worked on with unnecessary detail. After all, once the project was complete, they’re done. This also means that the code that they’re writing probably isn’t scalable either, just hacked together to get the “final” product out the door; meaning anyone in the future that works on it will be spending many more hours than necessary trying to decipher and expand upon what already exists.

When TwoPi breaks down a project, we quickly identify the MVP, and then determine how much extra time we have to work on those “nice-to-haves” instead of those “must-haves”. Our relationship with our clients isn’t one of “You’re project’s done, see you later”, but one where we hope to have a partnership. We know that a digital project is never really complete, and that they’re perpetually in a cycle of updating, adding new features, and evolving to fit evolving needs and markets. We also write code in the same way, taking into account features that the client wants to have in the future and writing scalable code that is easy to expand upon; saving time and making implementing or evolving features smooth sailing.

Breaking things down: in summary

Breaking down a project is one of the most important things we do here at TwoPi Code. It’s how we avoid going over a client’s budget; it’s how we best understand what a client needs; it’s how we are able to accurately report where we’re up to to the client; and it’s how we determine the minimal viable product that can be released so that a client can start earning on their product as soon as possible. It avoids pitfalls, results in scalable code, and overall results in a healthier digital project, and satisfied clients.