Programming is not mindlessly implementing specs nor is it determining the best big-O algorithm for a mathematical problem. Programming is art; turning raw code into an implementation of your ideas. Programming is what you do.

Software Engineering is what your company does. Software Engineering figures out the most efficient and profitable way to develop a product. Software engineering is as much about people, process, and schedules as it is about data structures and protocols.

Here’s the scene: you’ve just gotten a great idea on some new feature, and you’re discussing it with your [software engineering] manager. He’s¹ enthusiastic, and then, like clockwork, the question comes:

“So, how long will it take to implement?”

The answer is two weeks.

From his perspective, three weeks will mean it is a large task with many variables, likely to take four. Telling him four weeks will make him question whether the project is worthwhile as there are other tasks you are needed to do. Five weeks will signal that you are incompetent. Bringing up the M-word (that’s “months”) will be a sure-fire way to lose his support.

If the feature is doable with one week’s hard work, you should still say two weeks. One week will set you up for coming in late — there may just be those variables you didn’t anticipate, or there could be another issue that comes up and sidetracks you. The extra padding can also give you time to refine your design as it develops and make a better demo. If you are able to finish in less than two weeks, you’ll look that much better.

Don’t worry, two weeks will work. Programming is art, and you’ve already got the picture in your head. A tight schedule will force you to improve your engineering by making the necessary tradeoffs without falling into a perfectionist trap. If you work really hard and stop checking facebook, you can work 12 hours a day for the next 14 days. This will give you 168 hours or the equivalent of a little more than 4 real weeks; plenty of time. Remember, you don’t need to deliver 100% of the feature in this period of time, only the easiest 80%. If the feature turns out great, you’ll have time to later refine.

Two weeks is also the average period between meeting times, so it is unlikely you’ll need to give an impromptu and risky demo. At this next meeting, you can impress your manager with the end result; it always looks good to show something. If the feature gets nixed, you will not feel that you have wasted a significant chunk of your life.

If other tasks on your plate will prevent you from immediately starting on your feature, you should not add this into the time estimate as the mentioned negatives will apply. Instead, split it up: “I can get started in two weeks, and it will take another two weeks after that.”

There are two main scenarios where you do not want to commit to two weeks:
1. A small project which should be measured in hours.
2. A large project which should use two weeks as milestone markers.

To wrap up, please observe this discussion between an engineer and his manager:

Kirk: Scotty How long will it take you to have everything automated?
Scotty: Oh, six weeks Captain, but yah don’t have six weeks so I’ll do it in two.
Kirk: Mr. Scott have you always multiplied your repair estimates by a factor of three?
Scott: Of Course Captain, how else would I keep my reputation as a Miracle Worker?

🙂

[1] Replace he/his with she/her if your manager is a woman.