It 's a bit late but I had some thoughts after watching the finale of "Dollhouse" regarding the nature of identity
I think that if we ever develop downloadable brain scans, we will have a big problem with societal issues that depend on identity, Right now, we can equate personal identity with the physical body - we are, or are in, one body. It is possible for others to influence us, but we are ultimately in control. But if it were possible to download someone else's personality into our brain, we lose that mapping.
Consider how voting is done - we prove our unique identity by proving we are the physical body named in the voting rolls. If that body could contain a different person, the "one man, one vote" assumption fails. While voting is perhaps less susceptible to this kind of fraud (as it's easier to crack the voting machines and fake tallies than to alter individual votes one by one), there are still a number of cases where the unique identity we ascribe to the physical body must be accurate, or we risk much - suppose the President was "replaced" - how would we be able to tell?
And even further out - uploaded minds can be copied at will - how do we vote for things when each side can produce multiple copies of its voters?
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Friday, February 26, 2010
Wednesday, December 16, 2009
Managerial Doublespeak
I'm blogging in anger here, but what is a blog for, but to let one vent one's spleen
I ran into a full-scale manager/architect Charlie-Foxtrot today. My job has the usual lip-service to a software process, with the usual caving to schedule when things are taking longer than Marketing likes.
But yesterday I got both barrels of doublethink from The Powers That Be - On a project that languished for over a year, that has a rapidly approaching deadline, I was asked to write a full design document for a project that I will be doing myself, where I am the most-informed developer for that code. The "justification" was that we are supposed to "follow the process", but the Architects spouting this platitude do not have to struggle with the code.
To add insult to injury, the Architect has specified a number of things as mandatory that are patently bad, but will not believe the developers who know the code when they say this.
I am sick to death of Architects who think that the hard work is writing requirements documents, and that the developers who object to a stupid idea are being lazy.
I am sick to death of Requirements fed to customers without consultation with the developers that can give effort estimates for those tasks. Because the customer manages to choose the options that are hardest to do, while giving the least benefit.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
I ran into a full-scale manager/architect Charlie-Foxtrot today. My job has the usual lip-service to a software process, with the usual caving to schedule when things are taking longer than Marketing likes.
But yesterday I got both barrels of doublethink from The Powers That Be - On a project that languished for over a year, that has a rapidly approaching deadline, I was asked to write a full design document for a project that I will be doing myself, where I am the most-informed developer for that code. The "justification" was that we are supposed to "follow the process", but the Architects spouting this platitude do not have to struggle with the code.
To add insult to injury, the Architect has specified a number of things as mandatory that are patently bad, but will not believe the developers who know the code when they say this.
I am sick to death of Architects who think that the hard work is writing requirements documents, and that the developers who object to a stupid idea are being lazy.
I am sick to death of Requirements fed to customers without consultation with the developers that can give effort estimates for those tasks. Because the customer manages to choose the options that are hardest to do, while giving the least benefit.
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
Development Project Archetypes
Trust No One
Physics for Programmers
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
Subscribe to:
Posts (Atom)