I just watched the inauguration and, like many others, I was moved to tears. I've generally been a little skeptical of Obama-mania, but he is the right person for the job, without question. His eloquence, confidence, and humility are truly remarkable.
But I want to comment on how many times I heard the commentators assert amazement at the "peaceful transfer of power" that the inauguration represents. They are astounded that our leaders cede power without violence. But is a violent refusal to yield power even within the realm of possibility? Isn't "peaceful transfer" pretty much standard for most of the world nowadays? England, Canada, El Salvador, etc etc, all see peaceful transfers these days.
In fact, I suspect we are being exposed to a propaganda assertion: "consider yourselves blessed and lucky that these people rule over you peacefully, without infighting." The comradery displayed between these potentially violent adversaries (Clinton and Bush Sr. smiling and hugging, Gore and Bush Jr. sharing a stage) confirms that familiar critique of American two-party politics: these are just two sides of the same coin, a single oligarchical class. Don't mistake me, there are real and profound differences between Republicans and Democrats, and I am very grateful that Obama is president. But everyone on that inauguration stage clearly belongs to the same club.
What else is happening on that stage? The tooting horns, the bunting and banners, the processional entrance -- it's just a good old fashioned pagaent, used by rulers throughout history to impress their majesty and power. The subjects / constituents are always taken right in.
Tuesday, January 20, 2009
Tuesday, August 05, 2008
Lazy software development!
A colleague commented to me once: you want to look in your server room and see your sys admin relaxing -- feet on desk, leafing through a magazine. If he or she appers busy, stressed, or frantic, you know there's a problem.
The good system administrator sets up the network for maximum automation and minimum human intervention -- scripts do the work, not the ass in the seat. If you're a manager, don't feel cheated if the admin works short hours, feel blessed -- you've got a good one.
I propose that the same is true for coders. Good programmers should opt for the easiest, least complex solution to a problem, and then kick back with a magazine. If you manage developers and see them coding late, or see them stressing out, you know there's a problem. If the system is designed for simplicity and ease of development, feature development should be swift and pain-free.
In other words, Keep It Simple and Do not Repeat Yourself, and you can work bankers' hours. There's a nice side benefit, too: the system will be simpler to understand and maintain.
So here, then, is a Lazy Software Developer Manifesto.
Whereas we have worked on many projects and seen many different methodologies: waterfall, agile, and everything in between;
Whereas these project management styles often produce burned-out workers and bad software;
Therefore, we propose Lazy Methodology.
Here are some initial prececpts:
The good system administrator sets up the network for maximum automation and minimum human intervention -- scripts do the work, not the ass in the seat. If you're a manager, don't feel cheated if the admin works short hours, feel blessed -- you've got a good one.
I propose that the same is true for coders. Good programmers should opt for the easiest, least complex solution to a problem, and then kick back with a magazine. If you manage developers and see them coding late, or see them stressing out, you know there's a problem. If the system is designed for simplicity and ease of development, feature development should be swift and pain-free.
In other words, Keep It Simple and Do not Repeat Yourself, and you can work bankers' hours. There's a nice side benefit, too: the system will be simpler to understand and maintain.
So here, then, is a Lazy Software Developer Manifesto.
Whereas we have worked on many projects and seen many different methodologies: waterfall, agile, and everything in between;
Whereas these project management styles often produce burned-out workers and bad software;
Therefore, we propose Lazy Methodology.
Here are some initial prececpts:
- solve problems using the fewest lines of code / configuration
- embrace the old 80/20 rule (focus on your core use cases; skip the outliers that consume huge amounts of time)
- only have meetings when you have a reason to
Subscribe to:
Posts (Atom)