A quick summary of posts in this series:

1. Throwing Exceptions
2. Using Assertions (this one)
3. Catching Exceptions
4. Logging Exceptions

Guidelines for assertions

An assertion is code that’s used during development that allows a program to check itself as it runs. They are used much in the same spirit as unit tests, but spread out in the actual program code. It is a statement placed to indicate that the developer thinks that some predicate is always true at that place.

Use assertions for conditions that should never occur

Use a barricades to distinguish between assertions and exceptions

Don’t put executable code into assertions.

For highly robust code, assert and then handle the error any way

Assertions in Java

For those unfamiliar with assertions, I’ll give a quick summary. Java provides the keyword assert since version 1.4. It throws a java.lang.AssertionError when it fails, and has the following syntax:

assert expression : "error message shown if expression is false";

Where expression is any boolean expression which should always be true at the point of the assertion. For example, this variable should always be greater than 0, or that collection should always be empty.

To enable assertions when running a program, use the Java VM -ea (or -enableassertions) switch. Assertions are always compiled in, but without this switch, the assertions are ignored by the virtual machine.

Tune in next week for guidelines for catching exceptions! And please do write any comments or questions you might have below.

The series will cover what I think is a good and sound strategy for handling exceptions and errors in your application.

It is written with Java in mind, but is applicable to most languages which feature exceptions.

A quick summary of the coming posts:

1. Throwing Exceptions (this one)
2. Using Assertions
3. Catching Exceptions
4. Logging Exceptions

Let’s get started!

General

First, we’ll go through some things which apply to all types of exceptions.

Always preserve the stack trace

Never use exceptions for flow control

Provide enough context

Next, we’ll discuss checked and unchecked exceptions, and when to use them.

Checked exceptions

A checked exception is a Java concept which means an exception which is specified in a method’s signature. It is a way for the designer to tell the client of a method what might go wrong, so that the client can prepare accordingly.

Throw a checked exception if a method can’t fulfill it’s contract

Make your exceptions part of your contract

Never let implementation-specific exceptions escalate to the higher layers

Unchecked exceptions

Unchecked exceptions are all other exceptions, which are “unforeseen”.

Prefer unchecked exceptions for all programming errors

If the client cannot do anything useful, then make the exception unchecked

Feel free to provide any comments or thoughts below, and check back in a week for the next episode!

I originally intended to just comment that piece, but the sheer amount of comments made me realize that no-one would actually read it anyway. So I might as well write a response in my own blog which about as many will read but which makes me feel better.

I believe the answer is “yes”. I think that a competent programmer needs to be “mathematically inclined”. Not because the average programmer’s typical work includes much math such as applications in 3D, compression, and image manipulation. In those cases it is fairly obvious that a firm grasp of math is required. I believe the answer is “yes” because in my mind “mathematically inclined” also means “good at seeing patterns”, “good at identifying duplication”, “understands basic complexity theory”, or simply “good at groking thinks”. And while a good understanding of math in general is valuable, I think a solid understanding of discrete math and logic is invaluable.

Finally, I liked what the unnamed author mentioned in Jeff’s post wrote enough to reprint it here.

I run a small (4 people) web dev shop and I’m finding that younger coders haven’t had the pleasure of writing assembler or managing without library functions. I’ve always found strong math skills to be one of the most useful skills for coding, and when one has Google and a massive library of functions, one doesn’t have to be good at math to get things working, until it either breaks, has edge cases, or brings out OS or library bugs.

Some quick examples: simplifying tricky equations to determine array indicies or memory offsets; trigonometry to help with physical calculations; mental hex/bin/dec conversion; logic equalities such as DeMorgan’s theorem.

I’m getting frustrated by people I talk to who seem to misunderstand the whole point of agile software development (IMHO).

Different ways of reducing risk

The point with agile, as far as I understand, is to reduce risk and thereby costs by postponing decisions until we have as much information as possible. In older waterfall processes, pretty much everything was decided upfront. That wasn’t because people thought it was so much fun to decide everything up front, but because they believed it to be the best way to reduce risk and cost. Because a bug found just before delivery is much more costly than one found earlier.

Agile, on the other hand, tries to use development practices which enable us to postpone decisions, practices which makes the system easy to change even later in the development process. Thus, the code you write should have two qualities:

• doesn’t force you into making unnecessary decisions, and
• be easy to change.

How to reduce risk the agile way

Quotes such as “You Ain't Gonna Need It” (YAGNI) and “Do The Simplest Thing That Could Possibly Work” (DTST) emphasize the first part — not making premature decisions. But while you can typically find people talking about the second part too, it doesn’t nearly get as much attention in people minds as the first one. Most likely simply because it’s not included in the name, in the mantra. I guess “You Aren’t Gonna Need It, But Do Not Forget To Make Sure Your Code Is Flexible” just doesn’t stick as easily.

Actually ensuring that your code is easy to change requires some work — especially while trying to avoid making premature decisions! It means using things like table driven code and putting abstractions in code an meta-data in configuration. It means thinking about what things are likely to change, and what things are not. It means not assuming too much, since you never know how things are going to be used in the future.

Where many people misunderstand agile

Rules and practices are good, but they are just the means to an end. I find that too many people interpret the agile mantras of YAGNI and DTST too literally. They create solutions which are “simple” and “works” and only includes “what’s needed”.

However, the next day, or next month, when requirements and expectations have changed (as they no doubt will) these solutions prove to be hard to adapt to the new situation. That’s because their developers forgot about the second part, making the system easy to change! And I believe forgetting that is forgetting the very core of what agile is about!

You agree? Got another opinion? How do you ensure you’re code is easy to change?

Låt oss föreställa oss en helt vanlig taxichaufför.

Taxichauffören har taxilicens och en taxibil som är registrerad enligt konstens alla regler. Det enda som utmärker vår taxichaufför är att han har en lite egen twist — han tar alla körningar och ställer inga frågor.

En dag får vår taxichaufför ett uppdrag: Kör till en given adress, vänta med motorn igång och kör därefter till en annan adress. Taxichauffören accepterar. Väl vid den första adressen ser han att det är en bank. Han ser också klart och tydligt hur hans passagerare är inne i banken, hotar personalen och tvingar dem att ge honom pengar. Men vår taxichaufför ställer ju inga frågor så han väntar tills passageraren är klar på banken och kör sedan passageraren till den andra adressen. Körningen är klar och taxichauffören åker hem. Han inser att han just kört en bankrånare till och från ett rån men är okay med det — han själv gör ju inget olagligt. Han kör ju bara taxi.

Efter denna incident återkommer både denna passagerare och andra personer som använder taxichauffören för att köra dem till och från rån, inbrott, stölder och andra brott. Taxichauffören fortsätter köra utan att ställa några frågor. Han får inte någon del av bytet utan tar endast ordinarie taxa. Han är medveten om att hans passagerare begår brott, men sover ändå gott om natten — han själv gör ju inget olagligt. Han kör ju bara taxi.

Vad tycker du om taxichauffören? Gör han något olagligt? Beter han sig omoraliskt? Kommentera och ge din åsikt!

PS. Angående något helt annat, Pirate Bay-rättegången pågår. Vad handlar den om egentligen? Pirate Bay-killarna gör ju inget olagligt. De driver ju bara en webbsajt. (Eller?)

PPS. Skivbolagen behöver tänka om! Stöd Spotify och andra lagliga alternativ och tala om för skivbolagen vad ni vill ha!

PPPS. Detta inlägg är ej avsett för barn, då de ej förstår ironi.

En kollega till mig surfade runt på gp.se och lekte med deras TV-spelare. I adressfältet fick han fick syn på en parameter vid namn insertUrl vilket genast fick honom att fundera.

Phishing

Misstanken var logiskt nog att man då kanske kunde visa inte bara GP-TV genom gp.se utan vilken sida som helst. Denna misstanke visade sig vara helt berättigad. Man kunde alltså få gp.se att visa vilken annan sida som helst inuti en iframe. Och att från en annan sida bryta sig ur en iframe:n är en barnlek. Phishing-attack, ja tack!

Cross-site scripting

Alright, inte snyggt, men det tar inte slut där. Utöver att de blint litar på den URL som användaren skickar in och glatt visar den i sin iframe, så hade GP gjort ett ännu grövre fel. De hade över huvud taget inte validerat sin indata. Detta är ett av de mest grundläggande säkerhetsfel man över huvud taget kan göra på en webbsida. Det ger en elak person möjligheten att köra valfri kod (html/css/javascript/activex etc) när en användare besöker sidan.

Allt anfallaren behöver göra är att få besökarna att klicka på en specialkonstruerad länk till gp.se. Denna typ av attack kallas Cross-site Scripting (XSS) och kan leda till exempelvis stöld av de konton som finns på gp.se, exempelvis administratörer eller annonsörer. Inte bra! Inte det minsta bra!

Kontakt med webmaster

Min kollega valde att kontakta GP:s webmaster och påpeka säkerhetsbristen, så att de skulle kunna åtgärda den. Detta gjorde han igår kväll och idag under förmiddagen fick han ett svar att de nu hade åtgärdat problemet. Dock fanns i svaret inte en tillstymmelse till tack. Det kan man ju tycka att de kunde kostat på sig.

Problemet finns kvar!

Efter en snabb titt på samma sida kunde vi konstatera att förvisso har de nu en kontroll på insertUrl-argumentet för att försäkra sig om att det är en giltig GP-TV-url, men att säkerhetshålet trots detta kvarstod. Det finns nämligen fler parametrar vars värde också sätts rakt in i HTML-koden som skickas ut till användaren. Så de är fortfarande precis lika sårbara för XSS-attacker!

Sammanfattning

Så summa summarum, GP lyckas skapa en sida som inte bara lider av ett stort säkerhetsproblem, utan två! Två problem som är fullständigt grundläggande när det gäller säkerhet på webben. När vi påpekar det för dem svarar de kallt att det är fixat… men problemet kvarstår!

Jag är egentligen inte ett fan av “full disclosure” gällande säkerhetsbrister, men det finns en gräns! När de helt lyckas missa grundläggande säkerhetshål inte bara en gång utan även en andra gång efter att fått information om att hålet existerar, då har de gått över den gränsen!

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.