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.
Monthly Archives: September 2006
28
Sep 06
There’s hope…
27
Sep 06
Creating Passionate Users on empowering users
Creating Passionate Users: Ease-of-use should not mean neuter-the-software.
27
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.
26
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.
26
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”);
document.AppendChild(rootNode);
//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();
rootNode.Attributes.Append(nameAttribute);
}
//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();
rootNode.Attributes.Append(creationDateAttribute);
}
//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();
rootNode.Attributes.Append(dueDateAttribute);
}
}
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.
26
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.
19
Sep 06
OpenSource-Software for Customer Relationship Management
SugarCRM.
Interesting. To my (limited knowledge), the closest thing to an open source, vertical business application.
15
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.
15
Sep 06
Statistics
Seth Godin: They didn’t get the memo.
Excellent reminder for all of us working in IT.