Writing better commit messages

If you and your team are in the habit of writing good commit messages, it can save everyone a tremendous amount of time and effort. Other developers can very quickly see what you’ve done. It’ll also save tons of time tracking down commits from the past when you need to find them. A good commit message serves exactly two purposes: it gives other developers an explanation of the commit, and it gives some documentation for future searching.

Read one for some good rules on writing commit messages.

via lbrandy.com » Blog Archive » Writing better commit messages.

Use Threads Correctly = Isolation + Asynchronous Messages

Here are the key things to know about threads:

* Threads are for expressing asynchronous work. The point of being asynchronous is to let the units of independent work in the application all run at their own speeds and better tolerate each other’s latency.

* Threads are a low-level tool. Threads are just „sequential processes that share memory,“ and that kind of freewheeling anything-goes model doesn’t provide any abstraction or guard rails to make good practices easy and bad practices hard. As aptly criticized by Edward Lee in his paper „The Problem with Threads“ [2], threads let you do anything, and do it nondeterministically by default.

* „Up-level“ them by replacing shared data with asynchronous messages. As much as possible, prefer to keep each thread’s data isolated (unshared), and let threads instead communicate via asynchronous messages that pass copies of data. This best practice inherently encourages writing threads that are event-driven message processing loops, which gives inherent structure and synchronization and also improves determinism:

via Dr. Dobb’s | Use Threads Correctly = Isolation + Asynchronous Messages | März 16, 2009.

Don’t Live with Broken Windows

As soon as something is broken—whether it is a bug in the code, a problem with your process, a bad requirement, bad documentation—something you know is just wrong, you really have to stop and address it right then and there. Just fix it. And if you just can’t fix it, put up police tape around it. Nail plywood over it. Make sure everybody knows it is broken, that they shouldn’t trust it, shouldn’t go near it. It is as important to show you are on top of the situation as it is to actually fix the problem. As soon as something is broken and not fixed, it starts spreading a malaise across the team. „Well, that’s broken. Oh I just broke that. Oh well.“

via Don’t Live with Broken Windows.

Orthogonality and the DRY Principle

A helicopter has four main controls: foot pedals, collective pitch lever, cyclic, and throttle. The foot pedals control the tail rotor. With the foot pedals you can counteract the torque of the main blade and, basically, point the nose where you want the helicopter to go. The collective pitch lever, which you hold in your left hand, controls the pitch on the rotor blades. This lets you control the amount of lift the blades generate. The cyclic, which you hold in your right hand, can tip one section of the blade. Move the cyclic, and the helicopter moves in the corresponding direction. The throttle sits at the end of the pitch lever.

It sounds fairly simple. You can use the pedals to point the helicopter where you want it to go. You can use the collective to move up and down. Unfortunately, though, because of the aerodynamics and gyroscopic effects of the blades, all these controls are related. So one small change, such as lowering the collective, causes the helicopter to dip and turn to one side. You have to counteract every change you make with corresponding opposing forces on the other controls. However, by doing that, you introduce more changes to the original control. So you’re constantly dancing on all the controls to keep the helicopter stable.

That’s kind of similar to code. We’ve all worked on systems where you make one small change over here, and another problem pops out over there. So you go over there and fix it, but two more problems pop out somewhere else. You constantly push them back—like that Whack-a-Mole game—and you just never finish. If the system is not orthogonal, if the pieces interact with each other more than necessary, then you’ll always get that kind of distributed bug fixing.

via Orthogonality and the DRY Principle.

Hello world!

Hello world, software developers and architects! I hope, I can provide you some interesting articles and links with this blog. There are some interesting topics in my backlog, but I did not yet estimate them. So let’s wait for the next sprint review to post the results.

Man, too many agile buzz words in my mind… 😉