One of the big issues for code clarity is determining the intent of a function from its name. One of the tricks that I've taken to doing is to name the function such that when I read the code out loud, it sounds like I'm speaking normally, or nearly so.
For example, if I'm testing a file for various criteria, I'll have this:
if(fileIsRightSize() && fileIsNotWritable())
{
saveFile()
}
The cognitive benefit from this is immense. It's not a new idea, but I'm not seeing it get traction in code today.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Saturday, February 21, 2009
Friday, February 20, 2009
Ooooooh, Shiny!
What are the three primary symptoms of ADD?
1) lack of focus
2) easily distracted,
3) hey, look! a squirrel!
Jeff Atwood discusses the magpie tendencies of the industry. Over a decade ago, I used "magpie" to describe a cow-orker who was too enamored of changing technology for its own sake. Sometimes it seems that there's another new language every week, and a new web framework every month. We spend too much time learning Yet Another New Language and not enough time mastering the ones we already know.
Sometimes it's the customer that has this trait. I once heard a competitor's UI praised because it had oval buttons with drop shadows, while ours was vanilla Motif. Their system lacked a number of features we had, but because they looked cooler, they were getting the good vibes; and this was not a mass-market system - it was for a specific industry, where the number of systems would be in the few hundreds.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
1) lack of focus
2) easily distracted,
3) hey, look! a squirrel!
Jeff Atwood discusses the magpie tendencies of the industry. Over a decade ago, I used "magpie" to describe a cow-orker who was too enamored of changing technology for its own sake. Sometimes it seems that there's another new language every week, and a new web framework every month. We spend too much time learning Yet Another New Language and not enough time mastering the ones we already know.
Sometimes it's the customer that has this trait. I once heard a competitor's UI praised because it had oval buttons with drop shadows, while ours was vanilla Motif. Their system lacked a number of features we had, but because they looked cooler, they were getting the good vibes; and this was not a mass-market system - it was for a specific industry, where the number of systems would be in the few hundreds.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Thursday, February 19, 2009
Deja Vu, All Over Again
Just over a month ago, this list was published, the top 25 errors made in software. It's somewhat web-centric, given that most non-web software does not taken input from the great unwashed of the WWWeb. However, it is a good one to review, to see if your stuff could use a brush up.
Like Alex Wolfe says, it's a little troubling that so many systems are still plagued with these errors, given that there are monthly incidents of the web-based issues (CSS, usually), and more so that some of them are positively ancient (running off the end of a buffer). And like him, I'm somewhat inclined to blame the current disparagement of the industries' past. Nobody looks to the pillars of the discipline to see what they are saying.
Now, to some extent this is the typical "youth ignores elders" schtick, but a lot of it is more malignant - it's the rejection of all the collected wisdom because it doesn't have the pizzazz of Ruby, or the Cloud. And while there are a lot of new things necessary, like the new database features needed for massive scaling, having your server cracked because you let arbitrary SQL commands to be executed is epic fail.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Like Alex Wolfe says, it's a little troubling that so many systems are still plagued with these errors, given that there are monthly incidents of the web-based issues (CSS, usually), and more so that some of them are positively ancient (running off the end of a buffer). And like him, I'm somewhat inclined to blame the current disparagement of the industries' past. Nobody looks to the pillars of the discipline to see what they are saying.
Now, to some extent this is the typical "youth ignores elders" schtick, but a lot of it is more malignant - it's the rejection of all the collected wisdom because it doesn't have the pizzazz of Ruby, or the Cloud. And while there are a lot of new things necessary, like the new database features needed for massive scaling, having your server cracked because you let arbitrary SQL commands to be executed is epic fail.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Wednesday, February 11, 2009
Ninja Vs Samurai
Wil Shipley wrote a little piece about software about a year ago. The line that caught my eye was
"* The Way of the Code Samurai *
Now, I don't actually know much about real samurai, but the basic thing I've heard is they stand and stare at each other for hours, and then suddenly BAM strike once and the other guy is down.
That's how you should code."
Of course, I cannot let such a line go past unanswered.....
His points are excellent - think before you code, plan to do it over, write it clean as you go, and optimize later on.
Where he runs afoul of the Ninja Way is that he writes all this as if there are no managers breathing down your neck to get something written and delivered, or a Project Leader who will squash your raise if you are modifying code outside the area of the bugfix you are supposed to be doing. The Samurai were a favored class in their world, so they thought little of how to do things against the Powers That Be. The Ninja had to work from the bottom up.
So to get the time to think before you code the Ninja must start coding something - the spike solution Wil mentions, but even if you don't have an idea, start writing your test harness.
To get the chance to do it over, leave off a necessary, but tangential part of it - the UI, or the fringes of the API - stuff that is not necessary for the proof of concept, but expected in the final delivery.
To write it clean, adopt habits that support this - check flags with method calls if you expect conditions to be based on non-boolean values or several different flags; keep methods small, so that they can be refactored/rewritten quickly as you need to; learn the GoF patterns in your langauge, so that you can implement them quickly [heck, write them up as templates in your worksapce, so you can drop them in easily].
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
"* The Way of the Code Samurai *
Now, I don't actually know much about real samurai, but the basic thing I've heard is they stand and stare at each other for hours, and then suddenly BAM strike once and the other guy is down.
That's how you should code."
Of course, I cannot let such a line go past unanswered.....
His points are excellent - think before you code, plan to do it over, write it clean as you go, and optimize later on.
Where he runs afoul of the Ninja Way is that he writes all this as if there are no managers breathing down your neck to get something written and delivered, or a Project Leader who will squash your raise if you are modifying code outside the area of the bugfix you are supposed to be doing. The Samurai were a favored class in their world, so they thought little of how to do things against the Powers That Be. The Ninja had to work from the bottom up.
So to get the time to think before you code the Ninja must start coding something - the spike solution Wil mentions, but even if you don't have an idea, start writing your test harness.
To get the chance to do it over, leave off a necessary, but tangential part of it - the UI, or the fringes of the API - stuff that is not necessary for the proof of concept, but expected in the final delivery.
To write it clean, adopt habits that support this - check flags with method calls if you expect conditions to be based on non-boolean values or several different flags; keep methods small, so that they can be refactored/rewritten quickly as you need to; learn the GoF patterns in your langauge, so that you can implement them quickly [heck, write them up as templates in your worksapce, so you can drop them in easily].
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Thursday, February 05, 2009
Estimation
One of the more misunderstood parts of the software life cycle is the estimate. All methodologies have estimates, and it seems that all management mis-uses estimates. The rough estimate asked for at the beginning of the project rapidly turns into the contracted-delivery-date-with-penalties used to justify 80+ hour weeks.
One difficulty is that information deteriorates upwards in an organization - no matter how clear you are to your boss that it will take 3-8 weeks, +/- 2 weeks, he will summarize that as 1-10 weeks, his boss will split the difference at 6 weeks, and his boss will think 3 weeks, "because everyone knows programmers pad their estimates", so you end up with and already compromised schedule.
One of my early colleagues in the industry said that the minimum estimate for anything was 2 weeks. Bigger projects got longer estimates, but the floor meant that you always had some spare time to cover where management cut your times.
One brave tactic that I have used on occasion is to tacitly refuse overtime. I had a task once where I was asked to estimate the time it would take. I guessed 2 weeks (sic), and turned that estimate in to my boss on a Wednesday morning. That Friday at a status meeting I was informed that I was already 2 days behind schedule; imagine my surprise, since I was not told that my estimate had become my deadline. I was especially peeved because I was working on a customer issue, so I had no re-prioritization to let me know the new project was my primary task.
So I just worked M-F, 8 hour days. I did not stay late unless there was more customer site interaction, which often required staying until their staff went home at their local 5pm. I was lucky in that my estimate was only slightly above the real effort. But had it required more effort, I was going to stick to my routine, since it was not I who made the mistake in scheduling and priorities.
If you are unlucky enough to be in a Death March shop, there may be little recourse but to risk failure. If you can form a cadre of programmers who are willing to hold the line on estimates, you might get your bosses to stop ignoring the laws of physics.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
One difficulty is that information deteriorates upwards in an organization - no matter how clear you are to your boss that it will take 3-8 weeks, +/- 2 weeks, he will summarize that as 1-10 weeks, his boss will split the difference at 6 weeks, and his boss will think 3 weeks, "because everyone knows programmers pad their estimates", so you end up with and already compromised schedule.
One of my early colleagues in the industry said that the minimum estimate for anything was 2 weeks. Bigger projects got longer estimates, but the floor meant that you always had some spare time to cover where management cut your times.
One brave tactic that I have used on occasion is to tacitly refuse overtime. I had a task once where I was asked to estimate the time it would take. I guessed 2 weeks (sic), and turned that estimate in to my boss on a Wednesday morning. That Friday at a status meeting I was informed that I was already 2 days behind schedule; imagine my surprise, since I was not told that my estimate had become my deadline. I was especially peeved because I was working on a customer issue, so I had no re-prioritization to let me know the new project was my primary task.
So I just worked M-F, 8 hour days. I did not stay late unless there was more customer site interaction, which often required staying until their staff went home at their local 5pm. I was lucky in that my estimate was only slightly above the real effort. But had it required more effort, I was going to stick to my routine, since it was not I who made the mistake in scheduling and priorities.
If you are unlucky enough to be in a Death March shop, there may be little recourse but to risk failure. If you can form a cadre of programmers who are willing to hold the line on estimates, you might get your bosses to stop ignoring the laws of physics.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Wednesday, February 04, 2009
What's The Rush?
My Real World job has been hectic lately, with customer and internal issues colliding, and my individual time being a very valuable commodity for the various release managers. Since some of the issues affect fielded releases, the Program Managers are keen to tell the customers when we will have a fix available for them. So keen, in fact, they are telling them dates by which we will deliver said fixes.
Read that again. The Program Managers are setting a schedule by which developers are to find, analyze, and fix a bug, and test that fix.
How do you handle something like this? A total perversion of all that is Good and Holy in software development!
In better times, the best advice would be to look for another job. As I'm writing this, that's not such good advice, so you have to tell your managers something, and do something in your process to handle this. (Kudos to you if you have a process that acknowledges bugs will exist)
For the upward information flow, address it like car repairs - it doesn't matter how often the vehicle makes that funny noise if the mechanic isn't there to hear it - bugs need to be replicated where a developer can apply tools to extract information. If you broke down on the highway, called your mechanic and asked him to diagnose the problem over the phone, she'd tell you to wait until the tow truck got the car back to the shop and she was able to hook up the analyzer. Likewise with a bug in code, we need more data in most cases.
In addition, you need to make sure to emphasize that unless the software is very well factored, changes may have far-reaching side effects that need to be tested for. This is especially important for complex programs, such as multi-threaded ones, or highly performance-optimized ones.
Once a bug is found, you sometimes find it's the loose thread in a knitted tangle disguised as a sweater. It make take a long time to refactor the code to eliminate the root cause of the problem. I can't say I've ever had success in getting this point across to anyone more than one level above me in any organization.
If all else fails, revert to the old proverb, "Haste makes waste"
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Read that again. The Program Managers are setting a schedule by which developers are to find, analyze, and fix a bug, and test that fix.
How do you handle something like this? A total perversion of all that is Good and Holy in software development!
In better times, the best advice would be to look for another job. As I'm writing this, that's not such good advice, so you have to tell your managers something, and do something in your process to handle this. (Kudos to you if you have a process that acknowledges bugs will exist)
For the upward information flow, address it like car repairs - it doesn't matter how often the vehicle makes that funny noise if the mechanic isn't there to hear it - bugs need to be replicated where a developer can apply tools to extract information. If you broke down on the highway, called your mechanic and asked him to diagnose the problem over the phone, she'd tell you to wait until the tow truck got the car back to the shop and she was able to hook up the analyzer. Likewise with a bug in code, we need more data in most cases.
In addition, you need to make sure to emphasize that unless the software is very well factored, changes may have far-reaching side effects that need to be tested for. This is especially important for complex programs, such as multi-threaded ones, or highly performance-optimized ones.
Once a bug is found, you sometimes find it's the loose thread in a knitted tangle disguised as a sweater. It make take a long time to refactor the code to eliminate the root cause of the problem. I can't say I've ever had success in getting this point across to anyone more than one level above me in any organization.
If all else fails, revert to the old proverb, "Haste makes waste"
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Malaria.exe
Looks like Microsoft is branching out from being a vector of computer viruses into being one of real-world viruses.
I wonder if any CxOs from RedHat, IBM, or Apple were in attendance that day......
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
I wonder if any CxOs from RedHat, IBM, or Apple were in attendance that day......
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Subscribe to:
Posts (Atom)