mobcode

Kick the conversation

Sometimes two people are talking and a message gets lost. Both people end up waiting for the other person. The protocol is stuck.

This can happen when an email is lost, or gets missed in a sea of email. This is a particular problem on RentACoder. The two level message confirmation process causes messages to not be sent.

When you are working on a project and have not heard a response as expected then go ahead and send another message to the other person. You need to kick the conversation to get it going again.

It’s not about you

This is a hard lesson to learn. I am sure there is some exception. Everyone thinks they are an exception.

We focus on ourselves and our work. We think that is the focus of the entire project. The world for that matter. It is not. It is not all about:

• Your tasks and how to do them effectively.
• Your time and how to optimize it.
• Your problems and how to understand them.
• You.

Those things are important for you, but they should not be elevated as if they are most important thing for others. You should absorb the costs of arranging your own work. You should accept the limits on the optimizations you can perform within your world. You absorb and accept in an effort to fit better into the overall project. To serve the ultimate goal of the project.

When you do that, you become valuable to the project.

I am not suggesting that you abandon your own agenda. I believe that successful business means finding a way for individuals to pursue their self interests in a way that satsifies the organization’s goals.

You will be more valuable if you are aware of the overall goals. Be aware of where they conflict with your self interests. Decide where you are willing to compromise. If you have a personal goal that is not of any interest to the project, then be careful about promoting it to others as if it were above the project goals.

Craft a patch

I have seen two ways of submitting code changes to a project.

Check in whatever code you have laying around. You hacked on the code for a while. Made some exploratory changes to see how the code works. Added a few debugging print statements (with “*****” so they would stand out). Left a history of many attempted lines of code that are now commented out. Randomly reformatted various parts of the code. Made other changes along the way that you cannot remember. So now you are ready to check-in. You quickly merge all of your changes with the latest code (just click accept changes, if the tool can merge it then it probably can be merged safely). Submit your changes to be applied to the repository.

Ugh! What a mess.

Craft a patch. You did all of your exploratory work in a separate code branch that is not part of the patch. You are familiar with every line of code that is changed by the patch. You have reviewed it several times. Other developers have reviewed it as well. You have possibly made the changes multiple times as you merge (or re-apply your changes) to the latest code. You know what you are doing. You have a finely honed and specific set of changes. The patch is well crafted.

Winner’s curse: reprieve

Winning a fixed-bid project on RentACoder can be a curse. Winning may mean that you were the dumbest bidder, the one who most under-estimated the work to be done.

There is a clause in the RentACoder agreement that provides a 24 hour grace period for coders. During this time you can cancel your bid if you have a legitimate reason you cannot do the project (read the agreement for details).

If you win a project and then review the specification in detail and realize there is no way it will be a successful project for you then consider this grace clause. The project sponsor will be quite unhappy. If you do it multiple times I would expect RentACoder to revoke this privilege.

But, I have seen projects where developers know immediately the bid was a mistake and they try to work through the project anyway. This does not have good results for either the coder or the sponsor. The grace clause is a way to end the pain quickly.

Fixed-bid attitudes

When bidding on fixed-bid projects on RentACoder developers really want the project. So they are enthusiastic and responsive as the bidding takes place.

That attitude dissapears as soon as the project is awarded. The pre-bid promises are gone. The developer themself seems gone. They don’t respond quickly to email. They don’t do what they say they will. They pay no attention to project deadlines.

It seems to me that if you are going to end up doing the work, you might as well do it promptly and with some enthusiasm. I suspect it takes the same number of hours. The only difference is, it will make the sponsor happy.

Automated GUI testing

Testing GUIs is hard. Recently I had two graphics libraries built. We built an automated test harness for each. View the results.

Here are links to the two sites shown in the video:

• Edward Tufte’s sparklines
• Joe Gregorio’s sparkline generator

Agile happened

The agile movement has happened. In case you missed it. If you don’t know what it was all about then you need to at least learn something about:

• Incremental delivery - learn to deliver functionality as a thin, end-to-end thread. Then keep adding small features to that thread until you have a full, rich, robust implementation.
• Unit tests - test driven development dramatatically changes the process and the results of development. If you have missed this, then be very careful about dismissing it out of hand.

As you talk to project sponsors and project leaders there is a good chance that these practices are deeply rooted in their approach. They are not some new, novel technique to be debated. They are just a given.

Finish clean

It is important to bring a fixed-bid project to a decisive finish. The danger is that in the course of the project, the sponsor will discover what they really want. The problem is that you built what they asked for at the beginning. You have a couple of options. One option is to make the changes they want. However, this is not typically a viable option. The second option is to stay on the original charter, get the project delivered and create the opportunity for a second project.

As a developer you can start to send signals as you are finishing the project that you are in fact finishing. There is a balance to be struck. You don’t want it to appear that you are forcing the project to end too quickly, but you do want to let the sponsor know that you are preparing to declare the project finished. That is what both parties really want. They want the project to be delivered successfully and to be finished.

You can signal your intentions to the sponsor by referring to the “final” milestone, or the “last” requirements to be implemented. Of course your efforts are greatly bolstered if you have actually done everything in the original spec. However, avoid sounding too aggressive about it. Asking for “sign-off” on the current list of fixes is sure to alarm the sponsor.

It is also important to stay responsive at the end of the project. Responding quickly to email messages at the end, will help the project finish quickly. Avoid the temptation to spend your time on new projects and let the old projects languish.

A clear way to monitor whether you are converging on a conclusion is to pay attention to whether the list of oustanding work is getting shorter. If each new milestone delivered creates a larger list of things to do, then you are in trouble.

Study the masters

Find some of the masters and study their work in detail. Candidates include:

• Gerald Weinberg offers deep insight into people and how they function.
• Lisp videos make elegant programming look deceptively easy.
• Donald Knuth is a humbling testament to what can be done by a talented, driven person.
• Edward Tufte applies years of quality thinking and makes the case for quality thinking to be represented in graphics.
• Alan Kay was one of the guys creating (as in for the first time!) OO and GUIs. Now look where he is heading with Croquet.
• Paul Graham will totally change how you think about programming.

Beautiful and ugly languages

Stretch your mind by learning some new languages. Learn some languages that are too beautiful to make it into our mainstream world, like Lisp and Smalltalk. Then, once your mind is sufficiently stretched learn some languages that are ugly enough to survive in our world like Ruby and Python.

You will learn amazing ideas from the beautiful languages. Then, you will learn how to use those ideas in real life from the ugly languages.