Kent Beck on Software Engineering Radio

I just listened two different podcasts, an interview of Kent Beck at Software Engineering Radio and episode 1.0.3: Problems on "This Developer's Life". Few points which stuck into my mind while listening:

First on SE-Radio
- Scope of tests is something you have to decide yourself. TDD is not about unit testing. This means that you have to think about on what level you should write your tests. They can be acceptance tests, integration tests, unit tests or something else.

- Every test has costs and benefits. Costs are usually short term, and biggest benefits come on long term. So if you're doing some explorative coding, tests are not something you must write, because you might throw that code away before you can reap the benefits. But you've got to bite the bullet at some point, if you continue to use that code. So Beck isn't zealot on TDD.

-Software development is moving towards continuos deployment, and testability will become more and more important. Automated testing will become comparable to compiler, it'll give you feedback immediately.

On Problems episode, best quote was something like "Not all bugs need to be resolved". This meant that some bugs are in completely unnecessary features, so you'd be better if you threw away that troublesome feature.

Overall, both podcasts were great.

Engineering management at Facebook

Yishan Wong has written a great article about engineering management at Facebook. You can read it at http://algeri-wong.com/yishan/engineering-management.html.

Some quick thoughts about some of the major points

1. Hiring is number one
I couldn't agree more. This is one point which has come up on http://manager-tools.com/ podcasts. They say pretty much the same thing: every manager should constantly look for new hires in his/hers networks. One reasons is that you don't want to be in situation where you have to hire someone, which can happen when you get a new project. That forces you to just get best one from the available candidates, whether he/she is good enough. But just like Voltaire said, "The perfect is the enemy of the good".

2. Let process be implemented by those who practice it
In Toyota Production System this is called "standardized work". But standardized doesn't mean standard. The process is constantly improved by its users, and standardization is used mainly for metrics (http://en.wikipedia.org/wiki/Takt_time). It's funny how written word becomes a word of god so easily.

3. Promotion from within
One thing missing here is how external recruiting can effect to motivation. If there's a motivated and ambitious person in organization and he/she would like to move forward on his career, it's a pretty big hit to his/hers motivation if someone from outside gets that job he/she would've wanted.

Use normal class as message receiver in Scala

I constantly encounter the following problem when writing Scala.

If you want to use normal class as receiver for messages, you have to remember to import Actor._. Otherwise compiler will complain:


error: not found: value self

Following should print "Success"

import actors.Actor
import actors.Actor._
class Example {
case class Message(sender: Actor)
val receiver = actor {
  react {
    case Message(s: Actor) => sender ! true; exit();
  }
}

receiver ! Message(self)

self.receiveWithin(100) {
  case true => println("Success")
  case false => println("Failure")
}
}


I've been using this kind of "pattern" when testing message based communication between objects. It seems to be working pretty well, but tweaking of that timeout is important.

MySQL changes foreign key names

Just spent few hours debugging database conversion scripts, and bumped into a "little" bug in MySQL.


CREATE TABLE `test1`(
`id` integer NOT NULL,
PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;


CREATE TABLE `test2` (
`id` integer NOT NULL,
`id2` integer DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `IX_test_1` (`id`),
CONSTRAINT `FK_1` FOREIGN KEY (`id2`) REFERENCES `test1` (`id`) ) ENGINE=INNODB DEFAULT CHARSET=latin1;


INSERT INTO test2 (id, id2) VALUES (1, 44);
ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails (`test`.`test2`, CONSTRAINT `FK_1` FOREIGN KEY (`id2`) REFERENCES `test1` (`id`))


ALTER TABLE test2 DROP FOREIGN KEY `FK_1`;
ALTER TABLE test2 ADD FOREIGN KEY `FK_1` (`id2`) REFERENCES `test1` (`id`);


INSERT INTO test2 (id, id2) VALUES (1, 44);
ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails (`test`.`test2`, CONSTRAINT `test2_ibfk_1` FOREIGN KEY (`id2`) REFERENCES `test1` (`id`))

Somehow foreign key named FK_1 changed into test2_ibfk_1..