On time

 

Time is everything to a software developer. It bounds every aspect of his life. The time to come to work, the time of work and the time after work. But more to the point the time it takes to complete work – concentration – rest cycle, the number of times such a cycle can fit in a work day. The time lost talking to each other, eating, going to the bathroom, phoning, compiling, publishing, reading, searching waiting.

Most do not notice such a thing as time spent per activity, nor the time ill used or lost between meaningful work. Some do, and thus try to leverage it, learn it and thus they try to learn about them selves and their relation to the dimension of time

I’m such a person and I’ve learned a fair share of things in my time as a developer. I’ve learned that time is a feeling and that not all time can be meaningfully spent. That you are bound to have two to three work-concentration-rest cycles a day and that is that. I’ve learned that you can leverage the time between to better your self, watch a presentation or read an article during compile times or listen to podcasts on your way to work.

Such activities seem trivial when taken by them selves but focus on that, those five minutes spent listening to a talk on infoq are five minutes that you are wiser and potentially know more then before, albeit it was five minutes worth and if those minutes pile up during a month or a year how much time did you spent bettering your self instead of reading comic books, facebooks, twitters or other useless information's?

But other than that time is crucial for the activity of software development. The mastering of time by individual contributors which need to give estimates on their work and technical leads who need to coordinate the continuous integration of different modules in order to utilize the full potential of the team and incur no loss in output and productivity to product managers who need to be responsible for the deadline, or at least know what will be realistically produced by when.

When doing the work of a technical lead in charge of leading a team of developers time synchronization is of the up most importance. Imagine for a second a team of four developer plus out valiant imaginary leader. They are building a distributed system which will constructed of two main parts.

The first part is a a server component exposing some kind of fanciful services over the network. That server component is built with the goal of serving many clients build by potentially different organizations in different technologies.

The second part is a client application built to use the services exposed by the server component.

Our valiant leader thinks for a seconds and break the team in two parts. Two developers will work on the server component and two developers will work the client component.

By sheer luck the specification for the server interface is completed and hopefully will not change during development (one can hope at least). The client team is crack A-team of mixed UI design and Software development specialist, who know all there is about human machine interaction, how to draw fancy stuff and all there is about design patterns and software development.

Since they must build the client without the server component to test on they’ve leveraged their design pattern knowledge (with the help of our valiant and heroic technical leader) and they we pushed the server interaction code into their lower most layer and mocked up the input and outputs. Thus the super uber client is build. But alas the server component hit a glitch, it seems more people were needed so while the client is fully built but not tested on a real server the server component is build and tested only up to 30%.

Jeez what now?

Described above is problem of resource allocation and timing. What could be done different? Well a lot of things, the client work could have been started later or the team should not be broken into two separate sections instead each developer or pair could have been given a cross section of client and server functionality thus the client and server parts would be build, tested and rolled at the same time.

In end time is the king that marks each cycle in the life of a software developer. Knowing its rules and limits, its ebbs and cycles it is crucial for a developer to be successful in her career.