Are you managing developer time or just whistling Dixie?

Today's topic is managing developer time.   I know you are probably telling yourself:  But coding is an art and just like art it is free-form of expression that can't be limited by something strict like deadlines. This definitely applies to some of us, who are still living in our parent's basement and can't afford a tiny 24" ISP screen.  Unfortunately most great artists have suffered throughout their lives and have only been recognized long after their death.   They lived very poor and chose their art form over many of their basic needs.   In most cases development doesn't reach those levels, even though code can be as beautiful as sunset in Antarctica.

Show me the money

There are two types of development projects out there:

• Projects with soft deadlines/no deadlines: Open Source, Personal sites, some internal projects
• Projects with hard deadlines: software built for customers which costs money, both consulting projects and standalone products

Balance Act

When working on any project you are balancing three things:

                                    Soft Deadline                     Hard Deadline

- Cost                          Spend Free time                  Fixed

- Time                          Flexible                                Fixed

- Quality                       You choose                         Can vary. Depends on the other two.

If you take cost out of equation  you can really concentrate on Quality and Time.  There is definitely opportunity cost involved.  Developers working on soft deadline projects could be making money working on the client projects, but they get paid in something worth more then money.  Feeling good about contributing something to the world, having fun learning new technologies in personal time, improving internal processes that make work better for everyone.   These are all great things that are hard to measure.

On the other hand you have client projects.  Hard cold cash is the king.  In my company I like to send/receive payments in small purses of gold coins.   Well that only happened one time when we did that project for Vatican.  These guys are pretty old-fashioned.  Either way, how you receive payments is secondary.  The question is how do you balance Cost, Time and Quality and actually come out ahead at the end.

The answer is easy.  All you have to do is manage developer time.  THE END

If it would be that easy you would already do that... Right?   Unfortunately it is harder then feeding spinach to a two year old.  

What are developers made off

Here is the list of things developers like to do:

1. Code

2. See 1.

3. Watch Superhero movies

4. Talk shit on Reddit

5.

...

51. Eat Pizza

52. Talk shit on Reddit

53. Code

...

...

...

10002. Estimate tasks

10003. Write impl. details

10004. Update timesheet

10005. Go get something to eat, when you are really close to solving some issue, even though you have been really close for the last 16 hours and at this point you don't even remember what original problem was.

As you can see, the things related to managing Development time are very very far down the list.  As devs, we want to keep our Black Art to ourselves.  Otherwise if others in organization will find out what we really do all day, it will be very dangerous for everyone.  Let's go over each item we don't like to do.

The answer is 42

Estimating tasks

Who do you think I am Nostradamus.  I can't predict how long things will take or I wouldn't be losing all my money on Apple stock.  Let's make a deal.  I will just start coding and then we shall see.

How about not.  Yes estimating tasks is not an exact science, but with experience it is possible to get very good a it.  Estimates should not be set in stone, and may somewhat change as issues are discovered during writing of implementation details and actual implementation.  It is very important that PMs, Tech LEads and developers are clear on that.

Write Implementation Details

That seems like a huge waste of time.  I can just start coding and try several designs until I find the best one.  Then spend inordinate amount of time procrastinating back on forth on which approach is the best, while not actually going forward for weeks.  How about not.

I don't think anyone is stopping you from finding the best design.  All that's is asked is to spend some time thinking about problem up front.  Come up with preliminary design, do some proof of concept on small scale, talk to other developers about what you could be missing.  Yes it could be a waste of time, but in vast majority of cases it is not.  

Here are some interesting quotes about planning:

• Plans are of little importance, but planning is essential – Winston Churchill
• Plans are nothing; planning is everything. – Dwight D. Eisenhower
• No battle plan survives contact with the enemy. – Helmuth von Moltke the Elder
• A good plan, violently executed now, is better than a perfect plan next week. – George S. Patton

It seems like these guys are contradicting themselves in their quotes, but after you have worked on some projects without planning, which failed over and over, you can understand what these guys are talking about.  Your implementation details are living documents.  When you write your first draft, you have to be ready for change. Just like battle plans may change depending on how the bottle goes, your implementation details may not be the final approach you will take.

Here are some  things that come out of the process of writing impl. details:

• Another developer can review your design.
• If you can't clearly explain it on paper in a way that another person can understand, there is a good chance you need to think of a different approach.
• By writing impl. details you are getting a clear understanding of the overall design and business requirements
• Actual implementation is still an important task and your original plan may not go as planned, but you would be surprised how easy implementation becomes when you write down what you will do up front.

Update Elapsed Time for Estimated Tasks

This one is a doozy.  For almost all developers - the gene that makes them into good programmers usually comes paired up with a gene that makes them against updating elapsed time in timesheet.

It does not matter how simple Timesheet application is to use and that you only need like 5 mins to update your time for the day or two days,   developers will just agree with you that it is very important and not actually do it.

Some developers can be trained, while in other cases the only way to do it is by having PM or tech lead to seat down with developer and do it together.  Sooner or later there is a break through and they can do it on their own.

Conlusion

In conclusion to get development done on time, you need to make sure all tasks are estimated, implementation details are written and developers update elapsed time for the planned tasks.

"Sounds easy, no?  So why don't you just do it, Batman"
- Riddler