Agile Software Development

Many Finnish companies have a tradition of periodically selling the old stuff to its employees on the internal auctions. If you are lucky, you can get a decent computer, printer or fax for a couple of euros. Several years ago the company I was working for (CIM Wireless) has been bought by a bigger one. We were going to move to the new company premises and therefore had a particularly big auction where they were selling pretty much everything older, than a year. At that time I needed a new kettle and got one right from the company kitchen for as little as five or ten euros. I didn't put much thinking in, I just needed a new kettle - it didn't really matter which one.

When quality matters

It happened, however, that such a commodity as an electric kettle could be of so high quality that it makes you notice it. We didn't examine the device or measure its performance, but we couldn't miss such features as boiling water fast or ability to turn off automatically, when was empty. It might sound amazing, but we were actually surprised by the fact that it just worked very well. Plus it looked nice. We even recommended this model to a couple of friends - something you rarely do about kettles.

Quality used to be perceived as one angle of the time-cost-quality project triangle. Unfortunately quality isn't as manageable as cost and time. If the funding is cut it is often possible to release a working product with the smaller set of features. It time is limited it is sometimes possible to hire the best specialists to implement all the features faster. It might sound like dropping some quality standards could be a way to releasing the product earlier.

Some teams using Scrum and XP tend to have special Q&A iterations every several iterations and/or before the release. While it might be ok, during the transition to the agile processes, as a rule of thumb having Q&A sprints is a good indication of the problems with the definition of "done". The main point of iterative development is to have a "potentially shippable" product at the end of iteration. Planning for Q&A sprints essentially means that at the end of the iteration, team does not plan to have a potentially shippable product.

We are not rich enough to buy cheap stuff.
- Russian proverb

Did you know, that the products with the lowest defect rates have the shortest schedules?

The statistical research on about 4000 software project mathematically proves that savings on the QA, throwing away the code reviews and unit testing is the worst decision a manager could make in order to speed up the progress. The cuts in the testing will undoubtedly bite the project back.

I can recall several cases, when a seemingly clean'n'simple class appeared to be a huge and difficult to debug entity with loads of underlying asynchronous logic. The simple and small public interface hides the implementation details and according to the good Object-Oriented style all the underlying details are private. Or is it a good style to hide the implementation details into many private methods?

As it often happens, the problem comes from a good idea overused to the extent, where it inhibits another good idea. The encapsulation makes it easy to use your classes or systems externally, but it should not make you forget the internal structure of the class. As Michael Feathers tells

It often means that there's some other abstraction hidden away inside the class that might be useful to pull out.

The program optimization is performed in order to reduce the execution time, memory usage, bandwidth or some other resource. Optimization essentially means sacrificing the clear, simple and understandable code architecture. As a result the level of complexity increases, debugging and restructuring becomes more time-consuming and more expensive.

It is simply a lot cheaper to get a clear working and testing code before the start of the optimization. As a side effect, a set of unit tests (if you practice them) will protect you from the potential regression coming from the optimization actions.

Managers don't speak C++, refactoring and some of them don't trust the programmer's "feelings". To sell TDD to them, we have to speak the management language of costs, deadlines and delivery delays. Apply some management language and you'll be able to start the TDD.

Killer argument tips:
1) Extra testing saves at least some time of the final test round
2) Extra testing improves the code quality at least a bit
3) If extra testing is applied to the most important components and interactions, it takes not that scary amount of time
Therefore even in the worst case the time spent on the extra testing will be partially compensated with the better quality and smaller final testing efforts. And in the best case, both quality and delivery time will be improved significantly.

I don't care how good you think your design is. If I can't walk in and write a test for an arbitrary method of yours in five minutes its not as good as you think it is, and whether you know it or not, you're paying a price for it. (Michael Feathers)

If you practice a lot of unit testing, test-driven-development of whatever method that includes a lot of testing, you have to spend a lot of time on it. And most of time you have to do the testing-related work before the problem happens and before anyone is affected. Certainly it is good to capture the bug early, before it hurts anybody, but the need to do the "extra" work in advice introduces the temptation to "just tweak this small feature and test it if the problem arises later".

Peer code reviews are known friends of a good code quality. Many of the agile methods strongly recommend them. XP as usual goes to the extreme point and offers the pair programming practice, when the reviews are performed continuously.

The usual problem with the code reviews (unless you practice the pair programming) is that they are often performed after writing a big block of code and reviewers can concentrate on the micro level issues like coding conventions and style. It is important to enforce the common conventions, but it would be great to pay bigger attention to the code logic.

Toyota is one of the industry leaders known both for its quality and revenues. It's quality system was being built for decades and quite often the quality of the cars was by an order of magnitude better, than what, say, it's US competitors had to offer.

There are few simple principles behind the Toyota quality system. Here are two of them:

• Built-in-quality
  Quality is not something that is added at the end of the production line. Every major robot that works on the car parts has sensors and intelligence to recognize defects early and either fix them or remove the detail from the line.
• Toyota's five why's