Agility and code quality

Some days ago, I attended a meeting, where different projects’ agile people met and talked about challenges, achievements, stuff. Actually it was not the first time we met. The meeting has been held for months now. For these long months, there has been something that was bothering me about these discussions. I couldn’t name that thing, so I stayed silent, but now I think I suddenly recognized it (under a hot shower, sorry if it’s TMI – too much info). After these months it seems to me that people percieve agile as daily stand up meetings + retrospectives (or just the first one, in case of Kanban development). Some of these people are amazed that they’re still getting bug reports in spite they “are doing agile”. Standups: check, retros: check, planning meeting: check, but bug reports, however, still flowing in.

Don’t get me wrong, I’m not against these things. Daily standup is a very important thing. It facilitates communication between team members, or sometimes even between different teams. Daily scrum alone, however, will not make code quality any better. It will strengthen team spirit, it will help everyone to keep track with every aspects of the current development, but it’s not meant to get source code in a better shape.

The same applies to retrospective. It is a very cool forum to talk about strenghts and weaknesses of a team. Even better if constructive ideas arise (by the way, I don’t understand why some people think retrospectives cannot fit into Lean/Kanban ways of working. The process itself can be trailored and developed; for new teams it can be particularly helpful). In my opinion retros are one of the most important meetings of agile frameworks. It’s psychology, I guess. Some people simply won’t tell their ideas, unless they are told to do so.

So, standups and retros (along with other meetings) fail to improve code quality. That’s because agile ways of working  can be divided into two parts:  the process itself and a technological part. The process part mainly contains of the meetings described above, definitions of done, team rules, team members’ motivation etc. One needs soft skills in order to manage/take care of these things. By soft skills I mean empathy, friendliness, motivational skills etc. And all these things will not get you a good quality product. It’s because quality is directly related to technical skills. Technical skills include test driven development, code review, pair programming, design discussions and so on. So, will code review help improve quality? Most probably. You might spot suspicious code lines, liar names, uncovered production code. Will TDD help? Definitely. Your code will be doing exactly what you expect it to be doing.

I once heard of a project where all the soft skills were perfectly applied. All staff members were happy with their work, they have had daily scrum, retros, everything. However, when it came to unit tests, they were like: “well, uhm, our unit tests require a living connection to the database, a writable file system, a network connection …” and so on (remember the definition what does not count as a unit test: a test which touches the file system, talks to a database or over a network. Anything that lives outside of the test runner framework). So even if these guys respected all the soft-skill related part of agile, were producing not so good quality. They were stuck at a low level of technical skills.

So what I’m saying; it makes no sense to apply only one or the other part of an agile dialect in solitude. You need both of them in order to succeed. Soft skills in order to get motivated and happy people, and technical skills in order to produce fewer bugs and maintainable architecture. No process hsould be called agile until both parts are applied, in my opinion.

Null object pattern

This little and easy to use pattern is very useful, but still unknown to many people. Maybe it’s because when someone says “pattern”, we automatically think of patterns invented by the Gang of Four. Even if this one is not part of the original 23 GoF design patterns, it’s worth taking a look at it, since it can make design more clear.

So, what’s Null Object Pattern (or Empty Object Pattern, as a colleague of mine suggested at a session where I presented this pattern) is all about? Let’s suppose we are given an application which reads data from a database (as a response to a search, initiated through a GUI), after which it passes the data through several layers and presents the result on the GUI. Let’s  say the above mentioned data object is of type User. Now, what happens if there are no results to the query? In a classical design, that might result in a null value returned . From that point on, every single layer might check whether the object they are working with is null or not. If it is null, the current method further returns a null value, or works with it otherwise. The logic

if (user == null) {

    return null;

} else {

    // something useful


is duplicated over and over again through each and every layer of the application. It is necessary, after all, or else the application will throw a beautiful NullPointerException.

How can we avoid these if-else statements? Easy; imagine the following class hierarchy:
As you can see, we have refactored the User class, and made it an interface (or abstract class, if you wish). This way you don’t need to touch any of the methods’ return statements (of course you don’t need to call the concrete class ConcreteUser). Now, the implementation of the User class is moved down into ConcreteUser. As EmptyUser is also implementing (or extending) User, it has to implement all the methods defined in User. And now, the trick: we implement all the methods with an empty body. That’s right; a body with no statements at all. So, EmptyUser would look something like this, in our case:

public class EmptyUser implements User{
    public EmptyUser() {

    public void method1() {

    public void method2() {

So what’s the benefit? When our database query returns null (remember, we have to check here that the returned value is null or not), we don’t push it forward. We simply instantiate an EmptyUser object, which will be safe to call any method on. This way we can eliminate each and every if-null constructs (but the first). The design can now focus on the logic itself, rather than keeping doing null checks.

A very simple exercise on Null Object Pattern you can try at home; given an object called Book. A book has an author, a title and a getInfo() method, which can return some basic book info, in the format:

Author: Gabriel Garcia Marquez

Title: One hundred years of solitude

You are also given a “library”, in form of a hash map; the key is an ISBN number, the value is a Book object. Your task is to implement the LibraryInfo interface, defined as:

 public interface LibraryInfo {

	boolean isIsbnValid(final String isbn);
	Book getBook(final String isbn);
	StringBuilder getBookInfo(final String[] isbns);

isIsbnValid is pretty straightforward. It returns true if an ISBN value is valid, false otherwise.
getBook: if the ISBN number passed in as a parameter is valid, and the ISBN can be found in the library (the hash map, remember?) it returns the book found. NOT NULL otherwise 🙂
getBookInfo: checks ISBN numbers, queries the library for them and appends together all the resulting book information (remember that you don’t have to check for nulls at all here)

Don’t forget to use the Null Object Pattern

Competence tracking, a big lie

In the past two years, I’ve been asked for several times to evaluate my competence using Excel sheets. The process is always the same: there’s given an excel sheet with an enormously high number of different skills, technologies, techniques and frameworks. My task is to select a competence level for each of them. Usually there are three different levels; no freaking idea, medium and hero. Now in my opinion, this whole competence tracking is pointless, because:

  1. Everybody lies: And by everybody I really mean everybody. Weakly performing colleagues will choose higher competence levels, because they want to seem better professionals. Such a way they can avoid unpleasant questions, discussions with their managers. On the other hand, best people will lower their imaginary skill-level. Ever heard of the Dreyfus learning model? According to that model, people reaching higher and higher professional levels are not the ones with the best teaching capabilities. However, in an organization, usually they are in charge for leveling up new colleagues. Of course they want to avoid teaching people, so they simply lie.
  2. The scale is not accurate enough: The fewer stairs on the scale, the easier to under or overestimate someone. But as you increase the stairs, it is becoming harder and harder to place people on the scale. Getting back to the above mentioned three-stairs scale: who’s medium and who’s hero? Someone using (e.g.) Spring framework for three months; are they clueless or medium. And what about someone using it for two years? Are they hero? Maybe. But what if they are using if for RMI only? Still hero? I don’t know… Hard to say.
  3. Nobody takes it seriously: People most likely will forget about the whole thing, and fill up the stuff superficially – at the third or fourth request. It’s usually told that “it doesn’t take more than five minutes”, and surpriseee, people won’t spend more time with the spreadsheet. By the way, they won’t ever update the table by themselves, even if they acquire new competences. That means that the whole competence tracking process needs heavy management supervision. This can include multiple check-send remainder mails-check cycles, which is wasted time. On the other hand, can competence decrease? If soemeone doesn’t use a technology for ages, is that lost competence? Even if it is, I bet no one would ever track that in a competence file.
  4. Because not the technologies themselves matter: Think of people in your organization whom you consider the best. Are they the ones who can enumerate thousands of technologies and frameworks they’ve ever used, or the ones you can give any kind of job, and you can be sure it will be done right? Which group would you rather work with? As it is commonly said: not knowledge itself matters, but its derivative (= the ability to learn new things).
  5. Because tracking knowledge is booooring: I don’t think this needs furter talk.
In my opinion, the only valid competence measurement process regarding a person is to ask some of their coworkers, what they think about that certain person from the point of view of professionalism (on a scale of ten, for example).