It seems that only a rant-worthy topic can stir me to blog these days, for which I apologize.
However, I just had an experience with a practice that I cannot fathom, and I had to rant about it.
I was looking over some code for another part of The Job's product, in preparation for implementing a similar thing in code I am responsible for. The initial set of changes were relatively clear, and had been done by a local colleague. Then it appears that there was a second set of changes made by another programmer that were less clear. The second set was a bit more sweeping, and were done by a supposedly mid-senior developer. There were no comments in the code that had been changed. Wait, I was wrong - there were comments - every if/then and while block had the closing brace commented with "// end if" or "// end while" - EVEN THOSE IN FUNCTIONS ONLY 5 LINES LONG!!!!!
I remember when I was in college taking a FORTRAN class, we were told to comment heavily, and the ends of sections were required to have such comments, but we also had to have block comments before every major section of code. How did this get mutated into commenting only the ends of blocks? No comments about the intent of the block, the actions in the block, nothing. Just the little end markers for the blocks, cluttering up the diff report.
The part that scares me is that this was also allegedly reviewed by the offshore manager, and passed without comment (or any comment was ignored). What the hell is being taught as programming practices these days?!
I'd have preferred no comments at all to those useless bookends.
Saturday, October 16, 2010
Tuesday, September 07, 2010
Old Age and Treachery....
...beats Youth and Skill any day....
So goes an old saying that I like to repeat when one of the young guns at The Job starts ragging on us older programmers.
The key thing is that there is a great deal of accumulated knowledge that good programmers can use that just can't be taught. There are patterns in bug behavior that you learn to recognize, weird interactions that only happen once every decade (or longer), and paradigms that cycle around with Halley's Comet to crash systems - and it's damned hard to teach such things, both in what to look for, and how to generalize them.
That's not to say that young programmers are bad - they've got energy, enthusiasm, and just as much a chance to be truly smart as us codgers. And the lack of experience can lead to pushing an idea hard enough to make it a success (Twitter, anyone?) But most times reinventing the wheel is just wasted effort.
So as I scan the Web for interesting things to blog about, I run across three articles about the cultural differences in two other countries (vis-a-vis the USA): India and Japan
First, India: This one notes that in India, there is very much a belief that programming is the lowest rung of the corporate ladder, and that one's career will advance away from programming. This other one notes that there is also a very strong cultural pressure to rise in a company to achieve "success" within 5 years of starting formal work, in order to marry well.
Similarly, this article notes that Japan has a similar, if somewhat less severe problem, forcing its programmers into management after 13 years, although it hints that there is enough of a vein of monastic dedication that may give the truly determined programmers a chance to excel, at the cost of renumeration.
Now all this makes me look askance at outsourcing to such places - if the developers you get in India are, for the most part, novices, how are they going to learn the experiential things? They aren't experienced enough themselves, and there are no experienced programmers in their companies to teach them, should they be aware of the need. And if your outsourcing company is fortunate enough to be able to keep individuals on staff long-term (instead of them going elsewhere for better salaries), you still will lose them as a developer in five years!
I can't speak for anyone else, but I know that I've learned a great deal in the years since I hit 27 - I'm better at finding abstractions, much better at determining the cause of a bug, and much more likely to put logic in the data instead of the code. I know that my code will need to be refactored, but also that I'll need tests to be sure I don't miss a detail in the rewrite. I also know that any code that has been in production for years probably has dozens of special cases that make it hard to use the obvious abstractions, so I'd better look at it from the bottom-up as well as top-down.
So goes an old saying that I like to repeat when one of the young guns at The Job starts ragging on us older programmers.
The key thing is that there is a great deal of accumulated knowledge that good programmers can use that just can't be taught. There are patterns in bug behavior that you learn to recognize, weird interactions that only happen once every decade (or longer), and paradigms that cycle around with Halley's Comet to crash systems - and it's damned hard to teach such things, both in what to look for, and how to generalize them.
That's not to say that young programmers are bad - they've got energy, enthusiasm, and just as much a chance to be truly smart as us codgers. And the lack of experience can lead to pushing an idea hard enough to make it a success (Twitter, anyone?) But most times reinventing the wheel is just wasted effort.
So as I scan the Web for interesting things to blog about, I run across three articles about the cultural differences in two other countries (vis-a-vis the USA): India and Japan
First, India: This one notes that in India, there is very much a belief that programming is the lowest rung of the corporate ladder, and that one's career will advance away from programming. This other one notes that there is also a very strong cultural pressure to rise in a company to achieve "success" within 5 years of starting formal work, in order to marry well.
Similarly, this article notes that Japan has a similar, if somewhat less severe problem, forcing its programmers into management after 13 years, although it hints that there is enough of a vein of monastic dedication that may give the truly determined programmers a chance to excel, at the cost of renumeration.
Now all this makes me look askance at outsourcing to such places - if the developers you get in India are, for the most part, novices, how are they going to learn the experiential things? They aren't experienced enough themselves, and there are no experienced programmers in their companies to teach them, should they be aware of the need. And if your outsourcing company is fortunate enough to be able to keep individuals on staff long-term (instead of them going elsewhere for better salaries), you still will lose them as a developer in five years!
I can't speak for anyone else, but I know that I've learned a great deal in the years since I hit 27 - I'm better at finding abstractions, much better at determining the cause of a bug, and much more likely to put logic in the data instead of the code. I know that my code will need to be refactored, but also that I'll need tests to be sure I don't miss a detail in the rewrite. I also know that any code that has been in production for years probably has dozens of special cases that make it hard to use the obvious abstractions, so I'd better look at it from the bottom-up as well as top-down.
Monday, August 23, 2010
Explaining Technical Debt to Managers
I've written about technical debt already, but this is a good take on how to explain why it's necessary to clean up code to your managers.
The big problem is that managers are (usually) one-step removed from the code work, so they don't see the messy code, the compromised design, or the bubble-sort you used to get the last release out on time. So they don't see the roadblocks to adding new features very well.
And program/project managers are even further out of the loop on this - all they see is a UI and a list of features. They rarely have any idea that a working program could have crappy code in it - if it works it must be perfect, right?
So anything that makes it easier to explain why working code needs to be changed is a good thing. The best things are the metaphors that allow us to relate software refactoring to something the average manager can understand.
The big problem is that managers are (usually) one-step removed from the code work, so they don't see the messy code, the compromised design, or the bubble-sort you used to get the last release out on time. So they don't see the roadblocks to adding new features very well.
And program/project managers are even further out of the loop on this - all they see is a UI and a list of features. They rarely have any idea that a working program could have crappy code in it - if it works it must be perfect, right?
So anything that makes it easier to explain why working code needs to be changed is a good thing. The best things are the metaphors that allow us to relate software refactoring to something the average manager can understand.
Thursday, July 08, 2010
More on Estimation (+/- 10%)
The first thing to do when asked for an estimate is to recognize it. Sometimes your boss comes to you with a question that carries a hidden agenda. Spotting these leading questions is usually not hard, because they tend to be asked by your boss when s/he appears at your door unannounced, with a nervous smile, and asks something that seems curiously specific.
The second thing to do is make sure that once you know why they are asking, that you know how big the thing is. This may entail some time educating the questioner about all the real details so you can give an estimate that at least is about the thing they think they want.
Next, you need to break down the job into smaller tasks. From experience, I think that nothing is smaller than a day, and you cannot accurately estimate anything longer than 5 days. So start breaking the task down into discrete sub-tasks until everything is in the 1-5 day range.
Now, you may be objecting that there are some things that take almost no time to do, and you could do 5, 10, maybe 15 of them in one day, cutting your estimate significantly. Perhaps you can do a number of the things in the same day, but there are always unforeseen complications in any workplace that will make things drag out, so the 3 tasks that were going to take one day end up taking 2 because you had to add a new accessor method to a library class and add the tests for it, and the build process did not pull in the correct version, or you had to merge someone else's changes in before you added your stuff, etc. Leave that padding in.
Now that you have a detailed, 1-5 day breakdown of the task, spend a little time looking at the amount of time you think this will take, and consider the other things going on across that time. Does it fall across Christmas, when nearly everyone will be taking time off at the same time, so you won't be able to get in touch with anyone if you're in the office working? How about summer vacation, where someone important might be totally unreachable for 2 weeks? Or does it straddle the big release of the current product, which will result in a lot of field issues? Use this info to estimate how much of your day will be spent a) dealing with these other issues, and b) being interrupted. Having to spend 2 weeks digging through a month's worth of log files looking for a root cause will cut your progress to a snail's pace, as will having to attend twice-daily status updates. Remember, it can take up to 15 minutes to regain mental context after an interruption.
Finally, take the number you have, adjusted for expected interruptions, and add a fudge factor of 30% (initially). This will give you a reasonable starting point, with some room for pulling things in (as all bosses are wont to do), but without the congenital optimism we developers seem to have.
(And another suggestion from www.codesqueeze.com might be useful, if you boss doesn't have the hearing difficulty that cuts off the upper bound of a range)
Of course, there is always the method I read about early in my career - take your initial estimate, multiply by 2, add 5, then convert to the next highest time unit)
Tuesday, June 29, 2010
A New Look
Blogger added the new template editor a while back, and I finally got the time and inclination to make a few changes.
Comments on the look cheerfully accepted!
Comments on the look cheerfully accepted!
Wednesday, May 19, 2010
It's Not What It Looks Like......
This got a chuckle out of me yesterday, both for the content and for the (apparent) applicability to myself.
The point of the article is valid - the people who do the hiring in most companies are also the least likely to be able to distinguish the wheat from the chaff, so the development teams have to come up with some other way to get the good people interviewed.
But the comments against it seem equally valid - putting some cool non-corporate (for now) title in the job description glorifies the superficial aspects of our profession (and elicits stories of the good ol' Dot-Com boom), and sets into motion another round of the euphemism treadmill, where "hacker" has been replaced by "guru" has been replaced by "rockstar" et cetera, ad nauseum, and the wannabees will eventually fill in all the spaces, and we will be calling the best programmers something else.
It also trivializes us - making us look far to concerned with what we are called instead of what we do.
So let's all be programmers again, mkay?
And for the record - Ninja Software Development is not about "l33t n1nj4 skillz", but about working to develop better software disguised as an otherwise undistinguished programmer, even if the company doesn't want to let you make good software.
The point of the article is valid - the people who do the hiring in most companies are also the least likely to be able to distinguish the wheat from the chaff, so the development teams have to come up with some other way to get the good people interviewed.
But the comments against it seem equally valid - putting some cool non-corporate (for now) title in the job description glorifies the superficial aspects of our profession (and elicits stories of the good ol' Dot-Com boom), and sets into motion another round of the euphemism treadmill, where "hacker" has been replaced by "guru" has been replaced by "rockstar" et cetera, ad nauseum, and the wannabees will eventually fill in all the spaces, and we will be calling the best programmers something else.
It also trivializes us - making us look far to concerned with what we are called instead of what we do.
So let's all be programmers again, mkay?
And for the record - Ninja Software Development is not about "l33t n1nj4 skillz", but about working to develop better software disguised as an otherwise undistinguished programmer, even if the company doesn't want to let you make good software.
Monday, May 10, 2010
The Only Good Hero is a Sandwich
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.
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 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
Subscribe to:
Posts (Atom)