The Easiest Way To Lose Job As A Programmer (+5 TIPS)

Let's imagine, you are the best software developer in your team, but there's one thing you can't handle.

It is project estimation.

When you do software development one day your manager will come to you, show some papers and say "Hey, please estimate this piece of software".

Wanna lose a job? Try to do proper estimation and don't underestimate.

At the beginning of NS Code's journey, I tried to do fixed-price estimations with my team. I found it very hard because when I showed the same technical documentation to 2 developers this is what I've got in response:

Both developers had the same experience in the technology they wanted to use. Both of them had overall experience in software development. The difference between the two estimations was 16 hours. Billed at 50 USD / hour it means 800 USD difference in a very small project.

There are several options right now:

• Developer #1 underestimates, so the client pays less for the actual work done. It can lead to an argument between the developer and his boss.
• Developer #2 overestimates, so the client pays more than actual work is done, so it can lead to an argument between company and client.
• Developer #1 or #2 estimates correctly, so both company and client are happy.

Can you see where am I heading to? Fixed-price estimates can lead to several misunderstandings between clients and your company. When we are developer #1 and do estimation, but real estimation is close to #2 it can lead to creating our new resume.

Please, go Time & Material

It's just easier to make sure you won't piss your client off. The client pays for actual work done. Not more, not less. Prepare a rough estimation of how many hours you will spend on the project - either way, the client has to know what would be the price of the product.

Keep your client in a communication loop. Let them know every day what are you working on. They need to be sure what is going on, what goes well, and where are the problems which could lead to postponing deadlines.

If your client is worried about how the hours are billed - try to use some tools like Hubstaff / Toggl.

If the fixed price for sure - create good technical documentation.

Great technical documentation is something that is rarely found nowadays. Close deadlines, pressure from business / clients / market - there are just a few reasons of bad technical documentation.

Convince your client that both sides need to know what is the real scope of the project. Try doing wireframes, maybe some kind of presentations and make sure that you, and your client are on the same page.

Talk with business / client

When you are a developer and you do not directly communicate with end-users / your company's client, try to schedule a meeting. Either with someone from your company or directly with your client. Have a talk, prepare questions, and make sure you ask about everything that you are unsure of.

When I was a developer and not a manager - I often didn't really know what the feature really had to do or what it was about. A quick talk can save you hours of developing a feature when you are sure what it has to do.

Make sure that necessary features are really necessary

Indeed it can be tricky. When you can talk to your client you should ask them if some of the features are really necessary for an app.

For example - when the product is in MVP phase, maybe you don't need social sign-in? Maybe you can use out-of-the-box solutions for mobile app (e.g. Firebase) instead of writing your own backend?

Split project into milestones

Splitting the project into milestones can help you and your client make sure that everything is going in the right direction. Prepare milestones (but real milestones, not something like "the beginning" and "the end" 😉), and react to what will happen next.

During the development of a project a lot of unexpected situations can occur, so be ready to keep going and fix some bugs.

Summary

Project estimation is hard. Period. You can't always think about every possible scenario and every aspect of the app. When I can recommend you something - go for time & material project funding, and keep your client in a communication loop. When it comes to product development - a piece of bad news is better than no news.