Comments for Freekshow

Comment on That’s just perfect! by Freek Leemhuis

Freek Leemhuis — Mon, 24 Oct 2011 20:02:18 +0000

Hey Portia,
These are good questions, many thanks for that.
I will not pretend to know all the answers, but I’ll try to explain where I’m coming from.
The responsibilities of an agile coach are dependent on the context of the situation of course. My remark was based on the feeling I sometimes get, especially at agile conferences, that there are few agile coaches that have a solid grasp of the more technical aspects of software development. Agile software development was formed by practitioners, and sometimes I get the feeling that we need practitioners more than we need coaches.
The y-axis was not labeled improvement, because that is precisely my point: if you aim for perfection, you don’t get things done. Aiming for improvement would be fine
And the Kaizen thing – I’m wondering why people use Japanese terms for concepts if there are English equivalents that more people can understand. Or is it just because it sounds more ‘interesting’? Maybe there’s another reason that I’m missing?

Comment on That’s just perfect! by Portia Tung

Portia Tung — Mon, 24 Oct 2011 18:47:32 +0000

Hi Freek,

A thought-provoking entry! It illustrates how something seemingly straightforward in definition such as “Perfection” can mean so many different things to other people.

The entry provokes many more interesting questions. For instance, what are the responsibilities of an Agile Coach? What is the significance of the y-axis being labeled Perfection instead of Improvement? Why is calling Continuous Improvement “Kaizen” pretentious?

Comment on That’s just perfect! by Freek Leemhuis

Freek Leemhuis — Fri, 21 Oct 2011 08:37:02 +0000

hehe, good point, maybe I should have used ‘efficient’ or some such term.
Although I think code in general is resistant to perfect, creating pure functions in functional languages is as close as we will get. Of course, in themselves these have no value, and you have to drag state into into it for them to actually achieve something ‘in the real world’
Thanks for your comment, I found it very usefull

Comment on That’s just perfect! by -Mrcl-

-Mrcl- — Fri, 21 Oct 2011 08:21:31 +0000

Great food for thought as I’m a bit of a perfectionist myself… but why, pray tell, is the lower right part of the graph (x axis – the more functional) marked as ‘suck’?

[making phun] Is that because you dislike LISP and the like? [/making phun]

Comment on Unit Testing in Visual Studio 2008 – part 1 by Freek Leemhuis

Freek Leemhuis — Mon, 28 Mar 2011 08:09:02 +0000

Comment on Unit Testing in Visual Studio 2008 – part 1 by DNN Developers

DNN Developers — Mon, 28 Mar 2011 05:09:09 +0000

Does a tester with no knowledge of vb/C# able to use it?

Comment on Unit Testing in Visual Studio 2008 – part 1 by Ashutosh Singh

Ashutosh Singh — Fri, 04 Feb 2011 11:53:20 +0000

Nice Article

Comment on The scientific method by Premek Brada

Premek Brada — Thu, 16 Dec 2010 10:57:04 +0000

Well, actually there is a thing called “scientific method”; Wikipedia has a decent treatment on http://en.wikipedia.org/wiki/Scientific_method.

One of its particular points (missing in the bald programmer example) is that one is expected to state the assumptions under which the hypothesis should work, in this case e.g. the team characteristics and type of projects. Unstated assumptions can of course radically change the outcomes.

The key is that the whole experiment has to be repeatable by independent investigator, so that it is open to a proof or refute. If the hypothesis, assumptions, and model / experiment design are documented enough, anyone can stand up and show that your conclusion is wrong. It is nothing bad to end with a wrong conclusion, as long as someone else can come up with a correct one. The bad thing with respect to scientific method is to publish only selected parts of the process (“magic happens here”) and call the conclusion “the truth”.

Other than that, thanks for a nice post.

Comment on The scientific method by Jan Willem Tulp

Jan Willem Tulp — Wed, 15 Dec 2010 10:11:19 +0000

Good post! To determine whether you’re dealing just with a correlation or a causation is indeed quite hard, especially if you have so many variables when you’re doing a project (context may also have an impact on the final result). I also think that a good thing of practicing Lean is that you focus on the entire value stream, which is also something that may help. The more detailed your measurements, the more difficult it may be to find causalities. Also, the flow you’re trying to achieve in Lean will also help you to become more predictable.

And also, the shorter your cycles, the more predictable you become. The longer the cycle from initiation to ‘in production’, the more variables you have to deal with, and the harder it becomes to be predictable and find causalities.

Just as you wrote in your post, the essence of using a control group is to remove interfering variables. Using a control group is not always an option in real-life, so finding other ways to remove variables (short cycles, flow, etc.) is a good way to become predictable.

So again, great post, and maybe some causality you didn’t mention is the level of baldness instead of just bold or hairy

Comment on LINQ to SQL problems by SamCPP

SamCPP — Fri, 13 Nov 2009 03:42:50 +0000

“Why are people so fond of stored procedures? In most stored procedures that I review there’s way too much business logic, and no kids, that’s not the right place for it.”
Another point of view is it is the perfect place for it. If you use SPs as the interface to the database, you can guarantee database data integrity. If you run 2 versions of an application and one applies old database relationship rules and the other applies the new, you have database integrity issues. Stored procs are the perfect way of policing the use of the database. And from a security perspective, you can lock the database down at object level.