Definitions

According to Wikipedia, a cross-functional team is:

A group of people with different functional expertise working toward a common goal. It may include people from finance, marketing, operations, and human resources departments. Typically, it includes employees from all levels of an organization.

If we instead look at the definition of a cross-functional team in Wikipedia’s Agile Software Development article, we learn that such a team “is usually cross-functional and self-organizing without consideration for any existing corporate hierarchy or the corporate roles of team members.” This seems to suggest that the meaning of cross-functional in agile is often interpreted a bit differently.

Why confusion arises

Part of the problem might be that leaders in the field are sometimes a bit unclear. For example, reading Henrik Kniberg’s otherwise excellent piece on agile testing quickly, you can easily get the perception that he is arguing for the generalist approach. Quotes such as the following certainly helps one reaching such a conclusion.

In agile projects, testing is considered to be far too important to be confined to a single role, a single team, or a single project phase. Having a role called Tester implies that others don’t need to test. In an agile project almost everyone tests.

On the other hand, if you read it more carefully, he is actually arguing for a specialist approach. (Although he plays safe — and increases confusion — by calling them generalizing specialists.) Anyhow, this quote gives a rather other feeling than the previous.

Since the programmers have automated all the boring, repetetive tests, you are free to focus on the hard stuff. The stuff that is difficult to automate. Exploratory testing. Usability testing. Performance test scripts. Figuring out those tricky test cases that only a veteran like you could come up with.

Finally, in his own words:

Agile teams are cross functional, they are made up of generalizing specialists. People who are experts at certain areas, but have basic knowledge of a whole bunch of other areas as well. A team of generalizing specialists is extremely fast at learning and adapting.

Why specialists?

For me, I’m in the specialists camp. As some form of evidence, I’d like to quote Marcus Buckingham and Curt Coffman from the great book First, Break All the Rules.

Great managers do not believe that a productive team has camaraderie as its cornerstone and team members who can play all roles equally well. On the contrary, they define a productive team as one where each person knows which role he plays best and where he is cast in that role most of the time. … The founding principle here is that excellent teams are built around individual excellence.

The nice part about this last quote is that it is not simply anecdotal “evidence”, but actually conclusions drawn by the Gallup organization after interviewing over 80 000 managers!

Your experience?

What’s your experience in the matter? Is specialist or generalist the way to go?

A few days ago, I a girl caught my attention on the tram. Now, a lot of girls catch my attention, but this time it wasn’t actually the girl herself but her shoulder bag which caught my attention. It happened to have a print which I thought was pretty funny.

Join a proud minority — read books.

First I thought that was rather witty, but then it actually made me sad. Are people who read books (by free will) actually a minority? If I restrict myself to the software development world, then apparently they are. According to DeMarco and Lister in Peopleware:

The statistics about reading are particularly discouraging: The average software developer, for example, doesn’t own a single book on the subject of his or her work, and hasn’t ever read one. That fact is horrifying for anyone concerned about the quality of work in the field.

Consider if this would have been some other field, say medicine. Would you have liked to hear your surgeon say, “nah, I don’t really read books, I base most of what I do on reading blogs”. I sure wouldn’t!

Why you should read books

Alright, why should you read books? Why not just read blogs? Good question! And here’s why:

Books are better than blogs!

Now, that’s a pretty tough argument. Of course, I’m not saying that blogs are bad, but what I am saying is that so much more work has been put into the really great books than into any blog out there. Don’t waste all that work! By reading books, you will learn stuff you otherwise wouldn’t have and you’ll get a deeper understanding of it.

Now, don’t get me wrong. Blogs are truly essential and a great part of the internet. All programmers should consider themselves very lucky for having access to all that material. However, their content is typically only good after a couple of loops in the echo chamber (aka blogosphere). When you buy a (good) book, the material you get is already refined, it has already gone through all that necessary editing.

When not to buy books

You might ask yourself, why should I buy books which will be outdated in a year anyway? Also, there are no hyperlinks in books. Books suck! Well, in this regard, I completely agree. The answer is:

Don’t buy reference books.

Here I’m going to quote Jeff Atwood, because he explained it very nicely.

The best programming books are timeless. They transcend choice of language, IDE, or platform. They do not explain how, but why. If you feel compelled to clean house on your bookshelf every five years, trust me on this, you’re buying the wrong programming books.

How about you?

So, that’s my thoughts on the subject. What do you think? Do you read books? What is the best book you’ve read? The worst? Why? Answer with a comment!

I often get inspiration to write posts from reading books or blogs by really smart people. Thus, I often refer to people who are smarter than me. Sometimes I’m lucky enough to get comments from these people on my posts. While I’m typically rather convinced by my own reasoning when I write the post in question, every time I get such a comment I am struck by how much smarter they are than me.

Recent cases where this has happened:

• Mike Cohns comment on Not Converging on an Estimate: I discussed an adaption of some advice he gave in a book. However, my adaption forced me to ignore other parts of the same advice. He pointed out that there was no problem in actually doing both parts.
• Full Statement Coverage: I wondered why Ron Jeffries was writing such sloppy unit tests in some of his articles. He didn’t seem to test even half of the code he wrote. A short email conversation later I had realized that he of course wasn’t sloppy, but rather just much more clever than I was.

So, I simply hadn’t understood what they meant the first time? I don’t believe it’s as simple as that. I think I did understand. Most of the time anyway. But my level of understanding just wasn’t as deep as theirs.

The upside is that every such moment makes me a little bit smarter! Have you experienced a similar situation? What was your latest “revelation”?

The steps

I tried to perform the following steps.

1. Define the scope of what you’re estimating.
2. As Mike Cohn suggests, ask each developer to make an estimate and write it down.
3. After everybody has made up their own mind, take note of all estimates.
4. Discuss the estimates if wanted, but do not revise them! (Unless someone completely misunderstood the scope.)

By writing the scores down and not revising them, developers do not get a chance to influence each other. If all of these original, uninfluenced, estimates are close to each other, you can probably be more secure with that estimate. On the other hand, if they are spread out you get an indication that risk is rather high. Estimating this way actually gives you more information, as you not only get a mean value from the estimates, but also a precision or confidence interval.

Related thoughts

Max Pool has been arguing for a similar approach, where you estimate in ranges. However, using the approach suggested above, you don’t have to set a percentage probability yourself (which might be a hard number to come up with) — you get it for free.

Furthermore, if you think about it, estimating with just a single value is almost meaningless anyway — you’ve always got a precision, that is, an interval. When you say that something will take “2 days”, what is the precision? Two days within a second? Minute? Hour? Day? Week? Also, is it an upper bound? Lower bound? Mean value? Using an interval gives you a good way of making these assumptions much more explicit.

What are your thoughts? Have you estimated using something else than a point value? Do you disagree? Let me know!

Update

In his comment below, Mike Cohn pointed out that I in fact can have my cake and eat it too. I can use the highest estimate as a “upper bound” and also continue discussing and re-estimating until everybody agrees on a single estimate. That way we get a range but do not lose the valuable discussion during the convergence.

As a keynote speaker at a software conference, Enrico Zaninotto, an Italian economist, pointed out that the underlying economic mechanism for controlling complexity in just-in-time systems is minimizing irreversible actions.

The notion of “minimizing irreversible actions” strikes me as a better way of capturing that whole idea than the more established “last responsible moment“. The latter suggests that you should delay making decisions for as long as you can. I feel that sends the wrong signal. You can make decisions. You must make decisions. Not making a decision is a decision in itself. Just don’t make decisions that you cannot change — keep your options open. By thinking that you must not make decisions until the “last responsible moment”, it is easy to delay the decision longer than is actually responsible.

I believe this is especially true for software architecture. In the name of “last responsible moment”, many developers avoid making architectural decisions, thinking the architecture will emerge by itself. But to quote Grady Booch in a response to a letter “The Relevance of Architecture” in IEEE Software (Volume 24 Number 5).

Every system has an architecture; some are accidental, others intentional.

Which is yours?

The problem with this comparison is that it’s simply wrong. I’m fine with comparing creating software with creating a car. But the closest thing to an assembly line in software development is the work done by build and deployment scripts, turning source code into executable software. The actual analysis, design, and coding corresponds to developing a brand new car model. It is a creative process without a single given “right answer” and of which experimentation and iteration are natural ingredients.

To use another metaphor, and at the same time cite Mary and Tom Poppendieck from their book Lean Software Development:

Development is like creating a recipe, while production is like making the dish. Recipes are designed by experienced chefs who have developed an instinct for what works and the capability to adapt available ingredients to suit the occasion. Yet even great chefs produce several variations of a new dish as they iterate toward a recipe that will taste great and be easy to reproduce.

If a commit message feels very long, or you feel a resistance against writing it because you don’t know what to write, it has probably been too long since you last committed! If you commit after each task is done, writing a good one-sentence message is a no-brainer.

Every time I manage to actually do a proper cleaning of my apartment, I usually think: “Okay, now the apartment is clean, it shouldn’t be too difficult to keep it this way. I’ll just make sure that after every day it is still clean.” That’s a great rule in theory but it never works in practice. As soon as you slip, and let the apartment get messy, you’re lost. It has now become more of a mess than you can muster energy for to clean up.

A different strategy

But my friend suggested a different strategy: “Before you go to bed every night, make sure that the apartment is at least a little bit cleaner than it was when you woke up.” This rule has worked out extremely well for me. They both work fine as long as I follow them every single day. The difference is when I slip, when I allow the apartment to become a bit of a mess, I won’t automatically freeze and ignore it. All I have to do is to remove one single thing from the floor or wash one single glass, and I will have fulfilled my promise. If I just keep doing this, my apartment will eventually be clean. And also, once I’ve picked this single thing from the floor, or washed that single glass, it’s rather easy to take another and a third one as well.

When your apartment finally is clean, you’ll have to use a bit more imagination to fulfill the rule. You might archive those payed bills lying in your closet, remove the clothes you never use in your wardrobe and send them to a suitable charity, or do any other thing that you’ve long thought of doing. This would never even have happened with my first rule as it would have acknowledged my apartment as clean and I would need to do no work.

In software development

The reason I’m talking here about cleaning my apartment, is that I believe the very same principle applies to software development as well. It’s easy to ignore accumulating technical debt in your system, become paralyzed by it, and not have energy to deal with it. In that situation, just ensure that the system gets a little better by every commit, and one day, you’ll realize that your system is really in quite nice shape. So don’t aspire to be perfect, just to become better every day and you’ll get there (or at least very close ).

Then, somewhere about the turn of the century, agile development became the preferred way of creating software in the more trendy corners of the development community. Today, mainstream developers have started to follow and software shops all over the place are introducing Scrum, doing test-driven development or using other agile techniques.

In the second edition of his popular book Code Complete, author Steve McConell describes this by saying that while he was writing the first edition, design zealots argued for “big design up-front” (BDUF), and as he was writing the second, software swamis instead argued for “emergent design”, which basically means no initial design at all. As he put it:

In ten years the pendulum has swung from “design everything” to “design nothing”.

Now it seems to me that the pendulum is on its way back.

In an article in IEEE Software, the July/August 2008 issue, Rebecca J. Wirfs-Brock argues in favor of up-front design.

These days, some developers shy away from even suggesting that a project might need up-front design and experimentation. They equate any up-front work with “big design up front” (BDUF) and totally wasted effort. Up-front design needn’t be wasteful if you develop a design rhythm that balances thinking, learning, and doing. You’ll build confidence and sleep better at night.

On a similar note, Justin Etheredge argues that some agile developers might be a little bit naïve.

A lot of developers think that agile development represents doing no design up front. That we will figure out what we want to do and then just jump right into coding it without any concern for what we are going to build. Then we will just come back later, refactor the whole thing, and voila, instant working application. Well, it just doesn’t work that way.

Frans Bouma adds to the theme, possibly suggesting that even laziness might be a part of it.

Yes, Software Engineering is hard, deal with it. Don’t use the excuse that because goals are unknown, because the client changes his mind every day the design therefore has to be done in the code editor. If those are your problems, solve them, deal with them.

My own earlier posts deal with similar issues, such as developers who do TDD without thinking, and that you can't skip design.

To be fair to gurus arguing for the principles of agile development (which to a large degree I myself believe in), these comments apply more to average developer Joe than the gurus themselves. But then, the gurus are probably smart enough to succeed in building their software no matter what process they use. There are however way more average Joes than gurus, so the points above are still very valid.

Given this shift of thinking, where will we head now? Will the pendulum actually swing right back to BDUF? Will we find the sweet spot between emergent design and up-front design? Or will we rush off once again in a new chase for design nirvana? If so, where will we end up this time? I sure hope for the sweet spot option, but given human nature I’m not convinced. What are your thoughts?

When using Struts 1.3 with Tiles and SSLEXT plug-ins, the application server throws the following exception while trying to process a request.

SEVERE: Allocate exception for servlet action
javax.servlet.UnavailableException: TilesPlugin : Specified RequestProcessor
        not compatible with TilesRequestProcessor
    at org.apache.struts.action.ActionServlet.init(ActionServlet.java:399)
    at javax.servlet.GenericServlet.init(GenericServlet.java:212)
    ...

Cause

You are using a RequestProcessor which does not extend TilesRequestProcessor, most likely org.apache.struts.action.SecureRequestProcessor provided by SSLEXT.

Solution

As stated on SSLEXT’s web page, in order to use Tiles and SSLEXT together, you need to use specific Tiles-enabled custom request processor and plug-in classes. These classes are provided by SSLEXT and their full names classes are:

• org.apache.struts.action.SecureTilesRequestProcessor
• org.apache.struts.tiles.SecureTilesPlugin

Note that the SSLEXT web page incorrectly states the last class’ name as SecureTilesPlugIn (with a capital i).

See also

• http://sslext.sourceforge.net/
• http://www.jroller.com/JamesGoodwill/entry/using_tiles_and_a_custom

I can’t help to wonder, however, what’s so magical about 40 the hour workweek? Why not 35, 45, or even 55? Also, it will naturally vary among different people. So I want to know where to draw the line. Just playing safe on 40 seems a waste, if my team can do better.

The capacity model

In the figure above, I’ve created a simple model for how I imagine things work. It’s pretty safe to assume that everyone has a maximum productivity level, over which it is simply not possible to get. I’d say this maximum is defined by the programmers talent. No matter how much experience, practice or training one gets, there’s still some basic inherent talent level which defines one’s maximum. (If nothing else, let it be the number of words per minute the developer can type.)

More interestingly, we’ve got a current capacity which is the highest amount we can currently produce without lowering quality. A sustainable pace is any pace which is below this current capacity. That is, we can keep going at this rate forever, without accumulating any technical debt. We can go above it once in a while too, in a coding crunch, but then we start accumulating technical debt. This forces us to work at a lower rate later to pay back.

How do you go faster?

There are at least two interesting questions in this model. First, how do you find your current capacity? I believe that question can be answered empirically by increasing development speed until developers start getting (too) tired and bugs start to slip in. The second, and more interesting, question is: how do you raise your current capacity? To answer this, we must first answer another question which is: what defines your capacity? (In the figure, this unknown entity is called x.) My best bet is motivation with a tad of discipline thrown in for good measure.

To sum up, my point is that while we want to achieve a sustainable pace in development, we shouldn’t have to limit ourselves to 40 hours per week. If we can hold a sustainable pace of say 45 hours per week, as opposed to 40, we gain more than one month of extra development time during a year! Especially in start-ups, such as where I work, 40 hours a week is a luxury one cannot afford. Large companies such as Microsoft and Google also very much rely on peoples desire for and ability to work (much) more than 40 hours per week. So the question is, how do we increase our development pace while keeping it sustainable? Is it possible? (I sure hope so.) If so, how do you do?

No matter exactly what task it is, we’ll assume that completing it is something that would require many man-weeks to complete. Time that we typically do not have in the condensed schedule of a modern software development project. Thus, it can be hard to motivate spending the resources that would be required to perform such a change. All to often, this leads to a situation where change is regarded as “something that should be done, but which we don’t have time for right now”. That is the same thing as “something we will never do”. Furthermore, as we typically perform the improvement in order to make the code base easier to work with in the future, we want to prioritize the parts of the system where we spend most of our development time.

A simple rule

In situations like this, I suggest the following rather simple rule.

Every time you commit, ensure that all files in that changeset are updated to the new standard.

Thus, if your current commit touches a controller which contains business logic, you may not commit until you’ve extracted and merged it into the model. Or if your commit touches an undocumented or untested class, you may not commit until that problem has been corrected.

Rationale

The rationale behind this recommendation is twofold. First, the performing the change won’t feel like a gigantic task, as it only involves modifying a couple of classes at any time. This helps to get around the “something that should be done, but which we don’t have time for right now” problem. This helps to amortize the work over the course of the project.

Secondly, you don’t spend time on updating files on which no one is working. This connects to the assumption that the improvement is done in order to make the code base easier to work with. Thus, as long as no one is working on a file, there is no need to make the improvement there. However, as soon as someone touches that file, it will brought up to the new standard. This is really just the Last Responsible Moment principle, or YAGNI, put in a slightly different context.

As a bonus we reduce the risk that the change introduces bugs. This is because, as opposed to performing the change in one big go, only code on which the developer has just been working is updated. Thus, the developer is more familiar with the code and is in a better position to avoid introducing bugs by breaking non-obvious relationships and dependencies in the code. This advantage becomes more important the worse shape the code in question is in.

Possible drawbacks

To be fair, I should mention possible drawbacks. The major argument against this method is that the system is left in a “in between” state for an extended period of time. Depending on the type of change this could become problematic. If you’re switching from using one library to another, you might for a while be dependent on both libraries rather than any one of them. This might in turn create confusion about what library to use. Or if the system is in the middle of a major large scale refactoring, developers might in the same way be confused about the correct way to implement a feature.

I think that the best solution to this problem is to ensure that all developers are aware of what is happening. It’s really a question about communication within the team. Exactly how to solve this potential problem depends on the team. You can create a list of ongoing improvements which everybody can check when in doubt or when committing. You can emphasize collective ownership of the code and use pair programming to spread knowledge. Do whatever fits your team, as long as you consciously considers and manages the risk.

Summing it up

All in all, I think performing large scale changes in many smaller chunks is the preferred way to go. Pay off some of your technical debt every day, rather than all of it at once. After all, to pay off your whole technical debt at once, you most likely will have to take on debt of some other kind — economical, working overtime, or implementing less new business value.

The problem: My team had a lot of index cards which we wanted to put on a wall in order to simplify planning. We had thought about using pins, tape, magnets, and pretty much every type of device used to put a piece of paper on a wall known to man. That’s when I found it.

The solution: Flexible and adhesive magnetic tape. Just stick a piece of tape on the back of the card. Then you can post your cards on a whiteboard and move them around all day long. Up, down, left, right, left again, rearrange. If you wanna take it down and edit it, just do it and put it right back up again. So simple, so obvious. Love it!

If you happen to live in Sweden, you can pick a roll up at Clas Ohlson. In the US, I found the same product at The Magnet Source (see product C). They’re cheap too.

When running an optional Ant task (e.g. scp or sshexec) through the Eclipse Ant interface, you get an error similar to the one below.

BUILD FAILED
C:\Path\To\build.xml:45: Problem: failed to create task or type scp
Cause: Could not load a dependent class com/jcraft/jsch/UserInfo
       It is not enough to have Ant's optional JARs
       you need the JAR files that the optional tasks depend upon.
       Ant's optional task dependencies are listed in the manual.
Action: Determine what extra JAR files are needed, and place them in one of:
        -C:\Path\To\Ant\Home\lib
        -C:\Path\To\User\Home\.ant\lib
        -a directory added on the command line with the -lib argument

Do not panic, this is a common problem.
The commonest cause is a missing JAR.

This is not a bug; it is a configuration problem

However, you have found all required dependencies for the tasks you are trying to use and put them in one of the folders as specified.

Cause

Although you have added the right dependencies, Eclipse might not yet know of the file(s). If this is the case, you can see this by running Ant diagnostics (ant -diagnostics on the command line or the <diagnostics> ant task). You will see that the dependency is listed in the appropriate “lib jar listing” but is missing in the java.class.path system property.

Solution

Go to Window > Preferences > Ant > Runtime > Classpath, select “Ant Home Entries (default)” and click “Add External JARs…”. Select the required dependency or dependencies and accept. Now, the selected JAR files will be loaded to the class path and the optional ant task depending on them will work.

Traditional vs Test-Driven

The traditional way of developing (if there is such a thing) typically follows this pattern.

1. Implement a feature.
2. Test follows from implementation.

Whereas Test-Driven Development reverses that order.

1. Test a (missing) feature.
2. Implementation follows from test.

The idea here is that if we design and write the test before concerning ourselves with a particular implementation, we are more open-minded and the resulting feature will be designed as we want to use it rather than how it’s easiest to implement.

Thoughtless Development

Some people (myself included, in an earlier life), tend to get this idea slightly wrong. They end up with, what I call, Thoughtless Development. When converting from traditional development to TDD, they know the implementation is supposed to go last and follow from the tests.

For some reason though, they keep the “test follows from implementation” part. But as the test is supposed to be written first, there is no longer anything it can follow from. To make it even better, it is also supposed to be as simple as possible, which is easily interpreted as easy to do as possible. The flow typically ends up something like this.

1. Test follows from (vague expectations of) implementation.
2. Implementation follows from test.

Do I need to add that they typically end up with a heap of junk? That’s because there is no room for thought in this process. All the thinking and care that should go into designing tests is forgotten.

As I’ve written about earlier, some people tend to use TDD as an excuse for doing no design at all. Either purposefully or by accident. This is ironic, as TDD is really all about design! So let us all make sure that we are doing Test-Driven Development, and not Thoughtless Development.

We want a collection field belonging to an entity object to be sorted.

Solution

There are two possible solutions:

• If you want the collection to be sorted when loaded, but not necessarily keep that sorting order all the time, use the OrderBy annotation where you set the actual ORDER BY SQL clause. In that case, the collection can be of any type (e.g. Collection).

• If you want the collection to be sorted at all times, make it of type SortedSet or SortedMap and set the Sort annotation.

  • If the objects in the collection implements Comparable set type to SortType.NATURAL.
  • Otherwise set it to SortType.COMPARATOR and specify your own Comparator class in the comparator attribute.

Remarks

• There exists an annotation with name OrderBy in both the javax.persistence package as well as the org.hibernate.annotations package. The former should be used.

See also

• Collection related annotations

Joshua Kerievsky introduced the term Creation Method for these kinds of methods. The GOF pattern Factory Method is similar as it includes a subset of all possible Creation Methods.

So, how does a Creation Method differ from a constructor, semantically? When should one use one or the other?

Is computation required?

I tend to use a Creation Methods when the instance creation requires much computation. In one sense, it is very similar to when to use properties and when to use Get-methods in VB/C#.

Possibly, a Creation Method which does a lot should be seen as a separate responsibility and moved to a a separate Factory class. This is similar to what Joshua Kerievsky discusses in Encapsulate Classes with Factory, that some developers might not like having a class which has a Factory responsibility as well as its normal responsibility. In the end, I guess it’s a matter of taste.

Do you actually get a new object?

A Creation Method may be used when there is a finite set of possible objects to create. In such a case, a well named Creation Method may indicate that you cannot actually create a new object, but rather get one of the already defined.

An example would be the Java class Charset. There is a limited number of possible charsets (or at least number of charsets the system will understand), and therefore it does not provide a public constructor, but rather uses the method forName(String). You would use the following code to create a Charset object.

Charset c = Charset.forName("ISO-8859-1");

Other reasons

Another reason to use a Creation Method could be to hide the fact that it’s actually a (private) subclass which is being instantiated. In other words, that the Creation Method is actually a true Factory Method. See for instance the Money example in Kent Beck’s Test-Driven evelopment.

You’ve got more ideas on what differs Creation Methods and constructors? Post a comment.

Summary of coupling

Steve McConnell in Code Complete describes coupling as follows.

Coupling describes how tightly a class or routine is related to other classes or routines. The goal is to create classes and routines with small, direct, visible, and flexible relations to other classes and routines, which is known as “loose coupling”.

McConnell furthermore lists a number of different types of coupling, some of which are better than other.

• Simple-data-parameter coupling: All data passed between A and B are of primitive data types and passed through parameter lists. This kind of coupling is normal and acceptable.
• Simple-object coupling: A instantiates an object of type B. This kind is also fine.
• Object-parameter coupling: A requires B to send it an object of type C. This type is tighter since it requires B to know of C.
• Semantic coupling: A makes use of, not some syntactic element of B, but knowledge of its inner workings. Should be avoided.

Dependency injection to simplify testing

So, loose coupling is definitely good as it makes the system easier to work with. However, when I read one of Jeremy Miller's excellent posts I started thinking. He suggests using dependency injection to simplify testing in some cases, which to me seems to be creating tighter coupling within the system.

More specifically, the problem he describes is as follows. A class ClassUnderTest internally creates an object of type Dependency. However, if it is hard to create a new instance of Dependency equal to the first one (e.g. a datetime object representing “now”), ClassUnderTest becomes very difficult to test.

When the unit test wants to create a copy of the the hard-to-reproduce-object Dependency to compare with ClassUnderTest’s Dependency instance, a non-equal instance is created (the system clock has changed) and the test fails.

The solution is to provide the object under test with either:

• the Dependency object in question itself, or
• an object which provides ClassUnderTest with the wanted Dependency instance.

I agree with this completely. In fact, I’ve had the problem a number of times myself, and solved it successfully this very way.

In terms of coupling

With respect to coupling, the case is that before we add the test (let’s assume we’re testing legacy code) we have simple-object coupling, since ClassUnderTest creates another object Dependency. However, when we test ClassUnderTest we want to create another object of the same type as Dependency equal to the one ClassUnderTest created.

As noted above, the solution is dependency injection — to provide ClassUnderTest with Dependency, either directly or indirectly. That way, we have the possibility to get hold of Dependency to perform the assertion in question. In terms of coupling however, this changes the coupling to be of type object-parameter coupling which is considered tighter than the type of coupling we had before.

A counter argument

Thinking about this, I thought that maybe the key here is that to test ClassUnderTest in the first case, the test would need to be semantically coupled to ClassUnderTest because it would have to know what kind of Dependency object it created internally (”now” vs any other datetime) and try to recreate it in some clever way. So we actually replace semantic coupling with object-parameter coupling — an improvement.

The counter argument (to the counter argument) is that without the test code, we would have no need to create such an object and there would be no semantic coupling in the first place. Thus, writing the test tightens the coupling in the system.

The question

Am I missing anything, or is this an example of where designing for testability actually leads to worse (as in more complex and more tightly coupled) design? Or am I just getting lost completely in theory? Maybe this slightly tighter coupling is nothing compared to what we gain from having a good and simple unit test in place.

Programmers are good at imagining all sorts of future problems. Starting with one concrete example and generalizing from there prevents you from prematurely confusing yourself with extraneous concerns. You can do a better job of solving the immediate problem because you are focused. When you go to implement the next test case, you can focus on that one, too, knowing that the previous test is guaranteed to work.

I’ve found this to be very true. Before starting to think this way, I way to often started writing a test (or even started implementing some feature), only to stray away to a number of different tasks; adding guard clauses for the function, writing a helper function that I might need, refactoring a related method, and so on. By writing a simple test and implement that piece of functionality (and only that), then write a new test and implement that, and so on, my coding has become much more focused and I move forward noticeably faster.

However, this doesn’t mean you should just ignore thoughts on potential related problems. Write them down to look at later — but don’t let them grab your attention for longer time than that. Keep pen and paper ready at all times.

The problem was that instead of thinking about what functionality I actually needed, I just assumed that since I was going to measure time I needed a regular stop watch. Thus, the first version of my timer had the operations start, pause, stop and reset, where reset was only available when the timer was stopped.

After a while I realized I was pressing the sequence stop-reset-start a lot of times. I did it every time a task was finished and I was about to start with a new one. So to make my life easier I added restart which did just that.

After using it even more I realized that restart now actually was the only button I was pushing. Therefore, I simply removed all other buttons than restart (which was renamed reset).

The result is a very simple timer. It auto-starts and is then always running. Thus, no need for start or stop. That’s great for measuring time while working, because real time doesn’t stop. I always spend time doing something. The only thing I can do with my time is divide it into chunks of time which I spend doing different tasks. That is exactly what my reset button allows me to do — tell where one such chunk ends and the next starts.

I’m actually very satisfied with the result. What is rather funny about this whole thing is that although I first thought I needed “just a simple stop watch”, my need was in fact slightly different and even simpler.

P.S. If you want to use the timer, it’s available at http://timer.henko.net/. However, it currently assumes Central European Time (+1). Time is also only shown in hours, since that is how I enter time in my time reporting tool.

While evolving a design is good and nice one has to remember that even though big design up front might not be a good idea, all the hard design work still needs to be done at some point. Otherwise you’ll just end up with a big piece of garbage. Therefore, while starting with a story or use case, do take time and think it through and answer a couple of questions for yourself (not an exhaustive list).

• What is the goal of the story?
• In what ways can we solve this?
• How does these solutions fit into the current system?
• What are the pros and cons of these solutions?
• What are the larger problems (if any)?

However, while thinking about all this, don’t try to work all the details out, they will sort themselves out while coding. More importantly, don’t commit to any of the design alternatives you come up with. The important part is thinking the problem through thoroughly. A quote from David Eisenhower sums this up nicely:

In preparing for battle I have always found that plans are useless, but planning is indispensable.

Steve McConnell in the second edition of Code Complete, describes how while he was writing the first edition, design zealots argued for BDUF, and as he was writing the second, some software swamis instead argued for no initial design at all. He says:

In ten years the pendulum has swung from “design everything” to “design nothing”. But the alternative to BDUF isn’t no design up front, it’s a Little Design Up Front (LDUF) or Enough Design Up Front — ENUF.

Another take on this is to make the decision in the Last Responsible Moment, described by Jeremy Miller in one of his articles.

The key is to make decisions as late as you can responsibly wait because that is the point at which you have the most information on which to base the decision. In software design it means you forgo creating generalized solutions or class structures until you know that they’re justified or necessary.

However, one might not use this advice to justify not designing at all. The key here is that you don’t commit to a certain design (i.e. make the decision) until the last possible minute, but you still consider the alternatives — which of course requires you to research and actually think about them!

• are meant to make the program better.
• preserve semantics of the program (hopefully).
• should be driven by a real and provable need.
• can be harmful when premature/speculative.

In fact, they have the same goal as well. They are both meant to to make the program easier to interpret. The only difference is that refactoring tries to make it easier for the developer, and performance optimization for the computer.

This procedure is typically repeated a whole bunch of times. Thus, my thought process is a very iterative one. Unfortunately, I’m not in charge of the iterations. They usually end not because I’ve reached a new milestone, but because I’ve realized I’m hopelessly lost and need to go back to the beginning. Somehow still, (on good days) each iteration seems to make things at least a little bit clearer. Or at least every other iteration or so. Some of them just end in a big hopeless sigh.

Anyway, I finally either realize that I just can’t get it right, or I find a solution. If the latter, the solution typically has very little resemblance to my starting ideas. My thoughts have been distilled and refined over and over, and my initial assumptions have been overturned more or less completely. Actually, the solution typically is far more elegant and simple(!) than what I started with.

So why am I telling you this? Well, I’m not sure (still trying to get my head around that one ). But somewhere in the back of my head I wonder if this is not how I ought to develop software as well. Not that all iterations end in catastrophy, but that whenever I’m not quite sure of what I’m doing, I should throw whatever code I’ve been writing away and start over. Then, finally, the code I end up with will be simple enough for me to grasp in one go and only contains what I’m sure is absolutely necessary. Then of course, it is very hard to actually throw away code you’ve written. But maybe it’s worth it?

1. It says that while all tests pass, you’re not allowed to add new functionality. To do that, you have to add a new test which fails because of the lack of the wanted functionality.
2. Then you make that test pass in the simplest way you can imagine. In fact, while you have a test which fails, you’re allowed to do practically anything (possibly except cardinal sins) to make it pass.
3. After you’ve made it pass, you can refactor all you want to clean up the existing code, including the lines you just wrote.

This is the rhythm of TDD, which is often called red/green/refactor, as a reference to the color of the progress bar most unit testing interfaces use when test fail and pass.

Anyway, back to the eye-opening experience. As an example, lets use the following test, asserting that a method for calculating the sum of two integers is correct.

public void testSum() {
    assertEquals(8, sum(3, 5));
}

The simplest way I can imagine to make this test pass is the following code is just faking the implementation.

public int sum(int augend, int addend) {
    return 8;
}

Now, this really feels bad. We know that returning 8 is not a correct solution for all possible parameter values. On the other hand, the test is passing, which is my proof of that the program works. Nevertheless, just faking out the implementation feels like cheating. No matter how many more tests we write for this function we could always just continue faking it by making another special case, ending up with a gigantic switch statement rather than the real and much simpler function (I leave finding the correct function as an exercise for the reader ).

Now comes what for me was an eye-opener. Kent Beck in his book Test-Driven Development describes how to solve this problem nicely. He notices that there is duplication between the test and the implementation; not duplication of logic, but duplication of data. The duplication is also not explicit, but implicit. What return 8; really stands for is return 3+5;. And it is rather obvious to us that 3 and 5 really are the same numbers which are given as parameters to the sum() function in the test. In other words, the numbers 3 and 5 are duplicated.

To avoid this and remove the duplication, we have to make the function somehow reference the values in the test. In our case, this turns out to be very simple, as they are given to the method as parameters. We refactor the method as follows, and the duplication is gone.

public int sum(int augend, int addend) {
    return augend + addend;
}

Now look and behold. By removing the duplication, we also made the function work as we wanted.

Lets think again about the rhythm of TDD. Since the test passed with our first return 8; implementation, we were at green bar (all tests passed). And when we’ve got a green bar, TDD only allows us to refactor the code, not add new functionality. Now, one can argue that the change made to the implementation (changing 8 to augend + addend) wasn’t a semantics preserving refactoring at all, but rather adding new functionality. To answer this, let’s recap on perhaps the most well known definition of refactoring, namely from Martin Fowlers book Refactoring.

A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.

So, in fact, practically all refactorings change the exact behavior of the code, just not the type we are interested in which is observable behavior. And when we’re talking Test-Driven Development, what you don’t have tests for, you can’t observe. Thus, the modification we made was not changing any observable (i.e. tested) behavior, just untested and therefore invisible behavior.

This might seem to you as either fooling oneself, or as an elegant solution to the problem. I put my vote on the latter.

If a test exercises method a() which in turn calls b(), then both a() and b() are in fact tested. If b() is changed (in an incorrect way) there is a test which will fail. In other words, he was writing the least amount of test code necessary to get full statement coverage. Pretty smart, if you ask me.

I guess there is nothing wrong in doing extensive testing, besides perhaps that the development moves forward more slowly (at least in a short perspective). TDDers like to say, test until fear turns to boredom. So apparently I wasn’t bored enough by writing the tests yet.