Sep 06

There’s hope…

Looks like there’s a silver lining on the horizon for those of us who turned 40:
It’s not too late to be a genius.

Sep 06

Creating Passionate Users on empowering users

Creating Passionate Users: Ease-of-use should not mean neuter-the-software.

Sep 06

When Understanding means Refactoring

Jeff Atwood on When Understanding means Rewriting:

“It’s not that developers want to rewrite everything; it’s that very few developers are smart enough to understand code without rewriting it. And as much as I believe in the virtue of reading code, I’m convinced that the only way to get better at writing code is to write code. Lots of it. Good, bad, and everything in between. Nobody wants developers to reinvent the wheel (again), but reading about how a wheel works is a poor substitute for the experience of driving around on a few wheels of your own creation.”

When I try to understand a given piece code (most embarrassing, my own code written a few months ago), reading the code doesn’t cut it. Instead I try to nibble around on the edges, working from the inside out:
* Looks like the one who wrote the code was short on vowels & consonants for variables – Let’s try to change that – Ah, it still compiles. Cool.
* There are these two lines of code I understand – How about making that a method
* Looks like there’s a comment describing what’s done – Maybe I should try to extract a method
* There’s a certain piece of code used over and over again, maybe I can try to extract that?
* Is this method called from other places too? What do these other places feed in there as parameters?
* There’s this weird global (singleton) there, why is it needed? Let’s change its name. Ah, the compiler tells me where it’s used elsewhere in the system
* Stepping through the code in the debugger, I get a picture of the state of variables
* …
With every tiny step, I gain understanding. Little by little. After understanding this one method, I’m in better shape to understand the next one – Or even the object the method belongs to. Now I apply similar tiny baby steps to classes.
My suggestion is to refactor in order to understand the code instead of rewriting it.
Yup, backing up these refactorings with unit tests is a great idea – but I can still back out from fiddling around with the code without the tests, start the refactorings from scratch, with unit tests – but with some increased knowledge about the system.

Sep 06

Niklaus Wirth books

Chris Hanson notes that some of Niklaus Wirth’s books are available online (for free).
If you want to read one (very approachable) book on compiler construction, read Compiler Construction by Niklaus Wirth. Excellent stuff.

Sep 06

Comment Smell

Here’s some code from the rather interesting blog “Extreme Programming – Simulating an XP project“:
public string SaveToXml()
XmlDocument document = new XmlDocument();
//Create a root node called task
XmlElement rootNode = document.CreateElement(“Task”);
//If the name exists, store this information
if (this.Attributes.Contains(“Name”))
//Append the name information as an attribute
XmlAttribute nameAttribute = document.CreateAttribute(“Name”);
nameAttribute.InnerText = this.Attributes[“Name”].ToString();
//If the creation date exists, store this information
if (this.Attributes.Contains(“CreationDate”))
//Append the creation date information as an attribute
XmlAttribute creationDateAttribute = document.CreateAttribute(“CreationDate”);
creationDateAttribute.InnerText = this.Attributes[“CreationDate”].ToString();
//If the due date exists, store this information
if (this.Attributes.Contains(“DueDate”))
//Append the due date information as an attribute
XmlAttribute dueDateAttribute = document.CreateAttribute(“DueDate”);
dueDateAttribute.InnerText = this.Attributes[“DueDate”].ToString();
It’s a rather typical example for a “Comment smell”:
* The comments are not needed because the code communicates very clearly what is done (even to someone like me who’s not an XML-Guru at all)
* If the comments are not needed, we should get rid of them because they pollute the code plus they will get out of sync with the code in the long term (Can you say “Cut/Copy/Paste”? ­čÖé
Plus, the comments are hints on potential refactorings like extract method.

Sep 06

Excellent Blog on Testing

Michael Hunter is doing a great job with his blog: THE BOOK OF TESTING – Thoughts From a Braidy Tester.
This is required reading for everybody involved with software testing.
I have setup (and will maintain ­čÖé an RSS feed for all entries in the “You are not done yet” category of this blog.

Sep 06

OpenSource-Software for Customer Relationship Management

Interesting. To my (limited knowledge), the closest thing to an open source, vertical business application.

Sep 06

Removing duplication

Ivan on Programming in the small – removing duplication:

“Look out for duplication – it might be telling you something”

Interesting observation: Removing duplication isn’t about removing redundancy only, it’s about migrating towards a better, more object-oriented design, too.

Sep 06


Seth Godin: They didn’t get the memo.
Excellent reminder for all of us working in IT.

Sep 06

Napping Software

Seriously: pzizz™.
(Via 43 folders.)