Five Rules for Taking Your Project From Idea to Deployment

How many side projects have you started and then quit? Software developers are always learning new technologies, trying out new things, and building their ideas. They also build teams, launch startups, and create paid products.

However, most developers I have talked to report an abysmal completion rate on

their projects. Many have 10 or more unfinished side projects, and most have participated in freelance projects that never saw the light of day.

Why is this problem so prevalent and what can you do to remedy it? Here are five rules I have formulated over nine years of experience that will help you guide your projects successfully from idea to deployment.

Performance over importance

There is a military paradigm called prioritize and execute. Perhaps it would be more accurate to call it prioritize, then execute. The essential takeaway is that there are two phases to any complex mission: first you make a list of priorities, then you execute one by one.

But, many development teams do prioritization all wrong.

Usually, it looks something like this: the project manager or product owner ranks the importance of each task, usually color-codes them, and then the team gets to work. For solo projects, developers often do this themselves. For client projects, the clients usually have their own ideas as to what’s important.

The problem is, you should not prioritize tasks strictly by importance. Instead, you should do tasks in the order that facilitates the best performance. Some examples:

If task A is more important than task B, but task B will make task A easier, do task B first.

If task A is rated as most important, but it is not precise enough, do other tasks until A is crystal-clear. Avoid rewriting code and spending more time in meetings than necessary.

If task A is rated as most important and requires 3 days to do, but you’re 2 hours away from the weekend, take a couple of smaller low-level tasks and complete them instead. Clearing the clutter in your task queue is always a useful exercise for team productivity.

Obviously, if the server is on fire, that’s priority #1. Some levels of urgency can’t be negotiated with. But, in most cases, you should not be a slave to importance ratings. Instead, do your work in the order that maximizes your output. This will help you keep your motivation high and keep the project on the right track.

Execution over elocution

Once you have your priorities straight, execute. So many programmers suffer from analysis paralysis that awareness of it should be included in every company’s training process. At the very least, team leaders should understand the immense drain on resources that overanalysis can present.

Once you’ve finished the prioritization phase for your current development period (whether that be a day, a week, or more), you have to trust your judgment and put all your energy into executing as effectively as possible.

Only when you reach the next phase or sprint is it time to take a step back and reprioritize.

Progress over ego

Human beings like going forward. Scratch that. We love going forward. If you’ve ever watched small kids play soccer, you can observe one thing: they won’t pass the ball back towards their defense to save their life. Our instinct tells us that forward is the winner’s direction, the aggressive option that yields results. But, if you watch trained adults play soccer, you will realize that passing backward is a powerful weapon that allows your team to change tactics and knock the opponent off balance.

A similar concept applies to business. Knowing when to change direction is a rare skill. It requires overcoming your ego and keeping the big picture in mind while completing your tasks.

Software developers hate backtracking (or, god forbid, scraping a whole feature they’ve been working on for a week). It’s only natural. We take ownership of our work and we are inclined to justify its existence against logic and common sense.

Truly great software developers have enough control of their ego to understand when the direction in the last development period was wrong. They also have the mental strength to tell this to their team and their client, then walk back to the branch that’s going in the right direction.

Feedback over vision

Visionaries get a lot of admiration. People love the romantic idea of the eccentric inventor sitting in a cluttered office, changing the world with their unique mind. To candlelight, if at all possible.

But, this is not the century of great polymaths. There is no Leibniz out there. This is the century of decentralization, constant feedback, and constant growth. For these very reasons, there will never again be a century of great polymaths. There is simply too much data.

As a software developer, it is tempting to dream up a vision of what you want to build in your mind, and then just do it. But, by doing this, you are throwing away the biggest advantage of building in our time: the ability to get live feedback from users every step of the way.

Make use of your audience to hone in on their problems and fix them. Implementing your vision is a shot in the dark; why would you take it when you could be aiming for a big, red target in broad daylight?

If you want to build your vision, there is nothing to stop you. I’ve built a few. But understand this: as great as your vision might be, if users disagree, you’ve got no-one to build it for.

Binoculars over scopes

This rule especially applies to lead developers and other leadership positions.

If a general has men in the trenches, he does not go down into the trenches with them. He is the strategist — his duty is to understand the big picture and plan big picture moves accordingly. Then he delegates down the ranks and trusts his troops to execute.

If you’re How a Single Freelancer Outperforms a Whole Teamworking solo, you must simultaneously be a general and a foot soldier. More precisely: you must step back to plan like a general, then descend into the trenches and complete the mission like a soldier.

This ties in with the principles above. Developers love getting down and dirty in the coding trenches. But without awareness of the big picture, how can you prioritize? How can you know if you’ve taken a wrong turn?

Conclusion

Everyone can get lost without a map.

Many projects get shelved because they run too long, the goals aren’t clearly defined, and the audience is non-existent. Developers lose focus and motivation because they never take a moment to step back, refine their goals, and reprioritize the tasks correctly.

Follow the rules above on your next project and see if they help you stay on course. They have The Evolution of My Productivity as a Freelancerhelped me tremendously over the years.