mobcode

Open tab

Some developers appear to be looking for an open tab that they can charge all of their time to. So once they are “on” a project then by default all available time is charged to it. Only if they are very explicitly not working on the project do they decide to not charge the project.

Other developers appear to implement an opposite algorithm. By default they do not charge the project. Only when they are explicitly working on the project do they charge it.

As it turns out, you will deliver more value if you are the second type.

Illiterate apps

Why do we keep writing apps that can’t read? Sure they know sign-language; they can understand our gestures. But why can’t we write down instructions for them? Reading is so much more powerful.

Rather than locking functionality behind a GUI, instead expose it as scriptable functions. Then a GUI can be built on top of the functions. Or, with a scriptable base, we can choose to write instructions for the computer to read. Then we don’t have to sit there and make gestures at it repeatedly to get it to do the same thing over-and-over. You know we could make the computer… programmable.

Twenty questions

Have you ever asked someone a question and instead of getting an answer you get an endless series of questions?

For example:

Q: How much does a computer cost? A: What brand do you want? How much memory? A supercomputer or an embedded controller? What size of hard drive? What style of keyboard do you like?…

Wouldn’t this be nice:

Q: How much does a computer cost? A: Well if you just want a basic desktop system you will spend between $x and $y. Can you tell me more about what you need it for?

Notice the second person:

• Made some reasonable assumptions
• Provided a range of answers to accomodate the range of possibilities
• Spoke in terms the listener was interested in (their money, their needs) rather than technical details
• Showed a willingness to change the answer based on more detailed requirements

The first person caused the conversation to grind to a halt in the minutiae. The second person progressed the conversation by providing an answer. That answer could be the end of the discussion. Or it could be the starting point for the next phase of the conversation.

Apply this to development work. When you have a task to do, avoid the temptation to “deliver” a set of 20 questions to the sponsor. Often the developer who asks the questions considers their work done. They don’t think they own the task anymore because they are waiting for answers to their questions. This is fatal.

Instead make some reasonable assumptions. Maybe even make two sets of assumptions and provide both alternatives. Deliver something. And leave the “conversation” open so that the work can be steered as the requirements are refined.

When will it be done?

If you are working on something and you are asked “when will it be done?” then you have already failed. You should have avoided this question by doing one of these:

• Delivering it
• Delivering part of it
• Delivering an estimate of when it will be done
• Delivering reqular status updates that make it clear how the work is progressing

NOTE: If you need to answer the question, the answer is not “today!”.

NOTE: The answer is not “tomorrow” either.

Work in progress

“Work in progress” is work that is begun but not finished. It goes by many names. It is called “almost done”, “90% done”, “basically done”, etc. All of these mean “NOT done”.

“Work in progress” is a pain for a project. Being done is where the action is.

It is better to have one item done than to have several items in progress.

Drive

Some developers have “drive”. They are driven to deliver. Given a list of tasks to do they will jump in and grab some and do them. They find creative ways to overcome any obstacle in front of them.

Others will spend time admiring the list of work, talking about the work, documenting why they can’t do the work, and finding other ways to not deliver.

You want to be in the first category.

Time drain

Another form of negative delivery is to be a “time drain”. That is, you are a sink that consumes time from the project sponsor and other team members. This may take the form of:

• Endless questions
• Disputing the project procedures
• Advocating particular features that the project does not want
• Submitting low quality code that requires much work from others
• Failing to learn new technology and tools on your own

It is acceptable to ask questions. It is good to ask questions. As long as the asking of questions gets you to the point where you can deliver. If they do not, then you become a time drain. And that “drain” is a part of what you deliver to the project.

Delivering work

Sometimes you deliver negative value. Consider if your submission generates extra work for the project sponsor. For example, does it include:

• code that does not merge cleanly with the main code
• a set of manual procedures that must be followed as part of incorporating the change
• a jumble of several unrelated features that are hard to untangle and understand in isolation
• incomplete work that requires the sponsor to finish some details
• disregard for normal code submission guidelines that require the committer to understand the special way you are submitting your code

Typically there are several contributors offering code to a project. Each contributor wants their changes to be accepted. The more work that your changes generate the lower the chances they will be accepted.

XML as a virus

I have seen XML as a virus that spreads through the codebase. It contaminates the code. It steals developer cycles.

Consider this: we had a feature we needed in the application. Store a small config file with some user preferences. Read it on startup and if the user changes their preferences then save them to the file. Simple, right? We proposed a simple flat file syntax to store the configuration in.

However, the developer proposed storing the file in XML. They proposed this repeatedely and forecefully. We had not asked for XML, but the developer seemed unable to proceed if it was not XML. So we gave in: “fine store it in XML”. The big reason was the developer did not want to have to write a custom parser. Ok… so be it.

The next thing we know we were being asked all sorts of XML questions. Where do we want to store our DTD? What tag names should be used in the XML? Answer: “I don’t care”. I don’t even want to talk about such things.

Then we get the code. It turns out the XMLness has crept into practically the entire code base. All up and down the call stack there are methods and comments and parameters referring to XML. What’s this? And then at the core. The most complex part of the entire solution is a complicated “custom parser” that translates XML events and text values into application objects. How is that better than writing a parser that reads character events and translates them into objects?

So the XML ended up invading the entire solution. Like a virus. We had asked for a feature we ended up with a pile of XMLness. Moral: give your customer the features they ask for rather than the technology you are consumed with.

NOTE: In the end we were able to purge the XMLness from all the code except a single class that uses XStream to serialize our objects to XML.

Clear email

There are ways to increase the clarity of the email you send.

Correct Subject

Ensure the subject of the email matches what you are saying. Often email threads diverge from their original topic. When this happens, update the email subject.

Brief Quotes

Be selective in what past parts of the email thread you include in your email. Delete all of the past material except a specific sentence or two that you are responding to.

Format Quotes Well

Place the past email text you are quoting before your comments. Format them in a standard way. Don’t make up a new “standard” way of formatting them.

Format Well

When you have finished composing an email, look at it. It should be composed well. It should look like it is formatted correctly. It should not be a jumble of text from different people and indented randomly. It should look good.

Some email clients make it hard to format email well. That is your problem to fix. Either fight the tool or get a different one. It is your responsibility to deliver clear email.

Signatures

Do not include large signature files in your emails. This becomes pure noise when communicating with the same team members every day.

Be Brief (or Summarize)

You have spent much time with a topic and have much to say about it. Others do not have much time to spend reading your email. Be brief. If you can’t be brief, then at least provide a summary at the beginning of your message. The summary should be a a few sentences. If you can’t be brief perhaps you need to write it somewhere other than an email.  Finally, don’t just provide facts, provide your analysis.