Arkisto: September 2009



Bugs and fu…frustration

24. Septemberta, 2009 | Kirjoittaja: Antti Niittyviita

Companies are co-operating more and more. Making a customized tool is a good example. Because code is generated during the development process, there will also be bugs.

Depending on the user perspective, software bugs can be roughly split into two categories. The ones that entirely disable using the product, and those that make it harder to use it. The bugs that disable the product should be culled during the development process. What should be done to the tiny bugs that do not cause worse damage than user frustration?

I went and conducted a small survey among the software business pros.

The most frustrating bugs are the ones that come as a surprise. The existence of bugs that are known beforehand does not matter too much, unless their presence hinders using the product unreasonably.

Ultimately, the results from the small survey are quite logical. Unpredictability and not knowing the behavior of the software cause constant headaches. Furthermore, people who use the software for a living are very eager to complain and inform the supplier about defects. “Why the fuck couldn’t they even catch this bug when they were still testing it?!” This increases the workload for the supplier’s support team.

What if you could kill three birds with one stone?

One needs to forget traditional thought processes and rigid ‘business secrets’. Should we not play with more open hands instead of secrecy? Would it be far too unreasonable a notion to open the bug database for the end users?

There are three clear benefits for opening it:

1. The threshold of frustration for the end users rises, when the bug is known. Especially should there be a handy work-around for avoiding the bug. A known issue does not cause unnecessary frustration.

2. Trust in the supplier’s quality assurance increases. Every professional in the software business understands that there will always be bugs in the software. It is better when the supplier has discovered them before the end user.

3. The number of duplicate complaints goes down. And when a new issue is discovered through complaints, one should immediately inform about them on the user forum. This lessens the workload of the support team. If opening the bug database proves to be too difficult, technically or mentally, you should at the very least do a good listing of known issues and publish it.

Why could you now open the bug database to your customers? If the co-operation works well and openly, I cannot come up with one reason not to.

Trendy wordmongering

4. Septemberta, 2009 | Kirjoittaja: Antti Niittyviita

Software development must be made trendy no matter the cost. One has to choose fashionable terms to portray the modes of action of development and the processes that have been agreed upon beforehand.

People are agile developers and use the newest web 2.0, or even 3.0 (?) tools, but how does it end up in reality? Let us take a look at this from the perspective of an ordinary software developer, or perhaps through the eyes of a tester.

Agile is about communication. Honed to its best, efficient and productive.

Problems are not discussed through long e-mail threads, telecommunications meetings or validation processes. They are meant to be able to be solved on the spot, by co-operating to solve the problem, not to document it. How do people in your project act, when a tester discovers a problem?

Typically, the defects or errors are first documented into the error control system and the error manager is informed about it – if people remember to. Documentation is made manually and it takes time. Tests stand at a halt and performance pressure accumulates. Reporting is easily forgotten or it gets left at a stage where all the designated tests are first run. People need to be productive, supposedly agile.

When the defect is finally reported, the error manager assigns the developer to figure it out. The developer starts to wonder about the whole thing at a stage, when he remembers to check the ‘defect notifications’ folder in his e-mail. If the defect has been put in manually into the error database, the report is usually partially lacking or without an explanation. It might lack the essential log-files or the steps needed to reproduce the defect situation. The fix ends up forgotten, when the developer does not bother to rediscover the original error. Is this actually agile, even though there are assurances that it is?

Why not handle the defect genuinely in an agile manner? Report the defect through the communication channel that is most likely to matter. On broadband. If one thinks of communication channels in terms of speed from the modem to the 100M broadband, one could just as well measure agility or communication on the same scale.

Thorough documentation of defects and informing about them via an e-mail according to the process is usually slow. Let’s assign this mode of action the bandwidth of 56.6 kbps. One could also report the defect directly to the developer.

By tugging on the developer’s sleeve and showing the steps on how the defect happens and how it crashes the software, the bandwidth of this communication is then at a peak: 100Mbps.

There are admittedly more basic ways. One could, for example, phone the developer (512kbps) or IM him (384kbps).

If collectively agreed upon mode of action requires documentation and a process, it would be very well possible to choose the primarily fastest connection. After the message gets through, it can be verified with some slower alternate when there is time. Or even better: If the organization is actually adaptive and agile, find and use tools and accessories that enable to automatically verify it.

When you are choosing a broadband to fit your home with, would it not be prudent to choose the fastest one… especially if it is also the most profitable one? In software development, this is how it goes.

The fastest solution is also the least expensive, the most profitable and in fact, the most agile solution.