Selling Test-Driven Development to your boss

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.

How do these arguments sound to you? Did you succeed in translating the programmers’ issues into the management language?

Testability as the design metric

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”.

One of the usual consequences of this kind of approach is a set of hardly testable classes. Just because they use a lot of direct dependencies, instantiate concrete classes instead of using generic interfaces, etc. Programmers can use the best patterns available, document the implementation very well and still the heavily dependent code would be difficult to maintain and update. One of the reasons is that unless the class is separable (to be put into the test-tube), it is complex to examine what exactly consequence the new changes have. Another reason is that since the Stone Age people learn best from the examples. It is much easier to understand the class logics if you can scrutinize it alone, without having to instantiate the rest of the system and put the test data into the DB.

What is your experience? Did you have situations, when well-designed and well-documented code is difficult to maintain, because it is not modular enough?

Minimize the review burden by applying the review on a smaller bits of code

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.

The modern version control systems including even CVS provide the excellent feature to aid the code reviews – commit emails. Every time the developer commits the changes to the repository, it is possible to send an e-mail with the code changes, task name and description to the team leader, assigned reviewer or just everybody interested. This way the review process goes much faster and what is of biggest importance helps to find stupid errors earlier, saving you from spending yet a lot of time on debugging.

Have you ever try code reviewing initiated by commit e-mails? Does it work for you?

Performancing Metrics Module lately launched a beta of the very cool blog statistics service. It is created especially for bloggers with the AdSense click and comment counter. I don’t like modifying the theme templates just to include the yet another statistics counter. So I created a small and simple Drupal module for PMetrics. And decided to share it with everybody interested 🙂

If you are running Drupal, simply upload the PMetrics module to your modules directory and enable it in the admin/modules. That’s it. No extra settings required. Register at Performancing and analyze your logs.

Schreenshot from ProBlogger

Feel free to modify the module or sell it. If you use or modify the module it would be very kind of you to put a link to this post at your site, but it is not required. No license attached to this module.

Backing up the unreliable people

Scrum Master role in the Scrum development method in the first place “was designed to change the power relationship and interaction dynamics from the traditional Team Lead or Project Manager”. Scrum Master organizes the daily meetings, removes the impediments, reminds the Sprint goal, often maintains the Sprint backlog and does other secretary-like work.

Scrum is all about the self-organizing teams. Then why can’t the team itself do all these tasks? The answer is in that the only thing people are reliable in being unreliable. Without any evil intentions people tend to forget the agreed ways of working. From my point of view the main function of the Scrum Master is exactly to remind the agreed terms. As in any other agile method, team members have a lot of freedom in changing the rules of the game to suite them, but they are given the power of change only at the beginning of the iteration and have to express it explicitly. Scrum Master is for keeping the contracts during the iteration.

As far as I know in the eXtreme Programming there is a coach role that is dedicated exactly to keeping the XP rules. Could the XP-practitioners comment on the coach role? Is it analogous to Scrum Master or is it strictly about forcing the rules?

Scrum takes over XP

Extreme programming and Scrum are probably the most known agile software development methods over there. I myself find Scrum being more attractive and putting fewer requirements on the people communication skills. Have you ever wondered which method is more popular, which one is more talked about and what is the trend? I decided to ask the ubiquitous source of information – the web. I searched for “agile AND scrum” and “agile AND (xp OR extreme programming OR extremeprogramming”). “agile” is included to cut out the rugby’s scrum. The search engine syntaxes are a bit different; you can see the concrete queries, by following the result links.

So here are the results:

Engine XP Scrum Scrum/XP
Google Web 1630000 384 4245
Google Scholar 4160 704 5,9
Technorati 6662 1429 4,7
Google Blogsearch 2585 1190 2,2

“General public” awareness of XP is 4000 times higher, than of Scrum. You can confidently state that the majority of people who heard about XP never heard about Scrum. If you look at the research community, it is evident that there is much more research about the XP, but the ratio is just 5,9. The ratio of the active discussion numbers is even less: from 4,7 to 2,2 depending on which engine you trust more, but anyway lower, than the web and scholar ratios.

To me these results look like a proof of a big Scrum potential. It is researched and discussed a way more, than you might have thought.

What do you think? Are the results correct? Did I miss anything important?

Waterfall 2006

A great sample of satire: Waterfall 2006 conference.

After years of being disparaged by some in the software development community, the waterfall process is back with a vengeance. You’ve always known a good waterfall-based process is the right way to develop software projects. Come to the Waterfall 2006 conference and see how a sequential development process can benefit your next project. Learn how slow, deliberate handoffs (with signatures!) between groups can slow the rate of change on any project so that development teams have more time to spend on anticipating user needs through big, upfront design.

Attend these valuable tutorials:
– Eliminating Collaboration: Get More Done Alone by Jean Tabaka
– Making Outsourcing Work: One Team Member per Continent by Babu Bhat
– User Stories and Other Lies Users Tell Us by Mike Cohn
– FIT Testing In When You Can; Otherwise Skip It by Ward Cunningham

Good and evil of software platforms

Software platforms by definition are

“some sort of framework, either in hardware or software, which allows software to run. Typical platforms include a computer’s architecture, operating system, or programming languages and their runtime libraries.”

Business requirements driven platforms

Lately I’ve heard an opinion of one manager that the platform features should be driven by the business requirements and then these features will enable the concrete products. As an agile methods supporter I immediately became suspicious: anything that does not directly add value is over-design and are very likely to be useless and harmful.

The danger is in the fact that the business requirements discovered by some business analysts might simply hang in the air without the real link to the implementation, while various project will struggle trying to do the concrete things what their concrete customers want. The horizontal platform can easily become unbalanced, with too much effort put into never used features while some other components are not flexible enough.
Project driven platforms

As Joel Spolsky correctly notes:

“It’s really, really important to figure out if your product is a platform or not, because platforms need to be marketed in a very different way to be successful. That’s because a platform needs to appeal to developers first and foremost, not end users.”

The crucial mistake of business requirements driven approach is the assumption that these are the end-users who are the target audience. They are not. The platform customers are the developers and concrete projects.

Good and evil

So are the horizontal platforms evil? Not really. System libraries are useful, encourage the code reuse and save the developers from the unneeded low-level details. The only thing the platform designers should pay big attention to is who the actual platform customer is and how exactly the platform helps them. Platform driven by the [generalized] project requirements greatly facilitates the application development and exactly at the points where help is needed.

What is your experience with the platforms? What of the platforms you used was the most useful and why?

Overagiling in testing

Jonathan Kohl, a writer on software testing issues talks about good and bad in software testing. To me the key idea is that Agile testing does not mean throwing away all the testing habits and practices you got from waterfall or whatever approach you used. Agile development and testing is not a new silver bullet, it’s just a more efficient way of using the old good things.

Agile methods have some great things going on with regards to testing, but we’ve been set back by a lot of bad testing folklore that was rehashed under the “Agile Testing” banner in early writings. Sometimes ridiculous claims that software testers have heard for years were once again trotted out as “wisdom”, such as “manual tests are harmful”, or “every test must be automated”, or “testers are the Quality gatekeepers on a project”.

Recently, I’ve worked with more and more developers who were misled by the “Agile-Testing” folklore that automated unit testing encompasses software testing.

Via IndicThreads

Error handling

Check out the post on error handling by Mika Raento, the researcher at the University of Helsinki, Forum Nokia Champion and the author of the huge amount of free source code examples for Symbian.

Mika talks on the ways of error handling in software and how the developer can aid the error handling:

  • You may need to document specific errors and supply additional information to the immediate caller.
  • The error information must support generic handling strategies, like a blind retry.
  • Low-level exceptions should not be remapped by upper layers.
  • The routine detecting an error is responsible for describing it in terms understandable to a human, often the user.
  • The system must be able to tell the user if they should contact another human.
  • The system must produce different messages for consumption by different humans.