New stuff happening in tech

OpenBSD 4.2 is nearing release, this is my favorite firewall OS (I've been running it for more years than I can think back, maybe since 2000).  I'm considering trying to run X again as a desktop machine to see how far things have come since the last time I attempted it... and gave up in disgust.

LOLCode.net.  Words cannot describe the sheer awesomeosity.

Evidence Based Scheduling from Joel.  It will be hard for me to break down all the assorted reasons why I love this post/idea/tech, but no time like the present to start...

1. He builds the theory based on a number of practices that have already proven themselves to me in the past, such as breaking it down to very low granularity chunks (16 hours or less is a reasonable amount to me) and making cuts early based on cost/benefit.
2. Future predictions based on past performance?  Gee, that sounds awfully reasonable.
3. Including all the random interruptions/organizational overhead in the task length.  This is pure genius, by rolling all the non-task time into the tasks themselves you end up fully costing day to day activities into the end deliverables.  A number of times during his post I had moments of clarity, the kind where someone proposes something that simplifies things so perfectly that you begin kicking yourself for not thinking of it ages ago.
4. In the same way, adding bug fix time for a task into the task cost itself.  This means you're scheduling the time it takes to actually get the product ready for customers/users, not to some artificial milestone that only exists to try to get people 'motivated'.  Developer's goals are now to deliver shipping quality code as fast as they can, not to get something kind of working in time for the bug fixing period of the schedule.  You're not measuring the time to code, you're measuring time to code, debug, fix, integrate, and stabilize.
5. The focus is on getting the product done, at shipping quality with the highest value functionality.  This means that the product team's goals are aligning perfectly with the business goals, which is often not the case with current scheduling techniques.

While we're talking about Joel, I'll also point you to his excellent article in Inc. Magazine about how to fail at making software.  The two I want to draw particular attention to are #3 (negotiate the deadline) and #5 (Work till midnight).

These often go hand in hand, because when #3 inevitably fails management often asks for or rewards #5.  Whether the deadline is artificial because of "business needs" or as an attempt to get more productivity from the developers than they'd naturally do without feeling deadline pressure, it just doesn't work.  People meet deadlines with horrible quality, just miss it completely, or game the system to take advantage of the panic without solving the underlying problems.

Sadly, the mistakes are often repeated like clockwork within the same organizations.

Comments

[Hal]

I'd say it's pretty easy to use X on OpenBSD, and has been since at least 2.9, which is when I first started using it.

Provided you're not one of the whiners crying about no accelerated three dee, and are fine with reading the FAQ and man pages, it's pretty smooth sailing.