You Want IT When?

When I was a child, I had a strong aversion to pineapples.  Just the look of them made me ill.  It didn’t matter whether it was cut or uncut; there was just something about the look that made me believe I would not like the taste.  Maybe it was the color yellow, but there was something terribly unappealing about the fruit, and no matter how much my mom would entice me with declarations of how sweet it taste, I would not try it.

I felt the same way about cranberry sauce too.  It was an emotional aversion; there was nothing logical about it even though I was convinced my reasons were all logical.  Cranberry sauce looks slimy; slimy is disgusting; therefore, it must taste like it looks: disgusting.  It’s a logical inference; though, it has little relevance to how cranberry sauce actually tastes.

As I got older, I became more open to giving foods a try (and other things, of course) that were unappealing to me.  When I finally gave pineapples and cranberry sauce a try, I discovered how I’d been missing out for so long on enjoying a food that was so pleasurable to me.

Much of the software community has a similar aversion to LOC. Many of their arguments against LOC are logical, but they aren’t relevant to the science and practice of LOC as advocated by its adherents.  Sure one can write a line of code with more defects than ten lines of code, but the Law of Big Numbers says the density observed in practice will be the expected value.

(more…)

During a presentation on software metrics, I asked the audience to estimate the distance from New York, NY to Sante Fe, New Mexico in Kilometers (they were asked not to participate if they already knew the answer), and I asked them not to do any conversions in their head before giving their answer.  For those of you reading in other countries, we use miles to measure long distances in the USA, so kilometers is a unit that we don’t have much experience using.   The answers to the question were all over the place with most of them being overestimates of signification magnitude, double or more.  Then I asked the audience to estimate the distance again, but this time, they were to estimate the distance in miles - a unit they were all very familiar with.  These estimates were much better with all being less than 20% away from the actual distance.   Some were so close to the actual distance that they were essentially accurate.

(more…)

What if you could be more accurate in your software estimates?  What if you could gain more control over your project schedule? What if you could improve your product quality and know that you did before your customer received the product?  Okay, now that I have you’re attention, if I told you that metrics was the key to realizing these goals, will you continue reading?  If a software team is ever going to improve successfully and repeatedly in these areas, they will need to embrace metrics.

(more…)

What’s your worst fear as a software professional? My worst fear is changing jobs and joining a team that is in crisis. You’ve probably been part of a team, heard about a team or witnessed another team in your company deliver to one of those unrealistic schedules.  Often times, the project starts off right, but entropy slowly builds as changes are introduced to the schedule with the velocity of an open fire hydrant.  It doesn’t start that way: it builds with a crescendo.  It’s not a case of replacing the old water with new water; it’s a case of filling a pool that’s filled 98% of capacity while watching the water spill over the sides and drain into the streets.

It’s not the fear of working hard, long hours, or getting my hands dirty that concerns me - in fact I find crisis invigorating - it’s whether I’ll be empowered to make the changes required to right the ship that concerns me most.  There’s nothing like the feeling of dread when participating in an endeavor that controls your life because the leadership is making mistaken decisions that you believe are the root cause of your undesirable circumstances: the kind of decisions that dig the project into a deeper and deeper hole.

Well it happened to me when I started a new job as a Software Development Manager in 1999.  When I arrived at the office on that first Monday, I was the first one to arrive, and when the first veteran employee arrived, he greeted me with the traditional first hellos and said, “yeah, the guys will be strolling in late today, they just worked through the weekend.”  I knew instantly that things were going to be interesting, and I was not to be disappointed.

(more…)

I often wonder why software teams always seem to be committing to unrealistic schedules.  You know when the sales team signed a contract with a customer to deliver functionality on a date without ever asking the engineering team whether it were possible. Never mind the roadmaps identify an entirely different set of functionality than what was committed. And guess what?  The product roadmaps can’t change either; the sales team has signed contracts on that functionality too.

It’s not just the sales organizations though; the software organizations are all too happy to over commit without any help from outsiders.  You probably have one of those programmers on your team that when you ask him for an estimate, he says a week and three months later he’s still working on it.  When you ask him what happened, his answer is well it was a bit more complicated than I thought.  Does he learn from it? No way. Ask for an estimate on the next project, and he’ll still quote a week.

(more…)

It happened when I participated for the first time on a SEI/CMM process improvement initiative at my employer.  That’s when I realized the power of software metrics.  Instead of handing us a ready made process to follow, each of the different product organizations were tasked with the objective of developing their own processes with the goal of achieving Level 2 certification.   Each group formed teams around the key process areas (KPA) to develop the practices to be followed.  It was without a doubt the best process improvement experience of my career changing the way I manage and view software management permanently.  

When the process areas were complete, it was then my responsibility as a Technical Project Leader to use the processes developed on the implementation of my next assignment.  While there was skepticism with the initiative, the organization I worked in decided that they were going to support it and give it a good college try, and we did.  Some organizations simply wrote the procedures and loosely followed their processes, which is more often the case.

That’s when the epiphany happened.  One of the key principles for estimating is to first size the project and permute the size into a duration using historical data or industry standard data when no historical data exists.   Since we never recorded this type of data before, we used industry standard data, or what we believed to be.   Once the estimates were developed and work began, the power of that approach revealed itself when I began to track the project.  The tracking KPA required that all estimating assumptions be tracked, both time and size.

(more…)

It’s interesting to learn what pieces the readers are most reading on this blog.  It’s typical that what the author thinks will generate the most interest is different than what the readers find most interesting.  This has certainly been my experience.  “Why Software Process Adoption Fails” has been the most read essay.  It by far has the most clicks beating the next closest essay by a 2 to 1 margin, which is “No Pain, No Gain.“  When I wrote it, I thought it captured well my experiences at adopting process in the companies where I had worked.  Frankly, I didn’t expect it to be as popular, but it’s not surprising given the feelings about process in the software community.

(more…)

“Another 30 defects uncovered yesterday,” reports the QA Lead.  “Ten defects were fixed,” reports the Tech. Lead.  Taken alone these are alarming statistics, and if they persist long enough, the release date would certainly be in jeopardy.

Many software teams struggle through the QA phase with great anxiety as they normally work through the phase without a compass: nothing to tell them whether they are on track or not.  How many defects are left?  Will we be able to fix all the defects before the release date?  Will we find all the defects before the release date?  These are a few of the questions that teams have anxiety about.  It’s only until a few weeks before the planned release date that they come to grips with the realization that they are in trouble.

(more…)