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:

1. discuss better work conditions with your boss - more input into schedules, process improvements, better recognition
2. 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.
3. 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

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

         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

    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)

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

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:

1. Naive code - someone who has not learned about programming practices will write code that is difficult to learn and modify.
2. Incomplete or inefficient programs - someone who has not studied programming will lack knowledge of algorithms, and will lack experience of gap analysis.
3. Just plain shoddy work - the erstwhile programmers will not want to be programming, because they want to be solving their real problems.

The explosion of spreadsheets and database query languages exposed many domain experts to a small facet of programming, and as studies have shown, most people think they are more competent at things than they really are, and the least competent are really bad at seeing their cluelessness.

Programmers will have the background to recognize O(n²) 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

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

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

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

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