Gojko Adzic

Last month, I took a short break from my computer and went on a holiday. When I came back I was surprised to find that, while I was on the beach, Google sent quite a few people looking for underground Korean adult movies to my web log. I don’t know what is so special about the Korean illegal film industry, but considering that they also eat dogs there, it must be something very interesting to watch. I guess that you can find anything on Internet these days, but why were they looking for it on my web site? The answer to that question turned out to be another great example of why inputs should be sanitised no matter how unimportant. Continue Reading »

One of central agile programming ideas is to deliver frequently and get feedback early. To get the full benefits of this approach, it is not enough just to make sure that we deliver often and seek feedback — it is extremely important to plan our deliveries correctly as well. If the deliverables are not complete in the sense that they can really be used in production, then the feedback is not as relevant as we would like it to be.

Here is a situation I have seen a few times more than I would have wanted: the team and the clients split the whole project into several phases that will be shipped every few weeks; early deliverables mostly provide the plumbing for the later ones, and have only enough user-interfacing functions for the plumbing to be tested functionally. The clients set up and play with each new release. They dutifully give their feedback and participate in testing each time. When the whole thing comes together on the end, it turns out that the system still requires a lot of changes to solve the problem that it was intended for — the iterations and customer feedback failed to provide the directions. Continue Reading »

The print-on-demand service that I’ve chosen for my book has a fairly nice web user interface with lots of Ajax code. Generally, that web application is one of the best aspects of doing business with them. That’s why I was surprised to find a rather amateurish flaw in their shopping cart. Here is the screenshot:

Notice the “do not click Place Order more than once” message. Someone has obviously identified that customers have been clicking more times than needed, but offering a warning message is not the way to solve the issue. In fact, such a message is a huge warning signal that something is wrong.

I’m pointing out this case in particular because it is one of the most frequent problems I’ve seen in Ajax sites, and one so easy to avoid. The proper solution is incredibly simple: always disable the form as the first step of asynchronous processing. It is very easy to block the “Place Order” button before an Ajax call goes out to the server, and doing so would technically prevent anyone using a proper browser to place the same order twice. For high volume sites, like this one, I always recommend implementing some sort of double-order analytics on the server just in case, because exceptions do happen, but just a simple JavaScript command to disable that button would save everyone a lot of trouble.

In November, I attended a workshop on improving the understanding between customers and software development teams. The attendees were split into seven or eight groups, and there was an exercise at the end asking the members of each group to come up with a practice that could significantly improve the shared understanding with their customers. Five groups independently came to the same conclusion: “Spend some time working at the customer’s location.” Continue Reading »

| View | Upload your own

Kuniaki Igarashi posted a nice presentation on Omoiyari-Driven Development, with the core idea of programming while keeping in mind how other developers are going to use and understand your code. This practice aims to reduce misunderstandings among team members. I have a strong belief that communication and communication-related problems play a key role in software development, and although I would not consider being thoughtful of others as an idea that can lead development, I certainly agree with Kuniaki that it is a very important practice. I wrote several articles about related techniques, including Documentation for telepathic developers and The Poka-Yoke principle and how to write better software.

I am pointing to this presentation mostly because of the secondary “Bear programming” practice, which revolves around explaining the problem first to an imaginary team member (or in this case a real stuffed toy bear) before raising the flag and asking for more help. When a team member asks a question that clearly signals that he misunderstood the issue or the underlying infrastructure, I always try to lead that person into expressing the problem better or drawing it on paper. Very often that team member will reach a good conclusion himself - expressing it on paper or to another person just helps to clear the issue in his mind. This is, in my experience, much more effective than just giving an answer straight away. Bear programming speeds up the process a bit and includes a virtual person for people to talk to.

A stuffed toy is, however, no replacement for an experienced team member - and if agile development has thought us anything it is that there is no replacement for direct person-to-person communication. Asking for help is a good thing and I would not want to prevent people from doing that. But this can be a very useful practice to prevent junior team members from wandering off into the wilderness when they hit a problem. I would suggest using Bear programming, but with a different trigger - before starting to develop some utterly complex workaround, explain the problem to the bear. If that does not help, then raise the flag and call someone to assist you. Using the commander’s intent template can also help a lot to improve the shared understanding - so if you are often getting these problems ask yourself whether you can explain stuff better in the first place.