If you all will pardon me a short interlude of self-indulgence, I'd like to comment on the recent economic troubles, as to how it happened.
In my not so humble opinion, it was brought about by people who did not understand the effects of their tools - they were dazzled by the large sums of money that was available for doing nothing concrete. They saw that they moved billions of dollars from one account to another, and assumed that because they "handled" those sums, they "earned" a percentage of them. It's the same idea that the people who drive the armored cars should be paid a percentage of the sum of money they transport.
I contrast this to the amounts of money that tends to be paid to people who actually make things - cars, shoes, software. We get fixed amounts - hourly wages or yearly salaries. Yet those who do relatively little productive work (how much a any meeting is real decision making, as opposed to posturing and turf-defending?) get bonuses based on the sale of the products of their staff.
Now, I'm a firm believer in capitalism, but I see a great falling away from the respect that those who actually add value, as opposed to handwaving around value.
Unfortunately, this post describes what we as engineers may need to do. As much as we tend to hate power politics, we make need to take one for the team and step up.
(I almost forgot - the title quote is from the series Babylon 5, as I found it here)
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Saturday, July 25, 2009
Thursday, April 30, 2009
Why We Code
Why do we write code?
Not why are we working for Company X, writing accounting software, but why do we write code at home, on our spare time. Why do we do it?
My reasons are as follows, in no particular order:
One of the phrases I used early on in my career is "Writing programs is like sculpting with bubbles"
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Not why are we working for Company X, writing accounting software, but why do we write code at home, on our spare time. Why do we do it?
My reasons are as follows, in no particular order:
- The love of creation - I lack true artistic skills - can't paint, can't draw, can't sculpt. My woodworking is truly bad. But I can create programs that make a computer do all sorts of things.
- The joy of learning. When I have the chance to learn about a new language, or a new library, I have a good time.
- Problem solving. Finding a way around an obstacle and producing a program that solves that problem is just a kick.
One of the phrases I used early on in my career is "Writing programs is like sculpting with bubbles"
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Wednesday, April 29, 2009
They See Me Codin', They Hatin'
I ran across this yesterday.
What load of crap. The whole thing starts by claiming "nerds and programmers" are elitist assholes, then proceeds to show how the other cliques from high school and later life are not as bad, because it's only the "bad" ones that are mean to people - the "good" ones are the real artists/writers/athletes/whatevers.
But all the faults of the few truly antisocial nerds are laid on the backs of all of us.
A few counterpoints:
It claims that nerds take pride in alienation - well, after a decade of teasing (the years leading up to high school), you have to start finding something to hold onto, much like the gay community "taking back" the word queer - if the outside world spurns you, you need to make that a good thing.
It claims that "take one jock and put him in a group of nerds, and he'll start talking to them". Yes, he will, as will a nerd in a group of jocks. But as soon as there are more jocks than nerds, the pack mentality can arise, and the jocks start reverting to the behavior protrayed in the media - they pick on the nerds.
It claims that nerds will reject invitations from popular kids - many will, because they suspect the motives - they are being invited as comic releif, or because a parent insisted that all the class be invited.
It disparages Internet memes like Portal's "The cake is a lie" as elitist and "non-local". That's the beauty of the Internet! It allows the geographically distant to become a community, instead of being stuck with the random draw of physical location.
It takes to task a number of programming communities without noting that most online groups, nerd or not, fall prey to the perils of faceless communication.
All and all, I find the post to be a big sour grapes whine. We nerds are a diverse group, and by virtue of the Internet boom, much of our interests have moved into the mainstream, getting co-opted as "normal". Well, let me hasten to remind everyone - we invented RPGs before MMORPGs, one of us invented the Web, and we're making it better everyday.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
What load of crap. The whole thing starts by claiming "nerds and programmers" are elitist assholes, then proceeds to show how the other cliques from high school and later life are not as bad, because it's only the "bad" ones that are mean to people - the "good" ones are the real artists/writers/athletes/whatevers.
But all the faults of the few truly antisocial nerds are laid on the backs of all of us.
A few counterpoints:
It claims that nerds take pride in alienation - well, after a decade of teasing (the years leading up to high school), you have to start finding something to hold onto, much like the gay community "taking back" the word queer - if the outside world spurns you, you need to make that a good thing.
It claims that "take one jock and put him in a group of nerds, and he'll start talking to them". Yes, he will, as will a nerd in a group of jocks. But as soon as there are more jocks than nerds, the pack mentality can arise, and the jocks start reverting to the behavior protrayed in the media - they pick on the nerds.
It claims that nerds will reject invitations from popular kids - many will, because they suspect the motives - they are being invited as comic releif, or because a parent insisted that all the class be invited.
It disparages Internet memes like Portal's "The cake is a lie" as elitist and "non-local". That's the beauty of the Internet! It allows the geographically distant to become a community, instead of being stuck with the random draw of physical location.
It takes to task a number of programming communities without noting that most online groups, nerd or not, fall prey to the perils of faceless communication.
All and all, I find the post to be a big sour grapes whine. We nerds are a diverse group, and by virtue of the Internet boom, much of our interests have moved into the mainstream, getting co-opted as "normal". Well, let me hasten to remind everyone - we invented RPGs before MMORPGs, one of us invented the Web, and we're making it better everyday.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, April 26, 2009
Two Sides of the Coin
It's always interesting when you find advice on opposing sides of an issue. There's even a wiki page for it (the original wiki).
So I was amused to find this and this, concerning keeping code you like, and keeping code you hate. It's a real issue - sometime you need to get rid of something you think is good, because it's blocking progress - it's a local maximum that's keeping your system from getting to a global maximum. But sometimes you need to toss it all even against the advice of never re-invent the wheel, because the wheel you have sucks.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
So I was amused to find this and this, concerning keeping code you like, and keeping code you hate. It's a real issue - sometime you need to get rid of something you think is good, because it's blocking progress - it's a local maximum that's keeping your system from getting to a global maximum. But sometimes you need to toss it all even against the advice of never re-invent the wheel, because the wheel you have sucks.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, April 19, 2009
Ninja Skills - Estimation
One of the common tasks a developer is asked to do is to estimate the amount of time a particular feature will take to develop. According to the literature, we apparently suck at this. Developers are constantly being told that they cannot make good estimates.
So here's some help.
This post describes a fairly common technique, wherein the developer breaks the task down into units that can be completed in a small number of days (2, in this example). It does not specify if the developer is determining this alone or as part of a group.
Another example of a method is here. This provides a little more process, for those estimating as a group instead of individual developers.
The Ninja Way for estimations is not much different in the inital steps - you determine the size of the overall task, break it into sub tasks that are about the quantum you have found reasonably accurate to guess (typically 1-2 days), and add up those times. Next, look over each step, and ask yourself what could happen that would delay your completion of that step without removing the need to complete that subtask - someone else using the test machine for that release, an overnight build failure, etc. Guess at how long that would take to recover from, and add the longest of those single things into the estimate for that step. For example, if the test machine is in use, how log would it take for you to schedule a break with the current user? (And those who are so 21-century who ask "Why only one test machine? Why manual tests?" - wake up to the fact that not everything is run on a commodity web-server, and not all development organizations have the budget for even one machine per released version of their product.)
This should get you an estimate that will cover the inevitable delays.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
So here's some help.
This post describes a fairly common technique, wherein the developer breaks the task down into units that can be completed in a small number of days (2, in this example). It does not specify if the developer is determining this alone or as part of a group.
Another example of a method is here. This provides a little more process, for those estimating as a group instead of individual developers.
The Ninja Way for estimations is not much different in the inital steps - you determine the size of the overall task, break it into sub tasks that are about the quantum you have found reasonably accurate to guess (typically 1-2 days), and add up those times. Next, look over each step, and ask yourself what could happen that would delay your completion of that step without removing the need to complete that subtask - someone else using the test machine for that release, an overnight build failure, etc. Guess at how long that would take to recover from, and add the longest of those single things into the estimate for that step. For example, if the test machine is in use, how log would it take for you to schedule a break with the current user? (And those who are so 21-century who ask "Why only one test machine? Why manual tests?" - wake up to the fact that not everything is run on a commodity web-server, and not all development organizations have the budget for even one machine per released version of their product.)
This should get you an estimate that will cover the inevitable delays.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Tuesday, April 14, 2009
Anti-Heroism
In an earlier post, I mentioned the bad effects of a culture of heroism. Making a virtue of excessive overtime rewards reactive instead of proactive programming; it cuts into the testing of the product; it erodes morale.
It's a death spiral in most companies; managament stops recognizing the normal limits of work and starts to expect more and more. This is especially likely in companies that do not accurately track developer hours - if the management does not get a complete count of the time spent on development, they will assume it was done in a 40-hour week, and so they think that the next project can be accelerated by getting the developers to work a few more hours.
So when 5'o'clock rolls around, wrap up what you're working on, prep for the next day, and GO HOME.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
It's a death spiral in most companies; managament stops recognizing the normal limits of work and starts to expect more and more. This is especially likely in companies that do not accurately track developer hours - if the management does not get a complete count of the time spent on development, they will assume it was done in a 40-hour week, and so they think that the next project can be accelerated by getting the developers to work a few more hours.
So when 5'o'clock rolls around, wrap up what you're working on, prep for the next day, and GO HOME.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, April 05, 2009
A Followup on Automated Testing
A few posts back I described a blog post I had read about a shop that was stating they did 50-60 live deployments per day.
Here's a post about someone who went and looked at the system being deployed.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Here's a post about someone who went and looked at the system being deployed.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Subscribe to:
Posts (Atom)