Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.
So the useful question is not “how many hours do you work?” but “how much energy do you put into your work?” Other useful questions that come with it are:
* How much of your daily energy do you spend increasing your total energy? Do you feel you spend enough? Do you feel you spend it on the right things?
* How much of your daily energy do you waste each day? How do you define waste? Is all that waste really unproductive or does it have some beneficial side-effects? Are those side-effects sufficient to justify spending that energy?
* Do you spend energy on things which actively hurt you?
* Has your daily energy increased or decreased in the last 6 months? year? 5 years?
Any of these questions is more worthwhile than “How many hours do you work each day?”
There's a sort of Gresham's Law of trolls: trolls are willing to use a forum with a lot of thoughtful people in it, but thoughtful people aren't willing to use a forum with a lot of trolls in it. Which means that once trolling takes hold, it tends to become the dominant culture. That had already happened to Slashdot and Digg by the time I paid attention to comment threads there, but I watched it happen to Reddit.
News.YC is, among other things, an experiment to see if this fate can be avoided. The sites's guidelines explicitly ask people not to say things they wouldn't say face to face. If someone starts being rude, other users will step in and tell them to stop. And when people seem to be deliberately trolling, we ban them ruthlessly.
To compete with Remi’s post about getting xorg-server 1.5.3 stable in Gentoo, here’s one about getting xorg-server 1.6, which was released today, into testing in the main tree. We’ve been maintaining the 1.6 release candidates in the x11 overlay for a while now. Tonight I added the final release to the overlay. (Update for Google users) What’s new in 1.6, you ask?
- RandR 1.3: Panning, transforms (fixing projector keystones, etc.), primary outputs
- Xinput 1.5, including input device properties
- Predictable pointer acceleration
What’s left before it can move to the main tree? Here’s what I can think of, offhand:
- The new XRandR stuff needs to get released upstream (randrproto, libXrandr, xrandr). Right now we’ve got the xrandr userland tool depending on live git of libXrandr, which won’t work for the main tree. (Update: randrproto and libXrandr 1.3 are out, just waiting on the userland tool xrandr)
- We need to sort out the issue with XCB’s Xlib library renaming forcing recompiles of practically everything. This is becoming more and more of a blocker because now libXext 7.0.5 requires a new libX11. I think giving ourselves a hard blocker on 1.6 from this will help us get it fixed. See bug #248743 to track progress on this. (Update: solution in x11 overlay for testing)
- The server now has a fix to keep looking for HAL if it’s not running when started. Should we change /etc/init.d/xdm to compensate for this change by no longer depending on hald, thus allowing gdm/kdm/etc to start earlier? This will give us one of the steps taken by the fastboot work seen lately in Moblin and elsewhere.
- I think Remi’s going to add xf86-video-intel 2.6.2. (Update: done)
- Our xinit is crazy stale, mainly because we patch it like crazy and I don’t like porting those. I’d like to get it updated to a current release for 1.6. In the longer term, we need to merge distro-neutral parts of our work upstream, but that’s not a 1.6 blocker.
To sum up, you can try xorg-server 1.6 now by adding the x11 overlay with layman, or you can wait for the above issues to get solved, and it will show up soon in testing in your main tree.
I wrote an LWN article called “Google’s Summer of Code: Past and Future.” In it, you’ll learn:
- Why your project should apply to the program
- How big the program is likely to be this year
- A major change for the 2009 session, and
- A pointer to a valuable resource for mentors.
LWN is my favorite source for the best Linux and open-source news. They write original articles and also spend a lot of time searching all over the Internet for all the latest news so that all I have to do is read it. The reader community is fantastic, too. Subscribe to LWN today!
Invariably, groups that had the bad apple would perform worse. And this despite the fact that were people in some groups that were very talented, very smart, very likeable. Felps found that the bad apple’s behavior had a profound effect — groups with bad apples performed 30 to 40 percent worse than other groups. On teams with the bad apple, people would argue and fight, they didn’t share relevant information, they communicated less.
Even worse, other team members began to take on the bad apple’s characteristics. When the bad apple was a jerk, other team members would begin acting like a jerk. When he was a slacker, they began to slack, too. And they wouldn’t act this way just in response to the bad apple. They’d act this way to each other, in sort of a spillover effect.
Three factors must be present for meaningful organizational change to take place. These factors are:
D = Dissatisfaction with the status quo;
V = Vision of what is possible;
F = First, concrete steps that can be taken towards the vision.
R = If any of these factors are missing or weak, then you’re going to get resistance.
It is important for leaders of organizations going through change to realize the ‘lag time’ between where they are in the process and where others in the organizations are in the process.
The higher a leader sits in an organization the more quickly he or she tends to move through the change process. Because they can see the intended destination before others even know the race has begun, senior managers can forget that others will take longer to make the transition: letting go of old ways, moving through the neutral zone, and, finally, making a new beginning.
Our application is due for the Summer of Code in less than a month (see FAQ). The applications will include a few parts that I think are key and that are likely to change from last year’s application:
- Project ideas
- Previous involvement: successes, challenges
- Application template specific to Gentoo
- What we will do to ensure students stick around after the summer
We definitely need a nice big set of project ideas. The rest of them will probably be shorter answers. How do you think we should answer these questions?