Alexander Tarlinder

What’s the alternative to complex branching and pull requests? Trunk-only development drives practices such as testing, incremental development, and branching by abstraction. It also improves communication within the team.

Developers follow a relatively predictable development curve in their early careers. While there will be individual differences, pretty much every developer must pass through the following three stages: The Meta programming stage, the Design pattern stage, and the Functional composition stage. If left unchecked, the code produced during each of these stages may sometimes be quite harmful to a codebase. However, it represents an increase in the developer’s understanding of programming and should be harnessed and explained by more senior peers who know where that particular avenue leads.

What should a struggling software development team do in a world of seemingly infinite improvement options?

Do you feel like your organization’s development process delivers too little at too slow a pace? Your gut feeling is probably correct. In this post, I’ll describe three paradigms that result in near zero or even negative productivity.

You can get a fair feeling for any software system’s quality by putting in just two hours. Here’s how.

If not, you’re in good company. I’ve written a short summary on how to run a productive meeting. It’s not new. It’s not unique. It’s not revolutionary. But sometimes one feels a calling. Thanks Jimmy for helping out with the closure part. Click below to download a printable version.

Last Friday, we had a release party for my book, Developer Testing: Building Quality into Software, here at Crisp. Thanks everyone for coming! Apart from signing books, I did a short presentation and made some announcements. 

I started by talking about the process of writing the book (It’s available on Amazon, Adbris, and Bokus.) It took four years, but I did have some bumps along the road, like two kids :). For those of you who haven’t heard the story, here it goes: Large parts of the concept of developer testing were born during my time at the Swedish Postcode Lottery, where we were a brand new Scrum team working in a regulated industry. Since we had no testers on the team, and probably even more important, no traditions and rituals to adhere to, we self organised into automating all checking: at unit, integration, and end-to-end level to such a degree that we were confident about releasing, pretty much always.

Continue reading

In this talk I presented a simple 2D platformer written in Java/Groovy and how to use Spock to test it. I’ll make the source code available in a while. By the way, of you’re not using Spock yet, then start!

One property of legacy code is inflation by irrelevant logging statements. Not only does this increase the size of a bulging code base, I’d also argue that it’s dead wrong.

Quite recently I’ve had the honor of making acquaintance with a piece of code that looked roughly like this:

if (LOGGER.isLoggable(Level.FINEST)) {
    LOGGER.log(Level.FINEST, "foo is now", foo.getValue());
}
boolean result = doSomeActualWork(foo);
if (LOGGER.isLoggable(Level.FINER)) {
    LOGGER.exiting(this.getClass().getName(), "bar", result);
}

Continue reading

I talked about some overlooked (and quite new) features of JUnit at JDays in Gotherburg. My presentation was a tour that started with boring example tests, and then proceeded through parameterized tests, theory tests, and generative testing. At the end of this tour, I spoke about fundamental, yet again overlooked, testing techniques such as finding

In this series of articles, I’ll be discussing the developer profession from different angles. The common denominator is that all articles will, in one way or another, be about professionalism. This first article is about the different factors and decisions behind every single line of code.

A while ago I spoke to a friend who is pretty much a professional singer. He explained singing to me in a very passionate way, saying that singing is like solving multiple parallel equations in real time. He told me that it’s quite obvious that every singer has to follow notes. What’s less obvious is that the singer also takes a multitude of micro decisions during every second of his/hers singing. He told me about tempo, intensity, interpretation of the composer, matching the expectations of the audience, synchronization with other singers, following the Kapellmeister, and a bunch of other factors. I was quite impressed.

A second later it struck me that this goes for programming as well, and I started to list all the equations a developer must solve while writing a single line of code. Here it is!

Continue reading

Idag fick jag gästa SweNug och prata om testbarhet för utvecklare. Presentationen finns på Slideshare.

Continue reading

Tidigare kollade jag om det fanns intresse att hälsa på hos oss på Crisp och utbyta erfarenheter kring TDD. Efter att ett flertal hade visat intresse har vi nu schemalagt eventet till den 6:e maj. Anmälan är öppen! Ni som visade intresse genom att kommentera det första blogginlägget ombedes att anmäla er via eventets sida.

Om det känns lockande att fördjupa sig inom olika varianter och vinklingar av TDD, säg till, så ordnar vi ett TDD-kvällsevent här på Crisp.

Continue reading

Igår hade jag äran att få gästa SAST Stockholm Q4, där jag fick hålla en presentation om utvecklartestning. Med handen på hjärtat, så blev det lite mycket information på få tidsenheter ibland. Dock brinner jag verkligen för ämnet och vill säga så mycket jag kan. Efter att ha checkat runt lite, gläds jag åt att

Sometimes a continuous integration/delivery scenario is more complex than just building a system in a multi-stage pipeline. The system may consist of several subsystems, or just complex components, each of which requires a build pipeline of their own. Once all systems pass through their respective build pipelines they are integrated together and subjected to a joint deployment and further testing. When facing such a scenario, I decided to build the simplest possible thing that would work and get the job done.

Continue reading

What will software development be like in the future? “Agile” as we know it, will not be around, nor will test-driven development, continuous delivery, or BDD-like methodologies. I’ve been pondering this for a while, and based on some observations and a dose of wishful thinking, I’ve arrived at the conclusion above. Do you agree?

Continue reading

After having worked with various legacy codebases one discovers certain recurring traits and patterns. The topic of today is the Custom Exception Hierarchy encountered in Java legacy code. This phenomenon is rather Java-specific because of that language’s checked exceptions.

So what is a Custom Exception Hierarchy? It’s an exception hierarchy, with some strangely named exception at its root, present throughout the entire codebase and used everywhere. The author(s) of such hierarchy obviously felt that exceptions like IllegalStateException or IllegalArgumentException, or the like weren’t sufficient for the sophisticated needs of their application, so they came up with a better suited hierarchy of checked exceptions.

Continue reading

A while ago I was asked to become one of the Swedish country ambassadors for the Agile Testing Days 2012 conference. I said yes, because I think it’s a great conference. As country ambassador, I help in promoting the conference. I chose to do it, because I think it’s a good conference and I already recommend it to my friends.
Continue reading

Jag har precis lagt upp min första kurs här på Crisp – Testning av webbapplikationer med Selenium WebDriver. I detta blogginlägg tänkte jag förklara lite mer ingående vad kursen är tänkt att lära ut. Mina kolleger har också kommit med värdefull feedback och frågor som säkert kan dyka upp igen.
Continue reading

I gave a presentation called ”Being good at waiting – Using Selenium to test Ajax-intensive pages” in an unconf session at the Selenium Conference in London.

The audience was great! Thanks everybody! I certainly didn’t know everything there’s to know about the subject, and that resulted in an interactive session where people from the audience would share their experience and answer some questions. That was so cool 🙂
Continue reading

Surprisingly often an organization exposes itself to a multitude of risks by not knowing enough about its systems, infrastructure, and applications. This doesn’t manifest itself as a lack of “enterprise architecture” documents (while some could help). The implications are far more down-to-earth. Does any of this sound familiar?

• Upgrading both hardware and software is unproportionally difficult and the outcome isn’t predictable
• There exist tasks that must be performed by a specific person
• There exist artifacts that everybody thinks need to be there, but no one dares to touch, delete, or upgrade
• Introduction of new employees is difficult

Continue reading

I had a conversation with some of my colleagues about what makes a good daily stand-up, here are some properties: Time-boxed (15 minutes) Everyone is engaged Synchronization is taking place Attention to problems People ask for help The conversation is about stuff that matters to most people, individual issues are postponed Anyone can lead the

As developers feel the daily pressure to deliver, they tend to skip a crucial step in the process: learning and understanding the system. There’s a huge difference between just adding more lines of code to the codebase and making changes that maintain the conceptual integrity of the system.

Horizontal development is the result of not spending enough time learning and understanding the system you’re working on. By starting to churn out code too soon, you’ll inevitably be adding silos of functionality in parallel to existing functionality.

The outcome is legacy code. It doesn’t matter how well factored it is, and what test coverage it has!

Continue reading

What’s testability? And why does object-oriented code feel more testable? In this post I argue, somewhat informally, that making code object-oriented, or just by introducing more accurate abstractions, we decrease the domain-to-range ratio, thus making our code more testable.