Development Project Archetypes
Trust No One
Physics for Programmers
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Monday, October 26, 2009
A little humor
It's been a busy weekend, so I think a little humor is in order
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Thursday, October 22, 2009
Estimation, or 99.44% Chance of Success
[time warp here - I wrote this in late 2009, but only just noticed it was still just a draft]
We all know the drill. The Requirements have been reviewed, the Customer is on-board, and your manager wants to know how long it will take to make this thing. So you have to provide estimates.
First things first, as we all know, is to break the project down into smaller tasks, and estimate from that. The optimal size of a task to estimate depends on your environment, but it should be a small number of days.
Once you have a number of days, consider the granularity of time allowed you by your bosses and work environment - are you on a Maker schedule or a Manager schedule? If the latter, take that into consideration for any complicated sections of development.
The we get to the art of communicating this estimate to the management, and this post is a good discussion of that.
Finally, make sure that anything that your bosses ask you to do that is not already accounted for in the schedule is noted as a delaying factor.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
We all know the drill. The Requirements have been reviewed, the Customer is on-board, and your manager wants to know how long it will take to make this thing. So you have to provide estimates.
First things first, as we all know, is to break the project down into smaller tasks, and estimate from that. The optimal size of a task to estimate depends on your environment, but it should be a small number of days.
Once you have a number of days, consider the granularity of time allowed you by your bosses and work environment - are you on a Maker schedule or a Manager schedule? If the latter, take that into consideration for any complicated sections of development.
The we get to the art of communicating this estimate to the management, and this post is a good discussion of that.
Finally, make sure that anything that your bosses ask you to do that is not already accounted for in the schedule is noted as a delaying factor.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Wednesday, October 21, 2009
Crawling out of the chaos
Real Life has a way of sneaking up and consuming all of your time, in very amusing ways.
The job has been busy lately, but not in very productive ways. In light of that, here's a little rant on requirements for software. Unfortunately, there's often little the Ninja can do to improve this situation, because Requirements Gathering is often enshrined in the Marketing or Architecture Departments, well away from the developers who have to implement them (And as often well awat from the people who will use the system)
The things that the Ninja must do when Requirements are handed down from On High are:
Anything that is vague, get a clarification in writing - ideally in the documentation, but in an email with several of the developers and requirements authors cc'd.
Also, make sure that the requirements document is versioned, and that you have noted in email which version you are developing to. I have had more than one occasion where the document writer "improved" the requirements and "neglected" to inform development of these changes, which were well-publicized to the customer.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
The job has been busy lately, but not in very productive ways. In light of that, here's a little rant on requirements for software. Unfortunately, there's often little the Ninja can do to improve this situation, because Requirements Gathering is often enshrined in the Marketing or Architecture Departments, well away from the developers who have to implement them (And as often well awat from the people who will use the system)
The things that the Ninja must do when Requirements are handed down from On High are:
- Make sure there are as few conflicting requirements as possible.
- Make sure that each requirement is clear. Performance measured in transactions/second, for example
- Make sure that any external systems have a well-defined API to talk into the system
Anything that is vague, get a clarification in writing - ideally in the documentation, but in an email with several of the developers and requirements authors cc'd.
Also, make sure that the requirements document is versioned, and that you have noted in email which version you are developing to. I have had more than one occasion where the document writer "improved" the requirements and "neglected" to inform development of these changes, which were well-publicized to the customer.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Saturday, July 25, 2009
We are dreamers, shapers, singers, and makers....
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
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
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
Subscribe to:
Posts (Atom)