Per Lundholm's blog - Responses

Re: The TDD Tetrahedron

Per Lundholm — Fri, 19 Feb 2010 09:24:23 GMT

We are currently working on the problem of producing these in a cost-effective way. Suggestions are welcomed, make it in wood, plastic or paper? Which would be the most cost-effective? When solved, this will be announced here and on the front page of www.crisp.se.

Re: The TDD Tetrahedron

Guðlaugur — Wed, 17 Feb 2010 22:03:16 GMT

Nice idea. How do I get one???

Re: Change Based Configuration Management

Per Lundholm — Sun, 10 Jan 2010 11:13:17 GMT

Very interesting to hear this about Git. I really should get to know Git in these aspects.

Re: Change Based Configuration Management

Otávio Sampaio — Thu, 07 Jan 2010 13:36:20 GMT

I understand your problem. I use to have hard times while using Subversion. Moving our development to git made branching and merging much more painless. The other thing we have done is make sure that bugs or improvement tickets are splited until reach the smallest deliverable size possible. Besides that, all ticket should have their own unit and integration test. So is more easy to keep everything running. All this tools together made development configuration management more easy and straightforward.

Re: Don't let Java ruin your JavaFX

BMWTouring — Fri, 18 Dec 2009 18:37:59 GMT

Great that you are using JavaFX. Do you have a cvs or code source so others can also learn from your experience? Keep it up!

Re: Don't let Java ruin your JavaFX

Per Lundholm — Mon, 07 Dec 2009 06:44:54 GMT

Hey please go on with that great project, may this be mailed to you

Re: Beyond Basic TDD

Minal Nygårds — Fri, 20 Nov 2009 16:07:42 GMT

This post is great and very interesting. I myself have worked with several systems where only small portions of the system have unit tests. This means that noone are certain that the tests are uptodate or reliable. One may not even be aware that the portion of code one is working with actually has existing unittests. I think that each system needs strict rules on how to perceive and work with unit tests. I don't think it is wise to let each programmer decide for themselves. But I also don't think there is a need for unit tests for EVERYTHING. Looking forward to read more comments on your very interesting post.

Re: Not the Fixed Price Contract

Henrik Kniberg — Thu, 15 Oct 2009 07:48:36 GMT

Interesting thoughts!

Re: Design Principles for Error Handling

Mats Henricson — Tue, 13 Oct 2009 16:49:59 GMT

Agree 100%!

Re: Manage versions of your database schema!

Tiziano Mengotti — Tue, 25 Aug 2009 13:48:47 GMT

hi, the very same idea is used in "deltasql" (implemented in php and mysql as a web server), available at http://gpu-grid.net/wiki/index.php/Deltasql Basically, you enter the scripts on the webserver (numbering is done automatically) and the webserver computes for you the needed set of scripts, if you give it the current schema number. bye :-)

Re: The Last on Code Review

Mats Henricson — Mon, 10 Aug 2009 21:00:21 GMT

Amen, brother! I have been thinking about writing the exact same blog entry, but you beat me to the punch! I've been a strong believer in code reviews, and even blogged about it: http://www.jroller.com/matsh/entry/template_for_code_review_guidelines But pair programming is so much better, and so much more fun.

Re: Stable Interfaces - any good?

Minal Nygårds — Thu, 04 Jun 2009 15:09:30 GMT

I agree too. Actually, inside a module - I don't like to see too many interface classes at all. Unless they are meant as interfaces to the module itself.

Re: Stable Interfaces - any good?

Mats Henricson — Wed, 03 Jun 2009 18:25:29 GMT

In Google Reader, when I read about a person that had been in a 1000-person project, my first reaction was "Hm... that's about the size of AXE-N". Hehe.

And you are totally right, of course. That mantra about stable interfaces was obviously true then, 15 years ago. We know better now. Changing API:s are no big deal if done well, especially inside a company.

Re: Requirements Specification is Waste

Richard Kronfält — Tue, 02 Jun 2009 15:27:54 GMT

First of all; yes I am a viking, and I'll be looking forward to that glass of mjöd on some Agile Convention in the near future ;-) And more importantly; I agree with you. Completely. Requirements are waste and we should'nt bother writing them. If we can avoid it. My blog post was on the topic of finding a means of cooperating with a department that is still working according to waterfall. My idea of delivering the requirement specification incrementally is _only_ a workaround for allowing this cooperation cross departments where one is "agile"* and another is not,. * Yes I know, not fully Agile until all parts of the software lifecycle are covered. If it was completely up to me I would immediately put the tester(s) in the same team (cross-functional/-competent teams for the win) and forget about requirements; because you're right, what really defines a system are the test cases; so even the bug reports are waste. I'll continue advocating for this internally here, trust me on that. But until I get my way, I need some path forward. :-) Thanks for your comments and this post!

Re: Mock the Clock

Henrik Larsson — Wed, 20 May 2009 14:06:35 GMT

The clock is a physical resourse like DB, GUI and IPC and need to be mocked when running unit tests. When testing real-time (embedded) SW it is absolute necessary to "mock the clock". For example: If you have a critical limit of 100 milliseconds you want to verify proper behavior for 99, 100 and 101 milliseconds. It is impossible to use the real clock when running these test cases.

Re: Mock the Clock

Mattias Skarin — Thu, 14 May 2009 12:09:38 GMT

Agre, the problem of time (and date) is a reoccuring pattern. For example, in banking systems often two dates exists, "now" and "bankday" where bankday referrs to the bookeeping date.

Re: Mock the Clock

Olle Hallin — Thu, 30 Apr 2009 05:14:20 GMT

A simple, test-friendly design pattern for us fortunate Spring users:

public interface SystemClock {
  Date getDate();
}

@Component
public class SystemClockImpl {
  public Date getDate() {
    return new Date();
  }
}

@Service
public class SomeServiceImpl {

  @Autowired
  private SystemClock systemClock;

  public void someServiceThatNeedsCurrentTime() {
    Date now = systemClock.getDate();
    ...
  }
}

In unit tests, it is simple to mock the SystemClock, making it return whatever your tests require.

Re: Perspective of Retrospective

Tobias Fors — Tue, 28 Apr 2009 07:35:37 GMT

Hi Per! You're quite correct - retrospectives are one thing you don't want to skip if you want to suceed with Scrum. What I told the reporter while being interviewed for this article was basically the same thing you write here: that many teams, unfortunately, choose to not do retrospectives. The opinion that "scrum lacks support for retrospectives" is something that the reporter came up with on his own. Keep up the good work on spreading the use of retrospectives! Svenska läsare hittar lite mer om mina tankar om retrospektiv på min scrumtipsblogg: http://scrumtipsblogg.blogspot.com/search/label/återblicken

Re: Understanding a System

Minal Nygårds — Fri, 03 Apr 2009 19:46:54 GMT

A great post. What you say here is very important and I totally agree with you. If more people argued like you do, then we would have less systems that unesccesary fall into deterioration. A system, should actually become better and better the longer it lives - if it is maintained according to a well thought through architectural design. However, I sadly see too many systems deteriorate - due to the abscence of knowledge of the design intentions of a system. Good post!

Re: A Lean Simulation in JavaFX

Henrik Kniberg — Sun, 22 Mar 2009 08:29:47 GMT

Cool app! A bit confusing interface, I played around with it for a while and I'm still not 100% sure about what is going on. Impressive app though, for just a few hours of hacking. And the whole idea of making lean simulations in this way is inspiring :o)