Comment by jonahx
12 years ago
Anyone have good before and after examples of Rule 5? That is, a "dumb" data structure with "smart" code refactored to a smart data structure with dumb code?
12 years ago
Anyone have good before and after examples of Rule 5? That is, a "dumb" data structure with "smart" code refactored to a smart data structure with dumb code?
I don't have actual code. But when tutoring CS1 and CS2 students during undergrad, it was common for students to try to implement algorithms in terms of linked lists when they should have been using a tree.
The really persistent students would get things to almost work -- often with hundreds or thousands of lines for something that, with a tree, doesn't take more than 10-50 lines.
This is also an interesting case study in human behavior; the students were typically too impatient to spend 20 minutes thinking about the problem before coding, but could spend 20-30 hours on a single assignment. Odd combination of work ethic and lack of patience...
> the students were typically too impatient to spend 20 minutes thinking about the problem before coding, but could spend 20-30 hours on a single assignment. Odd combination of work ethic and lack of patience...
I wouldn't call it a lack of patience, per se. In most modern models of the brain, exercising executive control to think abstractly ("using System 2") expends energy for as long as you're doing it, and the explanation for many of the brain's inherent shortcuts and biases is to to prevent you from switching into System 2 for longer than absolutely necessary.
I have a feeling that a large part of what is characterized as "intelligence" is simply the brain being willing, for whatever reason, to switch into System 2 "mode" more often, and stay in it for longer.
In case anyone else is wondering, System 1 = autopilot thinking and System 2 = deliberate thinking.
From Thinking, Fast and Slow by Daniel Kahneman
1 reply →
Thanks. I like that example. Do you recall the algorithm they were implementing?
Do you think culture is a factor in this behavior?
This tends to get rewarded in industry as well, hard work, lots of code, must be good.
Well I have, related to databases.
I was the developer of one of the most used app for managing schools in my country (think: scores, grades, students, etc)
In my country, this look like this: (Ugly as hell, but that is not the one I design for the app)
http://www.slideshare.net/wildercondori/planilla-de-califica...
At first, the database was normalized. You have the obvious relations where of students, periods, class/grade, etc... so was a tree.
At the time of editing and printing (this was circa 2000 with FoxPro) things get complicated... fast (was important that editing the scores for each students be very fast).
It was my first serious job, and I'm a self-taught developer, so I don't know back them that my tables were a tree, neither any data-structure apart from the used in Fox.
But one day it hit me: Why I'm doing the tables this way? I see the pice of paper that show how manually a teacher do the scores, and I think: I will do the tables EXACTLY LIKE THIS (ie: As you see in the image above).
Suddenly, everything else get easy. Printing was easy. Editing was fast. Less errors. The app was a hit in part for that "small" change. Look like the competitors never get that idea back them.
I don't have an example of a refactoring, but the git data model [0] is extaordinarily simple, to the point that you can understand what goes on behind the scene on whatever ui you use and stop being mystified, and even extend the data model beyond its primary use [1].
[0] https://schacon.github.io/gitbook/1_the_git_object_model.htm...
[1] https://github.com/bup/bup
My take: poorly designed data models (persistence structures) relying on clever hacks in the program to overcome incorrect ordinality and cardinality rules, data redundancy etc ...
I think he meant an actual code example
Sorry, my bad. Read that hastily. Let me try that again:
Company has Departments with many Employees. One Employee is always a DepartmentHead.
POOR DATA STRUCTURE:
class Department {
}
class Employee {
}
This will require programs to make sure that no more than 1 employee can be a DepartmentHead. For every update to the IsDepartmentHead property of an instance of Employee the program will have to iterate through the list of Employees to flush the switch before assigning the new one.
BETTER DATA STRUCTURE:
class Department {
}
class Employee {
}
This is a much better data structure since you can only ever have one Employee assigned to a Department as a head. The program will of course need to prevent Employees from Departments they don't belong to from becoming Heads of the Departments they are NOT in.