As I wrote in my earlier entry on heroism, there is a vein of hero-worship in the software industry that runs deep. If I were a psychiatrist, I suspect that it's a side-effect of the geek collective unconsciousness and the usual high-school jocks-vs-geeks rivalry - it's our chance to save the day, instead of just watching some sports person do it.
Over the past few months I've see this topic rise up in the blogosphere, so I will paddle out and ride that wave as far as I can (who says ninja can't surf?)
It could also be that I was just pulled into a half-day of weekend work for no good reason. More on that anon.
Here's one right on point, detailing how heroism hurts an organization. I especially like how it gets related to the customer's viewpoint, something that I tend to dwell less on, being further away than some.
Skorks has this take on it, more in line with my personal view, and making a point of the perverse pride we developers can have in the terrible conditions we sometime work under. He also takes on the converse issue, that of the deprecation of those who get all the work done on time and under budget. This is another one that I ran into personally, where one company was giving out an award and give it 3 months running to the developer who was working late fixing broken stuff, and never once to the developers who got all their stuff done in the 9-5 hours.
And then there is the institutional schizophrenia of places that do not treat the developers like professionals - because, after all, if the programmers aren't here late, they're not really working, right? And if they change their minds about how long it will take, they're just lazy.
But all is not lost - there are signs that at least some of the people in management positions in the industry are seeing the light.
Now, as to my weekend spoiler - it's one of those last items - an artificial deadline, set by a manager based on a preliminary estimate, but set in stone because it was somehow ennobled by the company's scheduling process.
So how does a ninja cope with this?
There are the time-honored suggestions - first, take whatever estimate you can some up with, and double it. Chances are, you are as optimistic as I am, and your guesses as to how quickly you can code something up are forgetting the little things that get in the way - meetings, overnight build failures, field issues that only you can fix, corporate mandatory training, etc. We also tend to think we will get a full 8 hours of coding a day.
Secondly, start tracking your estimates to get an idea of how good you really are, and record how detailed your estimate was, how much external interference you got. If you can get statistics on how little time you can really spend on the code, you can use it as ammunition the next time your manager asks you if you can pull the completion date in a week, because the Senior VP is visiting that week and he;d like to see a demo.
Monday, May 10, 2010
Monday, May 03, 2010
Oh, You Want Loyalty? (or, Mark Suster is an Idiot)
I resisted this for about a week, but having been in the startup/small company scene for a while some years ago, I had to speak up. Mark Suster wrote this piece about how job-hoppers are bad employees, and it's stirred up a lot of dust.
Now, the part that gets my blood boiling is the part about how (supposedly) job-hoppers have shown they are disloyal. And how that is not what you want in a startup employee.
I call bullshit. This is a blatantly pro-management position that expects the employee to be a chattel to the company.
Loyalty means that you will sacrifice some of your benefit to benefit them. For a company, this means giving raises without them asking, when you can. It means keeping them on payroll when there is cash in the company instead of having a layoff because it would make the shareholders happier. It means adjusting their equity to make the IPO sweeter for them.
For a startup that's cash-poor, you've problem in that you can't pay better, and you don't have the buffer cash, or the clout to give them a better benefits package. So what do you do? One thing you don't do is claim that working for you is a privilege. Unless you are betting your entire future on the company, they're taking nearly as big a risk as you working for the startup. If the company fails (as startups are wont to do), will you have to declare backruptcy, sell your house, move in with the in-laws? Because they might have to, if the job market is bad. I had one 3-job year, courtesy of 2 bad sets of management (acquisition of a debt-ridden "asset" in one case, and a VP that got distracted by a new piece of technology when he was needed to justify a budget), and it was not a fun time.
Here and here are some other takes on my side of the issue.
Now, the part that gets my blood boiling is the part about how (supposedly) job-hoppers have shown they are disloyal. And how that is not what you want in a startup employee.
I call bullshit. This is a blatantly pro-management position that expects the employee to be a chattel to the company.
Loyalty means that you will sacrifice some of your benefit to benefit them. For a company, this means giving raises without them asking, when you can. It means keeping them on payroll when there is cash in the company instead of having a layoff because it would make the shareholders happier. It means adjusting their equity to make the IPO sweeter for them.
For a startup that's cash-poor, you've problem in that you can't pay better, and you don't have the buffer cash, or the clout to give them a better benefits package. So what do you do? One thing you don't do is claim that working for you is a privilege. Unless you are betting your entire future on the company, they're taking nearly as big a risk as you working for the startup. If the company fails (as startups are wont to do), will you have to declare backruptcy, sell your house, move in with the in-laws? Because they might have to, if the job market is bad. I had one 3-job year, courtesy of 2 bad sets of management (acquisition of a debt-ridden "asset" in one case, and a VP that got distracted by a new piece of technology when he was needed to justify a budget), and it was not a fun time.
Here and here are some other takes on my side of the issue.
Friday, February 26, 2010
A Digression [Off Topic]
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
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
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
Subscribe to:
Posts (Atom)