Hero background image of many pineapples

Software Development Explained With Cars

The only thing more difficult than building software for a client, is explaining how software is built to a client.

So we sat down to explain this incredibly complicated concept the only way we knew how - with pictures, and with cars:

Software development methods explained with cars

Few people know this, but before Toggl Track became a successful time tracking app, we used to build software for other companies.

One of the biggest, persisting issues we had, was the gap between how clients see software development and how development works out in practice. Endless negotiations over budgets are perhaps the most obvious symptom here, but the divide is wider than that.

Agile development - where does the client involvement stop?

The Waterfall model, where development follows a linear path from nailing down requirements to delivery and maintenance, seems all but gone these days. Unless you're working on particularly big projects, you're better off following an agile development methodology.

The agile mindset is grounded in the fact that clients often don't know what exactly they want from a piece of software. Agile teams work in a transparent manner and keep the client involved in the development process to make sure the end result matches their actual needs as closely as possible.

It's like buying a suit from the shop rather than online - you won't ever know if it fits or how it looks on you until you try it out. And ideally, you'd have a tailor make it fit your shape.

Buying software from an agile team is like getting a tailored suit.

Except that the client wants to pay for a stock suit and if something needs fitting, they want to hold the thread while you needle away.

How to protect your development time

While agile development is about transparency and cooperation, you still need to protect your time. Here's a few things that you may have heard clients say:

"Can I sit with you so we can work on this together?"
"Can we squeeze in (this huge feature) real quick, it's very small and shouldn't be very hard."
"I have a friend who could do this in a day, could we do this at half price?"
"Can we go back to the first version? Also we shouldn't pay for this if we won't be using the code."

These scenarios can cost you a lot of time and money if you don't stand your ground. Your first line of defense is a good project management system.

If you need to be able to respond to unexpected issues or maintenance stuff, use a Kanban board. A Kanban board is essentially a to-do list that imposes a strict limit on how many work items can be in progress at a given time. It's a great system for keeping your team from getting overwhelmed by interruptions - if an unexpected issue occurs you can prioritise it, but otherwise it goes into the queue.

If you don't need to worry about maintenance or if the project isn't made up of many interconnected parts, you can use a Scrum system. Scrum limits a team to working on a highly specific goal in sprints lasting typically between 2-4 weeks. Its whole idea is to keep the team fully focused on their goal.

Both Scrum and Kanban rely on discipline to work, so make sure your client knows you're not using either just to annoy them.

Do better work with Toggl Track

Time tracking can transform the way you work. Track time, get and share insightful reports and stop wondering where your day went.

3D illustration of stopwatch with a Toggl Track icon

How to protect your budget

Protecting your time is one thing - making sure you get paid for it is another.

Let's look at why we started building a time tracker in the first place - one way of staying profitable is to put a big red price tag on your time.

There are a few benefits to tracking your development time (discussed in more length here), but the two main benefits boil down to business intelligence and transparency.

In jargon-free terms, it gives you the ability to make informed plans and to show your clients how much "small changes" really cost in development time.

Time tracking works because of the way our brains function - we do not really have an accurate sense of time, but rather a pretty terrible perception of it. Consequently, guessing how much time a project might take - especially those ever-changing agile projects - is not significantly more accurate than predicting weather with a magic ball.

True, this might not work with overly eager clients that absolutely insist hovering over your programmers/designers, but it's much, much better than going into a project unarmed.