This blog has moved. Go to for the latest posts.

Tuesday, September 23, 2008

Apple on unfair claims in advertising

Part of being a cool company is that you respect your customers.
This is not a show of respect by Apple. Seriously, this is just used car salesman tactics. Apple, shape up!

Labels: , , , , , ,

at 22:16 | 0 comments
RSS link

Bookmark and Share

Continuous integration requires a good SCM

Lately I've been discussing SCM (Source Control Management) systems and how that impacts the
continuous integration efforts of the teams and the projects where they work.

I could not have expressed this better than Dean Wampler, check his blog post out.

Labels: , , ,

at 21:28 | 1 comments
RSS link

Bookmark and Share

The hard reality of life as developer...

If any of
this is familiar, then you should really be reading this blog! :)

Hug a developer today.
Blogged with the Flock Browser

Labels: , , , , ,

at 21:10 | 0 comments
RSS link

Bookmark and Share

The cost of un-fixed bugs or Good Code on top of Bad Code

While discussing with a colleague we started talking about the costs related to not fixing a bug
immediately (yes, this does mean that you have a way to immediately figure out if you introduced a bug).

The reason for fixing bugs immediately is not only the cost of content switching later on when you have to come back, but it is even more the cumulative cost of fixing all the code you have built on top of the bug you introduced.

Think about it this way. Bug = Bad code. If you have a bug and continue development you are developing working code (good code) on top of that bug (bad code).

When you later on go back to fix the bad code, you will then have to fix all of the good code that is now broken because of the bug fix you introduced.

Software is build in stacks, the lower level affects directly the upper levels (many of them), if you have a bug lower in the stack and then fix it you will have to change all of the upper levels! And that is where the real cost is.

So, if you find a bug, fix it now. If you did not find a bug, think of ways you could find it faster -- before you build good code on top of bad code.

Labels: , , , , , ,

at 10:55 | 0 comments
RSS link

Bookmark and Share

Monday, September 22, 2008

Testers are developers! Stop breaking them apart

First one clarification. Testing is needed, required, critical and very much a MUST. With that out of the way let's go to the post.

Many people have mentioned the need to include testers in Scrum or agile, and planning your processes with a testing step somewhere (normally close to the end).

All of these ideas are OK. There's nothing wrong with testing, the problem is that testing is done too late. Would you buy a car which engine was "fixed" after it came out of the line and didn't start? -- I certainly wouldn't not!

In software, like in cars, problems should be found early, very early. In fact problems should be found so early that they never reach the (needed) testing phase at the end (of the day preferably). This is why we need to stop thinking about testing as something separate from development or even coding. Testing must be part of every step of the process.

I don't agree with the proposal in
this article. The tester should not be the one developing the test cases in isolation, and certainly not after the team has planned! The reason is that the tester will find faulty assumptions and possible design problems while thinking about the test cases. That information is crucial for the team to avoid building problems into the software.

Testers should be involved from the start. In fact, for each story that the team is planning in the sprint planning meeting, they should at the same time plan the test cases, review the initial assumptions and only after that should they actually plan the tasks to accomplish that story.

The best way to develop quality software is not to test the bugs out, it is to develop quality in -- this is why testers should be involved in every step of the process (Scrum in this example).

As Deming said:
Build quality in, don't inspect quality in.

Oh and by the way, if the test cases are (really) written why would the coder wait for the tester to verify that his code change works? -- Just run the tests immediately! It seems to be that the coder not running the tests herself is just a way to avoid feedback, which is key to Agile!

Labels: , , , , ,

at 02:50 | 0 comments
RSS link

Bookmark and Share

Saturday, September 20, 2008

Learn or else...

Elisabeth Hendrickson I got to Brett Pettichord's post about the role of feedback in Agile.

Read it if you haven't yet.

Here are the pearls that made me post this:

“If you don’t have meaningful feedback then you’re not agile. You’re just in a new form of chaos.”


“Agile practices build a technical and organizational infrastructure to facilitate getting and acting on feedback. If you aren’t going to adapt to feedback, then this infrastructure is waste that will only slow you down.”

This is very much in line (or even the same) with one of the tenants of the TPS (Toyota/Thinking Production System), the PDCA cycle. In order to improve you need to learn, feedback is the fuel for the process of learning. No feedback no learning.

If you are not learning, you are not Agile. No matter what you are doing!

Labels: , , , , , , ,

at 22:27 | 0 comments
RSS link

Bookmark and Share

Tuesday, September 16, 2008

You are not ready for agile if...

This is a post I've been meaning to write for a long time. Who am I kidding, I don't have the time right now, so I'll let Andy do the talking:

You’re not ready for agile if you:

* behave territorially. You mark your territory like an aggressive dog, refusing to share power or information, and let everyone know if you weren’t included in the decision. When something new comes up, avoid it or kill it.
* are inflexible. You’ve got a policy for everything. If it’s not in the book, it doesn’t exist. This is the way we’ve always done it.
* grow uncomfortable with uncertainty. In an agile project, you will not know the project end date or even what features will be delivered in the next iteration. You cannot stand this, and will insist on fixed dates and costs right up front.
* treat developers as a commodity; a uniform, fungible resource. They are all alike. You can’t trust them to think for themselves, you’ve got to make the important decisions for them.
* believe development is a linear process. You ignore unpleasant feedback. Rather than acting on it, you always stick to the plan, just like a politician in an ill-advised military quagmire.

Read the whole post

As Andy says: Agility is a mindset. Call me back when you are willing to change your mind.

Labels: , , , , ,

at 21:14 | 0 comments
RSS link

Bookmark and Share

(c) All rights reserved