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
Wednesday, December 16, 2009
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
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
Sunday, April 19, 2009
Ninja Skills - Estimation
One of the common tasks a developer is asked to do is to estimate the amount of time a particular feature will take to develop. According to the literature, we apparently suck at this. Developers are constantly being told that they cannot make good estimates.
So here's some help.
This post describes a fairly common technique, wherein the developer breaks the task down into units that can be completed in a small number of days (2, in this example). It does not specify if the developer is determining this alone or as part of a group.
Another example of a method is here. This provides a little more process, for those estimating as a group instead of individual developers.
The Ninja Way for estimations is not much different in the inital steps - you determine the size of the overall task, break it into sub tasks that are about the quantum you have found reasonably accurate to guess (typically 1-2 days), and add up those times. Next, look over each step, and ask yourself what could happen that would delay your completion of that step without removing the need to complete that subtask - someone else using the test machine for that release, an overnight build failure, etc. Guess at how long that would take to recover from, and add the longest of those single things into the estimate for that step. For example, if the test machine is in use, how log would it take for you to schedule a break with the current user? (And those who are so 21-century who ask "Why only one test machine? Why manual tests?" - wake up to the fact that not everything is run on a commodity web-server, and not all development organizations have the budget for even one machine per released version of their product.)
This should get you an estimate that will cover the inevitable delays.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
So here's some help.
This post describes a fairly common technique, wherein the developer breaks the task down into units that can be completed in a small number of days (2, in this example). It does not specify if the developer is determining this alone or as part of a group.
Another example of a method is here. This provides a little more process, for those estimating as a group instead of individual developers.
The Ninja Way for estimations is not much different in the inital steps - you determine the size of the overall task, break it into sub tasks that are about the quantum you have found reasonably accurate to guess (typically 1-2 days), and add up those times. Next, look over each step, and ask yourself what could happen that would delay your completion of that step without removing the need to complete that subtask - someone else using the test machine for that release, an overnight build failure, etc. Guess at how long that would take to recover from, and add the longest of those single things into the estimate for that step. For example, if the test machine is in use, how log would it take for you to schedule a break with the current user? (And those who are so 21-century who ask "Why only one test machine? Why manual tests?" - wake up to the fact that not everything is run on a commodity web-server, and not all development organizations have the budget for even one machine per released version of their product.)
This should get you an estimate that will cover the inevitable delays.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Tuesday, April 14, 2009
Anti-Heroism
In an earlier post, I mentioned the bad effects of a culture of heroism. Making a virtue of excessive overtime rewards reactive instead of proactive programming; it cuts into the testing of the product; it erodes morale.
It's a death spiral in most companies; managament stops recognizing the normal limits of work and starts to expect more and more. This is especially likely in companies that do not accurately track developer hours - if the management does not get a complete count of the time spent on development, they will assume it was done in a 40-hour week, and so they think that the next project can be accelerated by getting the developers to work a few more hours.
So when 5'o'clock rolls around, wrap up what you're working on, prep for the next day, and GO HOME.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
It's a death spiral in most companies; managament stops recognizing the normal limits of work and starts to expect more and more. This is especially likely in companies that do not accurately track developer hours - if the management does not get a complete count of the time spent on development, they will assume it was done in a 40-hour week, and so they think that the next project can be accelerated by getting the developers to work a few more hours.
So when 5'o'clock rolls around, wrap up what you're working on, prep for the next day, and GO HOME.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, April 05, 2009
A Followup on Automated Testing
A few posts back I described a blog post I had read about a shop that was stating they did 50-60 live deployments per day.
Here's a post about someone who went and looked at the system being deployed.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Here's a post about someone who went and looked at the system being deployed.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Saturday, April 04, 2009
Several Lists to consider
I've accumulated a number of "Top N X" lists over the past few months, so I decided to bundle them all together into a single post for your perusal. I cannot vouch for any specifics in any of the lists, but they are probably useful at the least.
Coding practice sites - these are good for your Code Kata (and Code Kumite)
Seminal Computer Science Papers - you should always know the foundations of your discipline
Some recent programming books - now that you know the foundations, look to some cutting edge work
Good blogs about programming - keeping abreast of the latest news in the profession. (The list is incomplete - it's missing this blog :)
So read and enjoy, and hopefully you will find things you can use.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Coding practice sites - these are good for your Code Kata (and Code Kumite)
Seminal Computer Science Papers - you should always know the foundations of your discipline
Some recent programming books - now that you know the foundations, look to some cutting edge work
Good blogs about programming - keeping abreast of the latest news in the profession. (The list is incomplete - it's missing this blog :)
So read and enjoy, and hopefully you will find things you can use.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Wednesday, March 25, 2009
A Different Type Of Hacking
Although we all typically found adding code to a system, one of the funner parts is removing code. I love it when I can cut whole swaths of code out of a system, combining duplicate code into a common function, deleting unused methods, slashing commented-out junk.
And sometimes you get the chance to rewrite some code, and sometimes you have to
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
And sometimes you get the chance to rewrite some code, and sometimes you have to
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Tuesday, March 24, 2009
Another Take on Technical Debt
Most of us should be familiar with the idea of Technical Debt, but it's not always clear how it fits into the long-term view of a project. Here's Martin Fowler's concept of Design Stamina - showing why Technical Debt tends to accumulate; there is a point in the life of a project where TD is a useful thing to grow, but there is a point where it becomes a liability.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Monday, March 23, 2009
Social Skills In Developers
We all known at least one of them. The prima donna, the ego on legs, the one developer who is famously skilled, but is, to put it bluntly, an asshole.
If you're one of them, you probably need to stop reading now.
If you've got one on your team, you probably need to get them out of your critical path.
Despite our professions acceptance of heroism, the presence of a toxic person can kill a team, or
a project, or a company.
The biggest risk is to your team - you risk alienating all the rest of them, and at some point, you will piss off your resident genius and will have nobody to turn to to save your ass.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
If you're one of them, you probably need to stop reading now.
If you've got one on your team, you probably need to get them out of your critical path.
Despite our professions acceptance of heroism, the presence of a toxic person can kill a team, or
a project, or a company.
The biggest risk is to your team - you risk alienating all the rest of them, and at some point, you will piss off your resident genius and will have nobody to turn to to save your ass.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, March 22, 2009
Metric System
One of the larger conflicts between programmers and management is on how to measure programmer value - who is a good programmer and who isn't. Aside from the ego and paycheck issues, it's still a touchy subject, usually because the metrics that management usually chooses to use are typically measuring the wrong things.
One of the oldest metrics is Lines of Code (LOC, or more commonly KLOC). Now, KLOC may be a good way to compare the complexity or effort, after the fact, of a team's work on different projects, but it's not a good measure of individual programmer productivity. There are just too many variables. It's also very easy to game the numbers - if your boss is going to rate high KLOC numbers as good programming, your programs will be longer.
That's another point - programmers are very good at recognizing the rules of a system and gaming them. Given the strong correlation between programming and role-playing games, it's foolish to think that we won't find a way to mini-max the metric. KLOC? Put everything on its own line. Function Points? Every method will be as complex as possible. Etc, etc. The only way to have accurate metrics is to decouple them from programmer pay and promotion.
So what if you need to measure improvement? Here's one option, and another. And in case you need ammunition to get off a Death March, there's this.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
One of the oldest metrics is Lines of Code (LOC, or more commonly KLOC). Now, KLOC may be a good way to compare the complexity or effort, after the fact, of a team's work on different projects, but it's not a good measure of individual programmer productivity. There are just too many variables. It's also very easy to game the numbers - if your boss is going to rate high KLOC numbers as good programming, your programs will be longer.
That's another point - programmers are very good at recognizing the rules of a system and gaming them. Given the strong correlation between programming and role-playing games, it's foolish to think that we won't find a way to mini-max the metric. KLOC? Put everything on its own line. Function Points? Every method will be as complex as possible. Etc, etc. The only way to have accurate metrics is to decouple them from programmer pay and promotion.
So what if you need to measure improvement? Here's one option, and another. And in case you need ammunition to get off a Death March, there's this.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Saturday, March 21, 2009
Paper Pushing
Way back when I got started in programming, my high school did not have any computers, of any sort. So the programming was done on coding sheets, which were sent into the school district data processing facility, where some data entry clerks typed them in, presumably on cards, and sent the batch job to be processed. If we were lucky, everything was correct and we got back a result printout. If we weren't, we got back an error sheet and had to examine the code again to see where we went wrong. Usually it was a syntax error of some sort, so we re-wrote the coding sheet and submitted it on the next batch. I had one program that appeared to be un-typable - every clerk managed to typo something every try I made - the teacher finally let the program pass without running.
The next semester we got 3 Radio Shack TRS-80 computers, and we were freed from having to do coding sheets - until my college course in assembler, which was on punch cards - not a fun semester.
So for many years, I've been coding at the keyboard. But when I have a particularly hairy issue, I find myself going to a blank sheet of white paper and pseudocoding my way into the solution. I firmly believe that there is something visceral about writing that makes us more attentive to details. There are others who have a similar philosophy.
On the other hand, I've also fond that in some cases, typing is faster when I'm trying to get an idea out of my head and into a recorded form.
What do you think? Is writing code a quaint habit of old-timers, or a return to the core of the discipline?
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
The next semester we got 3 Radio Shack TRS-80 computers, and we were freed from having to do coding sheets - until my college course in assembler, which was on punch cards - not a fun semester.
So for many years, I've been coding at the keyboard. But when I have a particularly hairy issue, I find myself going to a blank sheet of white paper and pseudocoding my way into the solution. I firmly believe that there is something visceral about writing that makes us more attentive to details. There are others who have a similar philosophy.
On the other hand, I've also fond that in some cases, typing is faster when I'm trying to get an idea out of my head and into a recorded form.
What do you think? Is writing code a quaint habit of old-timers, or a return to the core of the discipline?
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Monday, March 16, 2009
Too Much Choice
An interesting point about choices.
One of my dislikes of Perl is this very thing - lots of way to do X leads to programs that use every way to do X in them.
One of the ways that choice makes our jobs harder is that every option needs to be validated somewhere in the code. Often this gets translated into masses of checks for all the options at every point of action.
Instead of this, you should strive to have things checked at the earliest opportunity, and then have the rest of your code assume that anything past the checks is valid and right. This limits your exposure to change, and makes the rest of the code flow smoother. It does tend to collect your checking code in the UI (or the interface to the UI), but it's a lot easier.
This also applies to the UI - don't give the user every option if they aren't all valid. Trim your menus of unactivated features; hide the checkboxes of custom features for the other customers.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
One of my dislikes of Perl is this very thing - lots of way to do X leads to programs that use every way to do X in them.
One of the ways that choice makes our jobs harder is that every option needs to be validated somewhere in the code. Often this gets translated into masses of checks for all the options at every point of action.
Instead of this, you should strive to have things checked at the earliest opportunity, and then have the rest of your code assume that anything past the checks is valid and right. This limits your exposure to change, and makes the rest of the code flow smoother. It does tend to collect your checking code in the UI (or the interface to the UI), but it's a lot easier.
This also applies to the UI - don't give the user every option if they aren't all valid. Trim your menus of unactivated features; hide the checkboxes of custom features for the other customers.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, March 15, 2009
Drowning In Code
Sometimes you have to work on old code.
(pause as the shock and cires of "Heretic!" die down)
Since not everyone gets to write only new code, you'll have to face this task many times in your career.
Here are two tips on how to approach it.
They both assume that you have limited documentation, obviously, since they promote looking at the code as opposed to looking at the documents; this is better anyway, since we all know that the docs are least likely to be accurate (followed closely by comments in the code)
Another good way to become familiar with the code is to look for something redundant that you can encapsulate into a method. This can lead to significant code reduction, making it easier for you to understand the remaining code.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
(pause as the shock and cires of "Heretic!" die down)
Since not everyone gets to write only new code, you'll have to face this task many times in your career.
Here are two tips on how to approach it.
They both assume that you have limited documentation, obviously, since they promote looking at the code as opposed to looking at the documents; this is better anyway, since we all know that the docs are least likely to be accurate (followed closely by comments in the code)
Another good way to become familiar with the code is to look for something redundant that you can encapsulate into a method. This can lead to significant code reduction, making it easier for you to understand the remaining code.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Saturday, March 14, 2009
One Reason Why Windows Sucks As A Development Platform
It takes 8 GB of RAM just to work
It also is expected that every application will use a standalone server for its copy of a database.
This is just plain nuts, folks. And here's some of the reasons why.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
It also is expected that every application will use a standalone server for its copy of a database.
This is just plain nuts, folks. And here's some of the reasons why.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Wednesday, March 11, 2009
Technical Debt and The New Thing
Here's a piece on Technical Debt and it's effect on your developers. Technical Debt is the accumulation of bad stuff in the codebase - magic numbers, duplication of code, hacks to get around some specific problem you don't have the time to fix Right Now.
And he's right - it's damned hard to get any manager to understand that you need to clean up stuff that was done to satisfy a compressed schedule. You need to make it as clean as possible from the start. But it's also very dangerous to build the whole shebang from scratch.
One employer tried this. A new Director hasd come in and was making the big mistake of trashing all the existing project (and people), so she got buy-in to re-write the app. She hand picked a new team from the existing one, augmented by some contractors she had worked with previously. But her biggest mistake was preventing the new team from reusing the old code - it had to be all new stuff, and her developers could not talk to the old guard for advice.
So the new project lost all the accumulated wisdom, and all the expertise that was present in the original team, and spent far too long rebuilding the infrastructure. The project failed miserably.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
And he's right - it's damned hard to get any manager to understand that you need to clean up stuff that was done to satisfy a compressed schedule. You need to make it as clean as possible from the start. But it's also very dangerous to build the whole shebang from scratch.
One employer tried this. A new Director hasd come in and was making the big mistake of trashing all the existing project (and people), so she got buy-in to re-write the app. She hand picked a new team from the existing one, augmented by some contractors she had worked with previously. But her biggest mistake was preventing the new team from reusing the old code - it had to be all new stuff, and her developers could not talk to the old guard for advice.
So the new project lost all the accumulated wisdom, and all the expertise that was present in the original team, and spent far too long rebuilding the infrastructure. The project failed miserably.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Tuesday, March 10, 2009
Not-Really Functional Programming
An interesting opinion on a style in OOP that leads towards a Functional Programming vibe. From my brief forays into FP, the advantage is that you don't have to manage state; the downside is that you have to organize your program so that you can drop all the intermediate results into a single function.
Of course, small focused methods are a Good Thing (tm) in their own right, so this may just be a convergent evolution of a sort - encapsulating the mutable state so that it's not important at other levels.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Of course, small focused methods are a Good Thing (tm) in their own right, so this may just be a convergent evolution of a sort - encapsulating the mutable state so that it's not important at other levels.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Monday, March 09, 2009
Fake It Til You Make It
Recent studies in social leadership have tended to show that those who speak up are perceived as leaders.
The obvious Ninja take-away from this is to be sure you speak up in the workplace. If you've been following along here, you should have some of the chops to back it up.
Of course, this may explain the tendency for all the red-tape layers of management to call meetings just so they can voice their irrelevant opinion and rubberstamp the decision.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
The obvious Ninja take-away from this is to be sure you speak up in the workplace. If you've been following along here, you should have some of the chops to back it up.
Of course, this may explain the tendency for all the red-tape layers of management to call meetings just so they can voice their irrelevant opinion and rubberstamp the decision.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, March 08, 2009
The Death Of One Thousand Cuts
One of the big things you get as a software developer is a sense for automation. Every advancement of our profession is about automating something - computers were first intended to replace tedious manual math calculations, after all.
So we have the hammer of automation, and tend to see many things as the Nail of repetition. Not that this is a bad thing - it makes our jobs interesting, and keeps us from dying of RSI.
Yet as we go along, we sometimes get into the rut of the things we are not yet able to automate, so I see this post as a reminder to keep looking for thing to automate.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
So we have the hammer of automation, and tend to see many things as the Nail of repetition. Not that this is a bad thing - it makes our jobs interesting, and keeps us from dying of RSI.
Yet as we go along, we sometimes get into the rut of the things we are not yet able to automate, so I see this post as a reminder to keep looking for thing to automate.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Signs And Portents
This list is going to look familiar to any of you that were coding during the dot-com boom and bust.
The scary part is that so many of them are true.
I counted 26 that I have personally seen. #40 was a point in my most recent company meeting.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
The scary part is that so many of them are true.
I counted 26 that I have personally seen. #40 was a point in my most recent company meeting.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Wednesday, March 04, 2009
On The Shoulders Of Giants
Do you think a sculptor would like to listen to Michaelangelo talk about stone carving? What about an engineer having lunch with James Watt?
This post brought this thought up - we're able to talk to the second generation of giants in this industry, and we seem to not take advantage of it as much as we should. Sure, we've developed things much beyond the original technology (My second PC had a 40 MB hard drive. Today I can buy a 1TB drive for one tenth the cost of that PC), but they had the brains to do things in tiny memory over slow data lines, and Moore's Law was not yet in effect.
I've seen Commodore Grace Hopper speak, for crying out loud!
It seems a shame that we're rushing headlong into the future without listening to our elders.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
This post brought this thought up - we're able to talk to the second generation of giants in this industry, and we seem to not take advantage of it as much as we should. Sure, we've developed things much beyond the original technology (My second PC had a 40 MB hard drive. Today I can buy a 1TB drive for one tenth the cost of that PC), but they had the brains to do things in tiny memory over slow data lines, and Moore's Law was not yet in effect.
I've seen Commodore Grace Hopper speak, for crying out loud!
It seems a shame that we're rushing headlong into the future without listening to our elders.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Monday, March 02, 2009
Good, Fast, Cheap Revisited
Here's a good discussion of the old programmer adage "Good, Fast, Cheap. Pick any two". The comments are enlightening.
A few things that I realized reading that was that there are some definitions that make this a little tricky to discuss.
The first is that your axes need to grow in the correct direction. You can say you're increasing scope by pushing that apex away from the center, which makes the project more difficult, but you've then got to treat resources and time in the same manner, which means that extending the Time apex is not giving more time, but decreasing the time to deadline; similarly, extending the Resources apex means filling up more of your developer's capacity.
I'll need to ponder this a while - perhaps I'll come up with a better analogy, or at least better terms to use.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
A few things that I realized reading that was that there are some definitions that make this a little tricky to discuss.
The first is that your axes need to grow in the correct direction. You can say you're increasing scope by pushing that apex away from the center, which makes the project more difficult, but you've then got to treat resources and time in the same manner, which means that extending the Time apex is not giving more time, but decreasing the time to deadline; similarly, extending the Resources apex means filling up more of your developer's capacity.
I'll need to ponder this a while - perhaps I'll come up with a better analogy, or at least better terms to use.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, March 01, 2009
Haters
As one of the (relatively) older people in Software Development, I've seen a good deal of the history of the profession, and one of the perennial things we are forced to live with are the holy wars over various things. We've got Editor Wars (Emacs vs vi), OS Wars (Windows vs Mac vs Unix), distro wars (Ubuntu vs Fedora vs Gentoo), and so on.
But the biggest wars are those over the programming paradigms - Declarative programming (DP), Functional programming (FP), Object-oriented programming (OO), and the others. So it's always amusing to read the various viewpoints from the various camps, and quite often I learn something useful from them.
However, not all are so valuable - this post, from a Erlang partisan, is an almost classic example of elevating personal preference to moral imperative. He (?) takes various straw men about OOP and proceeds to tear them apart, claiming that this then "proves" OOP is a bad idea.
I'm not usually prone to point-by-point rebuttals, but this one was too egregious not to try.
Objection 1 - functions and data should not be bound together
This shows a total misunderstanding of the premise of OOP. The objects exist to collect the data and behavior that modifies that data. If you have an object modeling a car, and you want to track fuel consumption for that car, where better to place that than with the car, so that any individual quirks about fuel burn rate for that specific car are contained there? An FP alternative would be to have a fuel-burn function, but that would have to be able to handle every possible fuel burn option, making it a very complex function; if only a few vehicles needed certain options, the OOP solution would keep those options close to where they are used.
Objection 2 - everything has to be an object
While not true in most OOP languages, the point is clear. However, the example he gives is for time, and he suggests using the Erlang type declarations. Now, I know very little about Erlang; in fact, I know effectively nothing about it. But this set of functions reference a conceptual time object - the real time clock of the system, and only return values from that object.
Objection 3 - OOPLs spread data type definitions all over the place
This one does have a grain of truth - you can't put everything in your OOP program in one file. However, it provides an encapulation - you don't need to know the inner workings of everything if you have a well-defined interface to those things. He also makes the spurious claim that if you need a "ubiquitious" data structure, you must inherit from that class to use it. This shows a lack of awareness of how OOP works - inheritance is only part of the mix - composition is more useful, and does not require inheritance to work. In fact, composition is part and parcel of earlier structured languages and their data structures.
Objection 4 - Objects have private state
Spoken (typed) like a true FP partisan. "State is the root of all evil", yet "in the real world, state abounds" Why then do we wish to eliminate state, if it is part of the things we wish to control? He claims that revealing all the state is good, but using monads to allow the programmer to avoid knowing about state is also good. You can't have it both ways - either there is state, and it needs to be managed, or you need to avoid it altogether. OOP allows the programmer to use state when desirable, and to hide it when convenient, much like the real world - I do not need to know all the details of state when I buy a soda from a vending machine, but it's very useful to me should I be repairing that machine.
He then wraps it all up by dismissing OOP because he sees no evidence it helped people learn faster, or made code reuse easier. Arguemnt from incredulity is hardly convincing.
OOP is not a panacea, by any means, but it is a strong tool for partitioning a problem set into disparate sections for working on it.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
But the biggest wars are those over the programming paradigms - Declarative programming (DP), Functional programming (FP), Object-oriented programming (OO), and the others. So it's always amusing to read the various viewpoints from the various camps, and quite often I learn something useful from them.
However, not all are so valuable - this post, from a Erlang partisan, is an almost classic example of elevating personal preference to moral imperative. He (?) takes various straw men about OOP and proceeds to tear them apart, claiming that this then "proves" OOP is a bad idea.
I'm not usually prone to point-by-point rebuttals, but this one was too egregious not to try.
Objection 1 - functions and data should not be bound together
This shows a total misunderstanding of the premise of OOP. The objects exist to collect the data and behavior that modifies that data. If you have an object modeling a car, and you want to track fuel consumption for that car, where better to place that than with the car, so that any individual quirks about fuel burn rate for that specific car are contained there? An FP alternative would be to have a fuel-burn function, but that would have to be able to handle every possible fuel burn option, making it a very complex function; if only a few vehicles needed certain options, the OOP solution would keep those options close to where they are used.
Objection 2 - everything has to be an object
While not true in most OOP languages, the point is clear. However, the example he gives is for time, and he suggests using the Erlang type declarations. Now, I know very little about Erlang; in fact, I know effectively nothing about it. But this set of functions reference a conceptual time object - the real time clock of the system, and only return values from that object.
Objection 3 - OOPLs spread data type definitions all over the place
This one does have a grain of truth - you can't put everything in your OOP program in one file. However, it provides an encapulation - you don't need to know the inner workings of everything if you have a well-defined interface to those things. He also makes the spurious claim that if you need a "ubiquitious" data structure, you must inherit from that class to use it. This shows a lack of awareness of how OOP works - inheritance is only part of the mix - composition is more useful, and does not require inheritance to work. In fact, composition is part and parcel of earlier structured languages and their data structures.
Objection 4 - Objects have private state
Spoken (typed) like a true FP partisan. "State is the root of all evil", yet "in the real world, state abounds" Why then do we wish to eliminate state, if it is part of the things we wish to control? He claims that revealing all the state is good, but using monads to allow the programmer to avoid knowing about state is also good. You can't have it both ways - either there is state, and it needs to be managed, or you need to avoid it altogether. OOP allows the programmer to use state when desirable, and to hide it when convenient, much like the real world - I do not need to know all the details of state when I buy a soda from a vending machine, but it's very useful to me should I be repairing that machine.
He then wraps it all up by dismissing OOP because he sees no evidence it helped people learn faster, or made code reuse easier. Arguemnt from incredulity is hardly convincing.
OOP is not a panacea, by any means, but it is a strong tool for partitioning a problem set into disparate sections for working on it.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Saturday, February 28, 2009
Automated Testing^2
Man, some people have all the luck.
I ran across this the other day, describing an automated test environment that, if it really is as he says, is truly amazing. The part that really stands out, to me, is that they're running their test suite on a pool of "30-40 machines"
I really envy that. My current employer does not have enough test machines for developers to run their own development tests, let alone run a test suite for load testing like that.
Of course, it's a lot easier if you're writing web-based systems. Then your scaling is conceptually trivial - all you need is a few tens of PCs hitting the server. If you're developing software for systems that live in a world of other specialized servers, many developed by other companies, then you are hard pressed to replicate more than a handful of systems to run tests on.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
I ran across this the other day, describing an automated test environment that, if it really is as he says, is truly amazing. The part that really stands out, to me, is that they're running their test suite on a pool of "30-40 machines"
I really envy that. My current employer does not have enough test machines for developers to run their own development tests, let alone run a test suite for load testing like that.
Of course, it's a lot easier if you're writing web-based systems. Then your scaling is conceptually trivial - all you need is a few tens of PCs hitting the server. If you're developing software for systems that live in a world of other specialized servers, many developed by other companies, then you are hard pressed to replicate more than a handful of systems to run tests on.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Wednesday, February 25, 2009
Making It Harder To Fail
I ran across this post and I was taken with the idea of making it harder to do bad things. I especially agree with the color coding of hardcoded values to be ugly and harsh. Using a larger font is probably an issue of personal taste and programming language choice.
Adopting a coding standard that encourages short, meaningful method names is also good.
Some people really like Hungarian notation, but I've found that using longer variable names is better - you do not need to remember the cryptic abbreviations.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Adopting a coding standard that encourages short, meaningful method names is also good.
Some people really like Hungarian notation, but I've found that using longer variable names is better - you do not need to remember the cryptic abbreviations.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Tuesday, February 24, 2009
Wheels Within Wheels
Jeff Atwood wrote a post earlier this month about Reinventing the Wheel, where he advocates it as a learning experience, or to make a better wheel.
The problem is that he mistakes the reason people say "Don't reinvent the wheel" - it's almost never because You can't come up with a better wheel - it's because you don't need a better wheel.
Unless your business is about compilers, or has a need for really tweaked compilers, you don't need to be writing compilers. Unless your business is about encryption, you don't need to be writing encryption routines. Unless your business is about email, you don't need to be writing an email client.
Given the breadth of computer science and programming, the odds are very high that you are not as well-versed in the topic as someone who specialized in the topic. Bruce Schneier has a "Doghouse" classification for companies that badly re-implement cryptography in their products.
Jeff does note that reinventing the wheel can be a good learning process, and gives a nod to Charles Moore rewriting drivers himself for use in Forth, but those are not common cases, and Moore's business was the language, so it was germane to him to make it as solid as possible.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
The problem is that he mistakes the reason people say "Don't reinvent the wheel" - it's almost never because You can't come up with a better wheel - it's because you don't need a better wheel.
Unless your business is about compilers, or has a need for really tweaked compilers, you don't need to be writing compilers. Unless your business is about encryption, you don't need to be writing encryption routines. Unless your business is about email, you don't need to be writing an email client.
Given the breadth of computer science and programming, the odds are very high that you are not as well-versed in the topic as someone who specialized in the topic. Bruce Schneier has a "Doghouse" classification for companies that badly re-implement cryptography in their products.
Jeff does note that reinventing the wheel can be a good learning process, and gives a nod to Charles Moore rewriting drivers himself for use in Forth, but those are not common cases, and Moore's business was the language, so it was germane to him to make it as solid as possible.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Monday, February 23, 2009
Good Enough is Good Enough!
Given the detail-orientation of many of us, it's not unusual to run across a situation where someone is striving for perfection. The correct thing to do (in most cases) is to stop them.
Perfection is bad from 2 aspects:
1) perfect means it solves every single problem the user has
This is bad because it means that the system is either brittle, or too malleable
2) the incremental cost of perfection is almost always much higher than the cost of small bugs
One way that a Ninja combats these tendencies is to prototype. Make a first version that covers the known issues in some way, and have a test run with the end user. I use this for documents all the time - I'll set out a view of the problem and distribute it for comments. I find that I get many more responses than if I ask for input before I present something. If I have no idea about what to write, I make a known-wrong example to insure that all the editors will leap to the occasion to show how much they know about the process and correct me.
The prototype allows you to concentrate on the most important issues first, and to no sweat the small issues until later, when the end user may be satisfied with the prototype, or one of its successors. Besides, if you prototype, you'll know what works when it comes time to do the inevitable rewrite
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Perfection is bad from 2 aspects:
1) perfect means it solves every single problem the user has
This is bad because it means that the system is either brittle, or too malleable
2) the incremental cost of perfection is almost always much higher than the cost of small bugs
One way that a Ninja combats these tendencies is to prototype. Make a first version that covers the known issues in some way, and have a test run with the end user. I use this for documents all the time - I'll set out a view of the problem and distribute it for comments. I find that I get many more responses than if I ask for input before I present something. If I have no idea about what to write, I make a known-wrong example to insure that all the editors will leap to the occasion to show how much they know about the process and correct me.
The prototype allows you to concentrate on the most important issues first, and to no sweat the small issues until later, when the end user may be satisfied with the prototype, or one of its successors. Besides, if you prototype, you'll know what works when it comes time to do the inevitable rewrite
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, February 22, 2009
Some Thoughts On The Zone
Most of us developing software have spent some time in "The Zone"; that quasi-mythical mental state called flow that allows us to almost instinctively create good code. My last extended run in the Zone was a number of years back*, but I was able to spend a number of weeks diving deep into the code and data structures to revamp a major portion of functionality in a system. I don't know if there are any studies that support the correctness of code written in the Zone, but it is at least strong folklore in the profession. And it's a good feeling, being in the Zone, and makes the development go faster.
So when I read about a development technique that helps you stay in the Zone, I'm interested. I'm going to try this over the next few weeks and see if it works.
*one of the perils of developing software for a company that does not sell software - you spend a lot of time out of the software process
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
So when I read about a development technique that helps you stay in the Zone, I'm interested. I'm going to try this over the next few weeks and see if it works.
*one of the perils of developing software for a company that does not sell software - you spend a lot of time out of the software process
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Saturday, February 21, 2009
What's In A Name?
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
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
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
Tuesday, February 03, 2009
Logging in Your System
Logging is one of the more controversial aspects of a large system. There are some who hold that you should not need to have log file - everything should be presented in some UI or other. Others take it to the other extreme, logging every action at almost the code line level.
Not surprisingly, the answer lies in between. You need to log enough to be able to track what is going on, and save enough info about the error conditions to make it clear what went on, but you don't want to flood your logfiles with chaff.
One common thing is to make your logging dynamic - you can adjust it on the fly, so that if an error is recurring, you can turn it up to get more detail. For this to work, you need to define various levels of logging to present, and have a means to store the current level of presentation. Another facet of logging is the files the logs are written to. UNIX system have the syslog() facility, which is good for serious issues - ones that may shut down the system, or cause complete failure, like full disks, etc.
But it can be a pain to fill up a system file with the minutae of your most verbose debug level, so the best is probably to route logs to a file under your control. Of course, it goes without saying that you should have a file aging system in place to keep the file from growing too large, and having too many old ones.
There is usually a debate about how logging levels should be managed - as increasing levels, or as bit flags to cover areas like disk I/O, database access, RPC communications, etc. It's something of a judgment call, but make a set of categories and enforce it across all processes in the system, or you'll have chaos.
If you go with levels, you'll have the question of how many levels. There are a number of logging systems that use levels, and if you are using a language with such a facility, use those levels. If not, look to one of them for suggestions.
Have a command-line utility to adjust logging levels, so that if you have to go in remotely you can change things - there's nothing worse than having to wake up a site staffer just to navigate to a single GUI and click one button.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Not surprisingly, the answer lies in between. You need to log enough to be able to track what is going on, and save enough info about the error conditions to make it clear what went on, but you don't want to flood your logfiles with chaff.
One common thing is to make your logging dynamic - you can adjust it on the fly, so that if an error is recurring, you can turn it up to get more detail. For this to work, you need to define various levels of logging to present, and have a means to store the current level of presentation. Another facet of logging is the files the logs are written to. UNIX system have the syslog() facility, which is good for serious issues - ones that may shut down the system, or cause complete failure, like full disks, etc.
But it can be a pain to fill up a system file with the minutae of your most verbose debug level, so the best is probably to route logs to a file under your control. Of course, it goes without saying that you should have a file aging system in place to keep the file from growing too large, and having too many old ones.
There is usually a debate about how logging levels should be managed - as increasing levels, or as bit flags to cover areas like disk I/O, database access, RPC communications, etc. It's something of a judgment call, but make a set of categories and enforce it across all processes in the system, or you'll have chaos.
If you go with levels, you'll have the question of how many levels. There are a number of logging systems that use levels, and if you are using a language with such a facility, use those levels. If not, look to one of them for suggestions.
Have a command-line utility to adjust logging levels, so that if you have to go in remotely you can change things - there's nothing worse than having to wake up a site staffer just to navigate to a single GUI and click one button.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Monday, February 02, 2009
Test Driven Design examples
I had a post planned out to cover TDD in some detail, but I got about halfway into it when I realized that since I don't get to do enough of it, I'd be better off (actually, you'd be better off) if I pointed you at someplace where it gets done more often, recent events notwithstanding.
Two of the big problems I have with TDD are
Now, some languages make it a little easier - Java and Python, for example, allow you to add a main() to every file, so that you can invoke each class with a set of test parameters from the start. This will serve to bootstrap your test scaffolding in most cases, since you can make all your classes callable from their own main(), and have some tests there. As your application grows, you can eliminate the test main() from more of the classes as you pull methods into patterns, allowing you to move the tests from the original file to the new one.
If you're using C++. however, you're in a bind. You can't have more than one main, and you need it for your actual program. A way around this is to make a class that is the core of the process, and have the main() be a shell, calling the constructor of that class, and possibly a start method, as the whole of the function. Again, as your codebase grows, you can move the test code around as necessary.
If you've got a mess of code already, with now tests, your best bet is to start with the interfaces. Anywhere there is a API - RPC, SOAP, TCP/IP, etc - you can write a program to provide either end of the connection, and start building a test harness from that. Use scripts to run the basics, testing every message with good and bad data. If you have an API at each end of the process, you can connect both end to a single program to allow it to confirm success/failure of any given message. A tool like netcat can be useful for this - your individual test programs can have a socket sending text datagrams to each other with results.
A caution - this can get interesting enough to consume all your spare time - it's a lot more fun to make things that you can see working than to be wading through spaghetti code that needs refactoring but lacks tests for checking functionality, so enforce some limits on your test scaffold building, unless you have a mandate from your management to build the test sets.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Two of the big problems I have with TDD are
- How to get started on a project with it, and
- How to get it going if you've got a mess of code already
Now, some languages make it a little easier - Java and Python, for example, allow you to add a main() to every file, so that you can invoke each class with a set of test parameters from the start. This will serve to bootstrap your test scaffolding in most cases, since you can make all your classes callable from their own main(), and have some tests there. As your application grows, you can eliminate the test main() from more of the classes as you pull methods into patterns, allowing you to move the tests from the original file to the new one.
If you're using C++. however, you're in a bind. You can't have more than one main, and you need it for your actual program. A way around this is to make a class that is the core of the process, and have the main() be a shell, calling the constructor of that class, and possibly a start method, as the whole of the function. Again, as your codebase grows, you can move the test code around as necessary.
If you've got a mess of code already, with now tests, your best bet is to start with the interfaces. Anywhere there is a API - RPC, SOAP, TCP/IP, etc - you can write a program to provide either end of the connection, and start building a test harness from that. Use scripts to run the basics, testing every message with good and bad data. If you have an API at each end of the process, you can connect both end to a single program to allow it to confirm success/failure of any given message. A tool like netcat can be useful for this - your individual test programs can have a socket sending text datagrams to each other with results.
A caution - this can get interesting enough to consume all your spare time - it's a lot more fun to make things that you can see working than to be wading through spaghetti code that needs refactoring but lacks tests for checking functionality, so enforce some limits on your test scaffold building, unless you have a mandate from your management to build the test sets.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, February 01, 2009
How DO You Get To Carnegie Hall?
I've mentioned Code Katas before, and practice, and I found this recently, from ORA, and while it wanders into general learning theory, it covers the idea that you need to practice code to get better, and that you need to be reviewing your code to see where you went wrong (rather like sports teams reviewing the game footage for pointers, or fighter pilots reviewing dogfight radar records).
So when you have a moment, try rewriting a small module of your current project, using a new data structure, or with only library functions.
(Also, a milestone for the blog - 100 posts!)
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
So when you have a moment, try rewriting a small module of your current project, using a new data structure, or with only library functions.
(Also, a milestone for the blog - 100 posts!)
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Pithy Sayings
Here's a few good quotes about software. I especially like #s 1, 3, and 6, notwithstanding #6 is from Bill Gates
Given Microsoft's code bloat, I wonder if he's changed his mind?
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Given Microsoft's code bloat, I wonder if he's changed his mind?
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Saturday, January 31, 2009
Playing Hurt - Can you sprain your corpus callosum?
As s long-time reader of the C2 wiki, I was pleasantly surprised to find another blogger who referenced it in a post about Playing Hurt. Now, in comparison to, say, pro football players (American football), who play in freezing weather with sprained ankles, cracked ribs, and minor concussions, the "hurt" a programmer experiences is small potatoes. On the other hand, since what we do is nearly 100% mental
("95% of this game is half mental" -- Yogi Berra), our "hurt" is all mental.
The leading issues are burnout and overload. Burnout is the end result of chronic overload, but can also be caused by other things, like continual dismissal of complaints about bad process, lots of time working on projects that go nowhere, lack of recognition, the host of typical workplace issues, and
conflicting priorities (aka matrix management)
Now, there is not anything conclusive that shows that playing hurt in Software Development leads to drastically worse software. It's fairly clear that your product will be lower than your best, but nothing that shows it will be in the bottom half of your ability. However, you will find that over time, your lower quality will snowball into larger problems.
Possible solutions are:
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
("95% of this game is half mental" -- Yogi Berra), our "hurt" is all mental.
The leading issues are burnout and overload. Burnout is the end result of chronic overload, but can also be caused by other things, like continual dismissal of complaints about bad process, lots of time working on projects that go nowhere, lack of recognition, the host of typical workplace issues, and
conflicting priorities (aka matrix management)
Now, there is not anything conclusive that shows that playing hurt in Software Development leads to drastically worse software. It's fairly clear that your product will be lower than your best, but nothing that shows it will be in the bottom half of your ability. However, you will find that over time, your lower quality will snowball into larger problems.
Possible solutions are:
- discuss better work conditions with your boss - more input into schedules, process improvements, better recognition
- find another job - not that it's any better anywhere else, but the change in environment and the learning you have to do will make you feel better.
- a side project - pick something you want to fix at your job, and start carving out an hour or two a week to work on it. Maybe it's test harnesses for your systems, or automating a build, or just learning about another part of the system. Try to find something fun to do.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Friday, January 30, 2009
Probabilities and Innumeracy
As part of the National Too Much Information Week, I'm explaining some of my blogging habits. I have a few searches looking for interesting posts in the blogosphere, and a feed reader across a number of programming-relevant sites, and I glean interesting posts from them as fodder for my posts. It's my small part of making sure the blogs are a self-referential recursive rabbit hole.
I read this a few weeks ago, and having taken a number of math and biology classes in my years, immediately saw that the correct answer was 2/3s. But reading the comments really depressed me. Not because so many people jumped to the naive conclusion of 1/2, but that they are seemingly resistant to learning why the naive answer is wrong.
I'm not talking about the people who take the "commonsense" approach that the father saying "One of them is a girl" meaning "only one" is a girl - most of them seem to agree that is a semantic issue. But those that continue to insist that with 4 outcomes, the odds of 2 of them don't add is just dumbfounding.
Just for those not wanting to just through the long discussion, here's the short form correct answer:
Dad says "I have 2 kids, and one of them is a girl. What are the odds that I have one son?"
the grid:
1st B 1st G
2nd B BB GB
2nd G BG GG
That is the sum total of possibilities for the family makeup
Now, the odds of a given child being male is 50% (overall, ignoring the slight differences of survival, etc), so each "box" of the grid has a 25% chance of being the "real" family makeup. But Dad says he's got one girl, so we can exclude the upper left box, leaving 3 boxes each with 25% chance. Now, note that there are 2 boxes with mixed kids, and one with only girls, so the odds of having a boy are 2/3s.
[Edit]
I think I have found the problem that everyone who says 50% is running into - they are flipping the meaning of "one of them is a girl" - they are taking this to mean they get to pick one of the BG or GG cells, but they can't do that with an even probability - all they can really do is exclude the BB cell. In other words "one of them is a girl" only uniquely identifies a single cell for exclusion.
[later edit]
Here's a small Python program that details the logic, and shows how the bad assumptions work. It's especially useful because the bad assumptions play directly to the numbers of boys and girls in the generated families. (some lines got folded, so if you cut&paste this, be awa
# 2kids - run simulations to test
# generate 1000 random 2-kid families
# 0 = boy, 1 = girl
import random
# generate child
def genChild():
sex = random.random()
if sex < 0.5:
return 0
return 1
# define Family class
class Family:
def __init__(self):
self.genFamily()
# generate family
def genFamily(self):
self.child1 = genChild()
self.child2 = genChild()
# see if there is at least one girl
def hasAGirl(f):
if(f.child1 == 1 or f.child2 == 1):
return 1
return 0
# see if there is a boy
def hasABoy(f):
if(f.child1 == 0 or f.child2 == 0):
return 1
return 0
random.seed()
familyList = []
for f in range(1000):
familyList.append(Family())
allBoys = 0
allGirls = 0
for family in familyList:
if(family.hasAGirl()):
if(family.hasABoy()):
pass
for family in familiesWithGirls:
if(family.hasABoy()):
brothers3 +=1
print "# of families with 1 or more girls that have one boy = ",brothers3
print "% of families with 1 or more girls that have one boy = ", ((1.0 * brothers3) / en(familiesWithGirls)) * 100
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
I read this a few weeks ago, and having taken a number of math and biology classes in my years, immediately saw that the correct answer was 2/3s. But reading the comments really depressed me. Not because so many people jumped to the naive conclusion of 1/2, but that they are seemingly resistant to learning why the naive answer is wrong.
I'm not talking about the people who take the "commonsense" approach that the father saying "One of them is a girl" meaning "only one" is a girl - most of them seem to agree that is a semantic issue. But those that continue to insist that with 4 outcomes, the odds of 2 of them don't add is just dumbfounding.
Just for those not wanting to just through the long discussion, here's the short form correct answer:
Dad says "I have 2 kids, and one of them is a girl. What are the odds that I have one son?"
the grid:
1st B 1st G
2nd B BB GB
2nd G BG GG
That is the sum total of possibilities for the family makeup
Now, the odds of a given child being male is 50% (overall, ignoring the slight differences of survival, etc), so each "box" of the grid has a 25% chance of being the "real" family makeup. But Dad says he's got one girl, so we can exclude the upper left box, leaving 3 boxes each with 25% chance. Now, note that there are 2 boxes with mixed kids, and one with only girls, so the odds of having a boy are 2/3s.
[Edit]
I think I have found the problem that everyone who says 50% is running into - they are flipping the meaning of "one of them is a girl" - they are taking this to mean they get to pick one of the BG or GG cells, but they can't do that with an even probability - all they can really do is exclude the BB cell. In other words "one of them is a girl" only uniquely identifies a single cell for exclusion.
[later edit]
Here's a small Python program that details the logic, and shows how the bad assumptions work. It's especially useful because the bad assumptions play directly to the numbers of boys and girls in the generated families. (some lines got folded, so if you cut&paste this, be awa
# 2kids - run simulations to test
# generate 1000 random 2-kid families
# 0 = boy, 1 = girl
import random
# generate child
def genChild():
sex = random.random()
if sex < 0.5:
return 0
return 1
# define Family class
class Family:
def __init__(self):
self.genFamily()
# generate family
def genFamily(self):
self.child1 = genChild()
self.child2 = genChild()
# see if there is at least one girl
def hasAGirl(f):
if(f.child1 == 1 or f.child2 == 1):
return 1
return 0
# see if there is a boy
def hasABoy(f):
if(f.child1 == 0 or f.child2 == 0):
return 1
return 0
random.seed()
familyList = []
for f in range(1000):
familyList.append(Family())
allBoys = 0
allGirls = 0
for family in familyList:
if(family.hasAGirl()):
if(family.hasABoy()):
pass
else:
allGirls += 1
else:
if(family.hasAGirl()):
pass
else:
allBoys +=1
print "Family breakdown: BB = ", allBoys, " GG = ", allGirls," mixed = ", 1000 - (allBoys + allGirls)
brothers1 = 0
for family in familyList:
if(family.hasAGirl()):
if(family.hasABoy()):
brothers1 += 1
print "filter by hasAGirl first, then hasABoy, number of familes with boys = ", brothers1
brothers2 = 0
for family in familyList:
if(family.hasAGirl() == 0):
pass
allGirls += 1
else:
if(family.hasAGirl()):
pass
else:
allBoys +=1
print "Family breakdown: BB = ", allBoys, " GG = ", allGirls," mixed = ", 1000 - (allBoys + allGirls)
brothers1 = 0
for family in familyList:
if(family.hasAGirl()):
if(family.hasABoy()):
brothers1 += 1
print "filter by hasAGirl first, then hasABoy, number of familes with boys = ", brothers1
brothers2 = 0
for family in familyList:
if(family.hasAGirl() == 0):
pass
if(family.hasABoy()):
brothers2 += 1
print "filter by !hasAGirl first, then hasABoy, number of familes with boys = ", brothers2
print "filtering by eliminating all-boy families first"
brothers3 = 0
familiesWithGirls = []
for family in familyList:
if(family.hasAGirl()):
familiesWithGirls.append(family)
print "# of families that have 1 or more girls = ", len(familiesWithGirls)
brothers2 += 1
print "filter by !hasAGirl first, then hasABoy, number of familes with boys = ", brothers2
print "filtering by eliminating all-boy families first"
brothers3 = 0
familiesWithGirls = []
for family in familyList:
if(family.hasAGirl()):
familiesWithGirls.append(family)
print "# of families that have 1 or more girls = ", len(familiesWithGirls)
for family in familiesWithGirls:
if(family.hasABoy()):
brothers3 +=1
print "# of families with 1 or more girls that have one boy = ",brothers3
print "% of families with 1 or more girls that have one boy = ", ((1.0 * brothers3) / en(familiesWithGirls)) * 100
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Friday, January 23, 2009
Why We Need Programmers
Every few years, it seems, there's another push to obsolete programmers. Sometimes it's overt, like COBOL was ("We'll make it so the businessmen can just say what they want done!"), and sometimes it's more subtle, but it always gets attention from the industries that depend on programmers.
The problem with all these efforts is that we're still a long way from being able to take a fuzzy natural language description of the desired solution and turn that into a working program. That means that someone who is not a programmer has to write the code for the program in some programming language. And that leads to all sorts of issues:
Programmers will have the background to recognize O(n2) algorithms; they will be familiar with the tools like code versioning systems and parsers; they will have passion for the code itself, so that it will be easy to maintain and modify.
I guess it's rather like plumbing. It's not hard for a homeowner to run a little length of drainpipe, but when it gets to plumbing a whole house, or handling a sewer connection, they prefer to use a professional.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
The problem with all these efforts is that we're still a long way from being able to take a fuzzy natural language description of the desired solution and turn that into a working program. That means that someone who is not a programmer has to write the code for the program in some programming language. And that leads to all sorts of issues:
- Naive code - someone who has not learned about programming practices will write code that is difficult to learn and modify.
- Incomplete or inefficient programs - someone who has not studied programming will lack knowledge of algorithms, and will lack experience of gap analysis.
- Just plain shoddy work - the erstwhile programmers will not want to be programming, because they want to be solving their real problems.
Programmers will have the background to recognize O(n2) algorithms; they will be familiar with the tools like code versioning systems and parsers; they will have passion for the code itself, so that it will be easy to maintain and modify.
I guess it's rather like plumbing. It's not hard for a homeowner to run a little length of drainpipe, but when it gets to plumbing a whole house, or handling a sewer connection, they prefer to use a professional.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, January 18, 2009
More on Offshoring and Its Perils
As my reader(s) know(s) [Hi Brian!], I'm way behind on my "interesting idea for a blog post" list, so I may be pumping a lot of relatively short posts out to try and get back up to the current set of items.
Anyway, I saw this post about offshoring, written by a developer in India, and I felt it worthy of mentioning, as it rings true - contractors never feel as close to project as full-time employees do, and the more remote the home office, the less involved even the employees feel. (look for the letter from the guy from London)
Adding to this is that nowadays, most of the Indian developers are available through the big consulting houses, so you get even less identification with the project, and more opportunities for corporate shenanigans that derail projects.
Of course, there is always the option of hiring directly, but that runs into the problem of scale. In the US, a job posting might get 100 resumes; 50 can be dumped right away for totally wrong qualifications, 25 for inadequate skills, 15 weeded out in the phone interviews/standardized tests, and the final 10 interviewd face-to-face and the best picked. However, in India, that same job posting might bring in 1000 candidates, and unless you have 10X the interview staff, you cannot get it winnowed down to the best 10 people - you might get it down to 100, interview 50, and hope for the best.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Anyway, I saw this post about offshoring, written by a developer in India, and I felt it worthy of mentioning, as it rings true - contractors never feel as close to project as full-time employees do, and the more remote the home office, the less involved even the employees feel. (look for the letter from the guy from London)
Adding to this is that nowadays, most of the Indian developers are available through the big consulting houses, so you get even less identification with the project, and more opportunities for corporate shenanigans that derail projects.
Of course, there is always the option of hiring directly, but that runs into the problem of scale. In the US, a job posting might get 100 resumes; 50 can be dumped right away for totally wrong qualifications, 25 for inadequate skills, 15 weeded out in the phone interviews/standardized tests, and the final 10 interviewd face-to-face and the best picked. However, in India, that same job posting might bring in 1000 candidates, and unless you have 10X the interview staff, you cannot get it winnowed down to the best 10 people - you might get it down to 100, interview 50, and hope for the best.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, January 11, 2009
The Good, The Bad, and It's Gonna Get Ugly
(with apologies to Sergio Leone)
While browsing over the past few weeks, I've run across several articles discussing the relative skill levels of developers and the effects of having differing skill levels in your team.
Jay Fields expounds his opinion of Net Negative Producing Programmers (NNPPs), but his solution is to avoid working with them, which is not very practical for most of us who are not freelance programmers.
Over on It's Common Sense, Stupid, Jay's position is accepted, but his conclusion is not. But the suggestions made are of a similar line - avoid NNPPs if you can, only the way companies work today, you can't make it any better. But another post there addresses the reason companies don't fire NNPPs - they can't tell who they are. Code quality is not visible - and the metrics managers try to use to measure it are easily subverted.
Of course the biggest problem about going to managers about NNPPs is that you might be seen as a cocky developer.
If you think you are the best developer in your group, and you feel that you are surrounded by NNPPs, you need to consider how you come across to your coworkers. If they don't like you, your manager will probably not be able to tell that you are better, and will agree with their opinion.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
While browsing over the past few weeks, I've run across several articles discussing the relative skill levels of developers and the effects of having differing skill levels in your team.
Jay Fields expounds his opinion of Net Negative Producing Programmers (NNPPs), but his solution is to avoid working with them, which is not very practical for most of us who are not freelance programmers.
Over on It's Common Sense, Stupid, Jay's position is accepted, but his conclusion is not. But the suggestions made are of a similar line - avoid NNPPs if you can, only the way companies work today, you can't make it any better. But another post there addresses the reason companies don't fire NNPPs - they can't tell who they are. Code quality is not visible - and the metrics managers try to use to measure it are easily subverted.
Of course the biggest problem about going to managers about NNPPs is that you might be seen as a cocky developer.
If you think you are the best developer in your group, and you feel that you are surrounded by NNPPs, you need to consider how you come across to your coworkers. If they don't like you, your manager will probably not be able to tell that you are better, and will agree with their opinion.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Thursday, January 08, 2009
The Impossible, We Do Right Away....
Yesterday I was reminded of this post. Some people do not understand how things work. Even my upper management.
They want a change of the program's behavior, but they don't want the cost of that change - they don't want to run their tests, or restart their timetables. They want you to somehow make the error go away without making them do anything different, and when you tell them that it's impossible, somehow you are evil from not trying.
If you face this often, you'll need to start programming defensively - making your programs as data-driven as possible, so that you can change behavior without changing code. Now, this obviously fails to help when the problems are code issues (threading, loop limits, etc) - so you'll still need to be ready to deal with the nonsense.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
They want a change of the program's behavior, but they don't want the cost of that change - they don't want to run their tests, or restart their timetables. They want you to somehow make the error go away without making them do anything different, and when you tell them that it's impossible, somehow you are evil from not trying.
If you face this often, you'll need to start programming defensively - making your programs as data-driven as possible, so that you can change behavior without changing code. Now, this obviously fails to help when the problems are code issues (threading, loop limits, etc) - so you'll still need to be ready to deal with the nonsense.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Monday, January 05, 2009
No More Brook's Law?
Every programmer worth his/her salt knows of Brook's Law, from his book The Mythical Man-Month,
and by and large, we tend to agree with it. But this post points out that there may be new tools and methods in software development that may show a way past Brook's Law.
The main factors in this are the open source movement, the leverage of the better languages, and the better understanding of the effects of software interactions.
Open source allows developers to know more about the code by examination than was previously typical. Even in the proprietary world, internal developers expect access to the code they work with.
Better languages are simply an order of magnitude (or more) better than the older languages - we can know access a web page in a single line of code; we have built-in data structures that we can use without having to build linked lists, hash tables, etc. We are able to encapsulate more behavior in less code.
The better understanding of software interactions has allowed us to make better software - we know to separate concerns; we know to build software in layers; we know to make data-driven modules that can handle generic cases or special cases with impunity.
That said, we haven't eliminated the problem, we've just made it small enough to be lost in the noise given the complexity of software we currently develop.
And not all of us work in places and on systems where we get to take advantage of all these new toys. Many of us are still working with lower-level languages, on systems that are too big to get the comprehension of, with unreasonable deadlines.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
and by and large, we tend to agree with it. But this post points out that there may be new tools and methods in software development that may show a way past Brook's Law.
The main factors in this are the open source movement, the leverage of the better languages, and the better understanding of the effects of software interactions.
Open source allows developers to know more about the code by examination than was previously typical. Even in the proprietary world, internal developers expect access to the code they work with.
Better languages are simply an order of magnitude (or more) better than the older languages - we can know access a web page in a single line of code; we have built-in data structures that we can use without having to build linked lists, hash tables, etc. We are able to encapsulate more behavior in less code.
The better understanding of software interactions has allowed us to make better software - we know to separate concerns; we know to build software in layers; we know to make data-driven modules that can handle generic cases or special cases with impunity.
That said, we haven't eliminated the problem, we've just made it small enough to be lost in the noise given the complexity of software we currently develop.
And not all of us work in places and on systems where we get to take advantage of all these new toys. Many of us are still working with lower-level languages, on systems that are too big to get the comprehension of, with unreasonable deadlines.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Subscribe to:
Posts (Atom)