How To Screw Up A Software Project By Thrashing Late

Over the last 10 years I’ve worked for dozens of clients, building dozens of professional software projects: iOS apps, Android apps, web apps and websites. Most projects went without a hitch, but other projects went downright disastrous.

I’ve learned from successes, but I’ve learned much more from mistakes. What’s interesting is that a project-gone-bad isn’t typically caused by one big mistake, but by lots of small mistakes over a longer period of time. It’s not one bug that spells disaster, but neglecting quality control since the beginning of a project.

In this article, I’d like to walk you through 3 of these slow project killers. The idea is not to help you avoid mistakes, but to help you see them in advance and respond appropriately. Mistakes are part of work, but it would be great if we could take the sting out of them!

The advice in this article is suitable for both freelance developers and employed developers, for both solo devs and those working in teams, and these mistakes don’t limit themselves to just mobile app development. These mistakes are everywhere!

Not Guarding Project Scope

You’ve started an iOS development project for a client, and you’re 3 months in. At one point the client calls you up and says: “Look, I really like that button on screen B, but can you move that to screen A?” You say: “No problemo!”, and your project scope goes down the drain…

Project scope is like watching your project through binoculars. Some tasks are in scope, and others are outside the scope. And as a project progresses, your client or boss has more insights about the project.

Maybe they have second thoughts about a feature, or heard about a new technology that you absolutely must use in their app. Most clients also feel ownership over a project, even when you’ve taken it out of their hands, and as a result want to “steer” the project according to their own wishes.

At this point you might ask yourself: “Is that a problem?” So, let’s look at what happens with projects that go out of scope:

Software development projects aren’t so forgiving when it comes to moving components. You can’t just put the engine in the back, when you designed it to go in the front. And you can’t decide to rotate your new kitchen 90 degrees halfway through remodeling.

Changes cost time and money. Extra time that’s unpaid comes out of your own pocket if you’re freelance. And if you’re employed, you might cheat your employer out of charging extra for more work. On top of that, more work puts more stress on your deadlines. At worst, you might miss the deadline.

OK, let’s play devil’s advocate here. Let’s say you’re a nice developer and you agree to do some extra work that’s out-of-scope. It doesn’t take that much time anyway – maybe 1 or 2 hours. Sounds reasonable, right?

You implement the extra feature, but at the end of the project you discover that you’ve made a mistake. The extra work you did isn’t compatible with some other feature that was already agreed on. Instead of 1 or 2 hours, you now have to spend 2 days rewriting the code!

So, how do you avoid going out-of-scope? Here’s how:

Explain to your clients and/or employer that making changes after the design has been agreed upon cannot be done. It will delay the project and cause extra costs for the parties involved.

Tell your client you wish to be flexible, so requested changes will always be considered but often can’t be honored. Help your client or team to spend extra time designing the project, to avoid needing to change things later on.

When you’re charging for your projects, i.e. if you’re freelance or helping your boss make a quote, always work with a 10%-30% margin. This margin helps you buffer against mistakes, changes, and unforseen events. And if you’ve got room in the budget, you can delight your client with a “free” extra feature.

Let’s move on to thrashing!

Become a professionaliOS developer

Get started with iOS 13 and Swift 5

Sign up for my iOS development course to learn iOS development with Swift 5, and start your professional iOS career.

Thrashing Throughout The Project

In the previous section we’ve already discussed what happens when a project goes out-of-scope, and how you can avoid it. Thrashing is a related phenomenon, but the problem is that you can’t always avoid it.

Thrashing is changing things on a project. And thrashing late is downright disastrous for a project. You want to avoid thrashing late at all costs.

Seth Godin tells a story about how they dealt with thrashing in a game development project. Here’s the gist of it:

The game project that the company developed had a hard deadline. If they missed the deadline, the project would go bust 100%.

Everybody on the team was given a red or green sticker.

If you wore a red sticker, you were on the critical path towards the deadline. If you didn’t or couldn’t do your work, the deadline would be missed.

If you wore a green sticker, your job was to help the people with a red sticker to do their work (or get out of their way).

The goal was of course to reduce the amount of red stickers, i.e. reduce the critical path, so the project would clear the deadline.

When you’re a developer working on a project, you’re on the critical path. So, when a client or co-worker or boss comes to you and wants to increase your workload on this critical path, they’re surely jeopardizing the deadline of the project.

Unfortunately, thrashing just happens. Developers and their teams are creative people, and many software projects are creative endeavours. You meet with co-workers and bosses, and new ideas form, and suddenly you have an idea that must make it into the project.

The solution here is to thrash early. Here’s how you do that:

Spend enough time at the start of a project to discuss, design and listen. Help your client or your company’s client to see what the project is going to look like, and engage them in the process.

Be very clear about the no thrashing late rule. Thrashing late is the same as sabotaging a project. This must be communicated early on, so you can help manage expectations of clients and bosses.

A good manager helps developers do their best work. If you have a manager who hassles you to put in an extra feature, make it very clear that they are delaying the project.

You’ll hopefully recognize that every one of the disasters in this article has something to do with communication and managing expectations. Inadequate communication weaves like a red thread (or tape) throughout screwed up software projects. Communicating clearly and timely is an asset to any project, and an invaluable skill for any software developer.

Not Creating Technical Designs And Documentation

A technical design forms the basis of a successful software development project. Documenting your code, and technical decision you made, is part of that design process.

Describing what’s needed from your client, stakeholders, and teams at what point (such as graphics, data entry, accounts, licenses, etc.)

Setting up a project planning, milestones, and deliverables

Writing code comments, i.e. for functions, classes, properties, components, and especially at points where some additional explanations about your code are needed

Investigating and deciding on what technical architecture and design patterns to use

You wouldn’t build a house without a detailed, measured blueprint, would you? You can’t just move a support wall after discovering that the plumbing prevents you from building it where you wanted to. The same goes for software projects: you need to think before acting.

I doubt that any developer will ever start work without doing some design, but what’s often needed is asking yourself if the designs are sufficient.

You can use proper functional-technical design as the foundation of a project, something that you can go back to when decisions need to be made. Design and documentation can serve as discussion points for communication with clients and your team. And when changes are required, you can consult your designs first before hacking the project.

One of the benefits of a crystal clear functional-technical design is that the client, or your boss, can sign off on it. They understand exactly what they’re going to get when the project is finished. This means they can thrash however they want during the design phase, but not after. In my experience, this gives stakeholders the ownership over the project that they seek, without risking resource intensive changes later on.

Writing documentation isn’t the most sexy part of software development. Designing software is interesting though, and a developer who can take on a project’s design, architecture and planning is often valued better than a developer who merely codes.

Become a professionaliOS developer

Get started with iOS 13 and Swift 5

Sign up for my iOS development course to learn iOS development with Swift 5, and start your professional iOS career.

Browse Topics

Swift Sandbox

Reinder de Vries

Reinder de Vries is a professional iOS developer. He teaches app developers how to build their own apps at LearnAppMaking.com. Since 2009 he has developed a few dozen apps for iOS, worked for global brands and lead development at several startups. When he’s not coding, he enjoys strong espresso and traveling.