This is an amusing folk tale (a modernized version) that I
found thought provoking. It picked it up from a leadership article I was
reading about awarding productivity. I don't really know who originally authored it, though I suspect it originates from an old folk tale for children. If anyone knows, drop me a note and I'll add some credits.
The Little Red Hen
Once upon a time, there was a
little red hen who scratched about the barnyard until she uncovered some grains
of wheat.
She called her neighbors and said,
"If we plant this wheat, we shall have bread to eat. Who will help me
plant it?"
"Not I," said the cow.
"Not I," said the duck.
"Not I," said the pig.
"Not I," said the goose.
"Then I will," said the
little red hen, and she did.
The wheat grew tall and ripened
into golden grain. "Who will help me reap my wheat?" asked the little
red hen.
"Not I," said the duck.
"Out of my
classification," said the pig.
"I'd lose my seniority,"
said the cow.
"I'd lose my unemployment
compensation," said the goose.
"Then I will," said the
little red hen, and she did.
At last it came time to bake the
bread. "Who will help me bake the bread?" asked the little red hen.
"That would be overtime for
me," said the cow.
"I'd lose my welfare
benefits," said the duck.
"I'm a dropout and never
learned how," said the pig.
"If I'm to be the only helper,
that's discrimination," said the goose.
"Then I will," said the
little red hen.
She baked five loaves and held them
up for her neighbors to see. They wanted some and, in fact, demanded a share.
But the little red hen said,
"No, I can eat the five loaves."
"Excess profits!" cried
the cow.
"Capitalist leech!"
screamed the duck.
"I demand equal rights!"
yelled the goose.
And the pig just grunted.
And they painted "unfair"
picket signs and marched around and around the little red hen, shouting
obscenities.
When the government agent came, he
said to the little red hen, "You must not be greedy."
"But I earned the bread,"
said the little red hen.
"Exactly," said the
agent. "That is the wonderful free enterprise system. Anyone in the
barnyard can earn as much as he wants. But under our modern government
regulations, the productive workers must divide their product with the
idle."
And they lived happily ever after,
including the little red hen, who smiled and clucked, "I am grateful. I am
grateful."
But her neighbors wondered why she
never again baked any more bread.
They believed it would help make personal computing less expensive, because Google would give away the software free of charge. They wanted to shrug off 20 years of accumulated software history (what the information technology industry calls the "legacy") by building an OS and browser from scratch. Finally, they hoped the combined technology would be an alternative to Microsoft Windows and Internet Explorer, providing a new
Google clearly has the clout and money to pull this off but can they build something compelling enough to get millions of users to switch to a new OS? I would certainly be willing to explore a new operating system developed by Google but I'm also unwilling to give up the familiarity of Microsoft Office and the other day-to-day tools I use to do my job. Yes, there will be substitutes for most of those products but the fact is that they will probably be pale in comparison. A good example is OpenOffice -- a great office automation package but, I'm sorry, it's a long ways away from Microsoft Office. So, Google has a pretty tall order in front of them and they'd better be in it for the long haul if they have any hope of success.
In my last article (Agile Transition "Initiatives" - Just say no!), I talked about how Agile Transition Initiatives can fail because prescriptive processes are pushed on an organization through a program delivered as part of some named initiative and led by a process improvement group, Agile coaching group or external consulting firm. The work force appears to acquiesce with the initiative but in fact passively resists it because they believe t
An interesting article, by David Anderson, about making the "Agile Transition". At my workplace we're in the early stages of making this same transition. As an executive sponsor, it's something that I've generally approached in systematic way as a formal initiative. David's article suggests an alternative approach focused on the organizational culture. It's worth a read. For me, the verdict is still out on the best approach. I'm inclined to marry both the encouragement of cultural changes along with a a bit of a prescriptive approach.
In a deft act of genomic manipulation, researchers at the J. Craig Venter Institute, in Rockville, MD, transplanted a bacterial genome into yeast, altered it, and then transplanted it back into a hollowed bacterial shell, producing a viable new microbe. The technique may provide a way to more easily genetically engineer organisms not commonly studied in the lab and could aid in the expanding effort to create microbes that can produce fugenome e
ngineering
and opens new applications," says Jim Collins, a bioengineer at Boston
University, who was not involved in the research. "I see this asels or clean up toxic chemicals. "This research enhances our capabilities in an important advance relevant to the bioenergy and biomaterials industries."
When people think of Nano Machines, they typically picture tiny cell-sized robots made of metal, plastics, etc. I think the reality is that the first truly useful Nano Machines are likely to be biologically engineered. It's pretty clear that this field of science is accelerating at a dramatic pace. What does it mean? I believe we're going to see stunning leaps in our ability to treat diseases, internal injuries, and other health problems in the next two to three decades.
For good or bad, practical immortality could be just around the corner. You're starting to hear terms like "escape velocity" applied to human longevity. The theory is that, at some point, the acceleration in medical science will exceed our current life spans. So, no matter how old you get, there will be new medical breakthroughs that will keep you alive a bit longer. I wonder what the quality of life will be on a planet with 15 or 20 billion people? Will this type of medical care be accessible to everyone or just the rich? Are we going to be hiring armies of bio-software engineers in the future?
We're looking for a qualified software engineer with experience developing web-based applications in Java. If you think you've got the right stuff, take a look and submit your resume.
Neural networks have seen an explosion of interest over the last few years, and are being successfully applied across an extraordinary range of problem domains, in areas as diverse as finance, medicine, engineering, geology and physics. Indeed, anywhere that there are problems of prediction, classification or control, neural networks are being introduced. This sweeping success can be attributed to a few key factors:
This is a good introduction to Neural Networks. I have dabbled a bit with the development of simple neural network applications but I'm far from being an expert. It's fascinating stuff. When it comes to creating true Artificial Intelligence, I can't help feeling that we're just missing some critical ingredient that is probably more art than science.
I recently did a presentation at a user conference covering
the broad topic of Enterprise Project Portfolio Management (PPM).Much of what I had to say would read like “Mom
and apple pie” to anyone who has attempted to institutionalize a PPM process
within their organization. However, there was one particular slide that I
titled Going from “No data” to “Knowledge & Understanding” that
seemed to turn on a few light bulbs for folks so I thought I’d share that here.
One of the key success factors of deploying an enterprise
PPM process revolves around collecting data, turning that data into knowledge
and ultimately making decisions based on that knowledge. The challenge is that
for many organizations this process has a tendency to illuminate some rather
unpleasant facts about inefficiencies or other wasteful practices. If you’re a
change agent in your organization, this will immediately translate to “strong resistance”
in your mind. It’s a natural reaction
for most managers to initial question the legitimacy of the data when it doesn’t
fit their perception of reality.Fortunately the process of collecting and understanding the data tends
to follow a predictable path.
I’m going to loosely describe this path in the context of
building up a project portfolio but it can really be applied to just about any
organizational change that involves collecting and analyzing data for decision
making purposes.
Phase 1 – Data collection
Your data will likely be incomplete.There will be a lack of ownership – many executives
will distance themselves from the data if it doesn’t support their perceptions.The validity of the data will be challenged.
At this stage, you need to continue to collect data,
constantly improving the accuracy, and continue to put it in front of the eyes
of your executives.If they point out
that something looks inaccurate, go back and fix the source and show it to them
again.Eventually people will run out of
ways to poke any significant holes in the data and then you’re ready to move to
the next phase.
Phase 2 – Information
At this point, managers are starting to accept the validity
of the data and it’s taking on some real meaning.Getting to this point is likely to be one of
the most challenging periods of time if you’re the change agent. It’s at this
point where you begin to really shine a light on some of the dark recesses of
your organization.You’re going to find projects
in your portfolio that don’t make any sense; expenditures of resources that
aren’t aligned with the corporate strategy; expose differences between well ran
departments and poorly ran departments; etc.It will be shocking for some managers and a pleasant surprise for
others.The good news is that it
invariable creates an immediate thirst for more information.
Phase 3 – Knowledge &
Understanding
If you’ve made it this far, you’re doing well and the rest
of the ride is pretty much downhill. At
this point, most managers are accepting of the data and information being
presented to them and are starting to ask “How and why?” It’s at this point
where high-value decision start to be made.You’ll see fact-based prioritization decisions made; better alignment of
projects with corporate strategy; changes in resource allocation; and changes
in the behaviors of the organization.
Phase 4 – Growth &
Expansion
Ok, so really if you’ve gotten to phase 3 (see above) you
can legitimately claim success.Phase 4
is really a natural fallout of that success -- provided you are able to
maintain what you’ve worked so hard to achieve.It’s pretty common for organizations, at this point, to look for ways to
take your success and attempt to apply it to other parts of the
organization.For example, if you
implemented a PPM process within your Technology department you may find
yourself asked to do the same thing for the rest of the company.Great! More work for you!
E-mail protocols and spam filtering is something of a hobby
and I certainly have more expertise in that area than most folks. I’m someone
who receives close to 1,000 e-mails a day, of which 80-90% are spam. So, it’s a
problem that is near and dear to my heart. So, what do you do about it?
Spam is very much like some of the complicated human
diseases we face today, such as cancer or HIV. Clearly, there are rarely severe health consequences that
result from e-mail spam but what I’m talking about is the way these diseases mutate
and are often very difficult to treat.
Spam, is something that mutates almost as quickly as new
ways of filtering are developed. The people who propagate spam are
no fools and many of them are highly skilled programmers with a deep understanding
of how e-mail systems function. If you attack the problem with any one
solution, you’ll find that they quickly modify their approach to work around
that solution much in the same way that a complex disease might react to a
single medication. They key is to use a
combination of techniques or “drugs” to combat the problem on many different
levels all at the same time. Ok, this is as far as I’m going to take this
analogy … I promise!
So, in a practical sense, how does this apply to eliminating
spam from your inbox? Well, there are a number of different techniques that are
available to filter spam and the trick is employing 2, 3, or even more of these
techniques all at the same time. Below, I’m going to describe three broad
categories of spam filtering techniques that you can explore on your own – just
try Googling some of them and you’ll find a wealth of more detailed information.
Statistical Analysis
Statistical analysis is probably the one of the more
commonly used spam filtering techniques that you will find in use today. You’ll
also here terms such as heuristic, Bayesian, and others types of related analysis, which I loosely group under the category “Statistical Analysis”.
Essentially, this method of spam filtering relies on examining the headers and
content of the message and assigning a score or some sort of probability that
the message is spam. Based on that score, you can tell your e-mail software to
either accept, reject, or file the message in your junk mail folder.
SpamAssassin and DSPAM are two commonly used software applications that enable
this sort of filtering and are in wide spread use by many ISPs and e-mail
service providers.
In terms of effectiveness, you’ll see claims of anywhere
between 70% - 99% accuracy. Most of these systems are capable of learning over
time and improving their effectiveness. My personal experience is that you’re
doing pretty well if you are able to filter out 70% of the spam using this
technique alone. Unfortunately, that means you could still be receiving a lot
of spam that makes it into your inbox. However, it’s certainly a major step in the
right direction for most people.
Filtering
Filtering really isn’t a specific technology,
but generally refers to a suite of tools that ISPs and users can employ to
eliminate undesirable e-mail. In its simplest form, most e-mail clients (i.e.,
Outlook) support the ability to create rules that examine messages for specific
content and then take some sort of action – typically to delete the message. For
example, you can create a rule that looks for the word “mortgage” in the body
of the message and, if found, move the message to your junk mail folder.
More sophisticated systems, generally used by an ISP, might
allow users to filter out messages based on the originating geography. For example,
I really don’t expect to receive any personal e-mail from Asia so I block any
e-mail that originates from that part of the world – done by examining the originating IP
address. This is a technique that I
commonly refer to as Geo-IP filtering.
Another common technique, and probably more widely
available than Geo-IP filtering, is “Grey listing”. Grey listing relies on the fact that much of the
world’s spam is not sent by mail servers but rather viruses, Trojan programs,
etc. that have infected people’s PCs. Grey listing filters messages by
initially refusing to accept e-mail from a source that it has never seen
before. If the sending mail server is legit, it should attempt to resend the
message again. If it doesn’t, then you can be pretty sure it wasn't something you needed to read.
The effectiveness of this sort of filtering ranges broadly.
My personal experience is that using rules to do keyword searched in your
e-mail, at best, will only eliminate only 10% - 15% of the spam. Techniques
such as grey listing or Geo-IP are closer to 30% - 50% effective. You'd never want to use these techniques by themselves but they nicely compliment other techniques such as statstical analysis.
Challenge/Response
Challenge/response anti-spam includes a class of techniques
that eliminate spam by automatically challenging the sender to prove their
e-mail is legitimate. Typically this involves the receiveing system putting a hold on
their e-mail (so you never see it) and sending an e-mail back to the sender
asking them to click on a link or take some other action to verify their
authenticity. As soon as they respond, their original e-mail is released and
you get to see read it. Once a sender has authenticated themselves, their
e-mail address is added to a trusted “white list” so that they are no longer
challenged for any subsequent e-mails.
Challenge/Response systems are nearly 100% effective. So,
why isn’t it more widely used? Quite frankly, many ISPs and e-mail service providers
hate this solution. It’s a technique that often causes their systems to process
a lot more e-mail and uses more network bandwidth due to the added overhead of
the challenge aspect of this solution. In fact, there are some ISPs and e-mail
providers who have decided to treat challenges as a type of spam. The other drawback
is that spammers often forge the senders e-mail address to obscure their
identity. Unfortunately, if they happen to use your e-mail address then any
challenge message end up being sent to you. Of course, you’ll see the
challenge and have no idea why the heck it was sent and if you get
enough of them, you might find it down right annoying.
Personally, I think if challenge/response systems were
more widely adopted, it could be quite successful at reducing the overall
volume of spam. It’s a highly effective solution and there are many variations
that can make it very difficult for a spammer to get around without making a major economic investment. However, due
to the drawbacks discussed above, you’re not likely to see this approach widely
adopted anytime soon. Still, its one more tool you can put in your arsenal if you decide it's right for you.
Conducting performance evaluations on individual software developers
can prove a daunting challenge for even the most experienced manager. Unless
you’re working in some sort of Utopian organization where you have perfect
processes and perfect requirements, measuring the performance of your
development staff is likely to be very subjective. A key stumbling block is the
fact that the success of a software developer is often dependent on many variables
outside of their control. Som
e of those variables include things like the
quality of the software requirements; the level of collaboration from the
business sponsor; the availability effective development environment; etc. Yet,
every sizable software development shop seems to both their star players and those
that seem to fall short.
So, how do you measure their performance? There is no single
answer and one of the first things you should do is stop by your friendly Human
Resources department for some advice. If you don’t have an HR group, do a
little research and reading
online. You’ll find that there is no shortage of
opinions on this matter, from folks that want to measure the number of lines of
code per hour to those who claim it can’t be adequately measured.
Here are a few of my own thoughts on the matter:
Subjectivity is part of the equation – If you
were hoping for a purely objective way of measuring a developer’s performance,
forget it! Programming is both science and art, and it’s the artistic quality
that will always be subjective. That’s ok! If you’re a manager, you should
understand that agreement is not necessarily part of the equation. However, you
do need to be able to express what you like and don’t like about their work in
a way that will allow them to take corrective action.
There are things you can measure – It’s not all
art! For example, if you set an expectation that developers will unit test
their code, that’s a pretty black & white measure. They either did it or
they didn’t. As to the adequacy and quality of their testing, well, that’s a
different story – subjectivity again. Did they complete any required
documentation (e.g., design docs)? Hard deliverables, such as documentation are
easy things to measure.
Setting clear expectations is critical – If you
require your developers to do unit testing or prepare certain documentation,
then tell them! Better yet, put it down on paper and share your expectations
with the entire team. Make sure your team understands exactly what and how you
are going to be measuring their performance.
Provide near real-time feedback and document –
When an employee performance well, tell them! When they don’t perform well,
tell them! Simple, huh? I suggest, particularly when correcting negative
performance, that you document things using e-mail or some other written
mechanism. If you have an individual with chronic performance issues, having
written documentation is essential if you every reach the point where you are
making a termination decision. I also can’t stress enough how important the “real-time
feedback” aspect is in this process. If you wait more than about 24 hours to
provide feedback, the effectiveness is greatly reduced.
In the end, measuring whether a developer is
able to consistently deliver quality work on time is essential.The trick is how do you hold a developer
accountable for what is essentially an estimated level of effort? It’s an “estimate”
after all?!It’s a tough problem and the
key is to break things down to the point where most of the variables are in the
control of the developer. If you’re measuring a developer on completion of tasks
estimated to take more than about two or three days, you’re going to run into
problems. Generally, the longer the duration the more uncontrollable variables that
come into play – everything from dependencies on other developers to shifting
requirements. One of the things I like about most of the Agile development methodologies
is the way the team breaks down the work to be done in really small chunks,
typically measured in days or hours. If a developer says they are going to
finish implementing class XYX by tomorrow, that’s something I can measure them
on and I can reasonably expect the outcome to be in their control. True, there
are things that can still go wrong that isn’t their fault, but they are
generally easy to identify and understand (e.g., their workstation crashed).
If you’ve have some success stories or challenges you want
to share related to measuring software developer performance, I’d love to hear
from you! It’s a tough subject, with no shortage of opinions!
This is the third of five articles on organizational change that I'm
planning -- well, maybe there will be a sixth article but I'm not sure
anyone can stomach that much blathering on one topic. For reference
here are links to the two prior articles
“Grass
Root Initiatives” are generally productive and if you’re an
organization where these are prominent you’re probably in a pretty good
place. To be successful, grass root initiatives must be sponsored by
someone in the organizational with the resources and political clout to
help the process improvement team reach their goals. Typically the sponsor will be a senior level manager or executive.
Grass
root efforts generally enjoy the support of a fairly broad group of
employee and are much more likely to be successfully adopted than
purely top-down driven initiatives. It's something to be encouraged but
does require a bit of oversight to ensure they don't run amuck -- or
worse, get blown up by some moronic executive who doesn't understand
what the team is attempting to achieve. There are also a few negatives
that you will want to try and minimize:
Similar to Covert Operations, grass roots
type initiatives may not always be in clear alignment with the broader
organizational goals. Want to get blown up? Being grossly out of
alignment with the wishes of the senior executives, and it's just a
matter of time until someone lobs a grenade.
Progress
is often slow and enterprise-wide adoption can be very challenging.
Because there is very little stimulus for the entire organization to
change, improvements are often isolated to specific departments or
functional areas.
If you’re the executive sponsor of a
grass root initiative, it is critical that you examine the
organizational goals and ensure they are properly aligned with any
changes the team is pursuing. Fail to do so and you’re likely to run
into stiff resistance and some tough questions from senior level
executives at some point – forcing you to go covert or abandoning your
efforts. With a little storytelling and some good salesmanship, most
types of organizational changes can be aligned with company goals.
After all, most sane company encourages anything that will improve
efficiency and profitability if properly explained.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_b.png?x-id=e435d8f7-3d87-4dcf-b806-823a48ed3859)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_b.png?x-id=d6a3530d-c7c2-4470-9154-678bc3d4fde9)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_b.png?x-id=9256ce3d-a37c-4a35-aff9-a1fdf3750037)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_b.png?x-id=7ed03144-6297-48e0-8bff-6e0250ccd09d)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_b.png?x-id=9edf862f-b502-4d93-91c8-109ee5a6da7a)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_b.png?x-id=829b14b5-ed64-4aa9-8f39-069590f19d9d)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_b.png?x-id=bfb3a593-5e77-4106-9032-9fe5887ffb1f)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_b.png?x-id=9c9fce72-f150-47c1-8b37-1fdf0261e1d9)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_b.png?x-id=4c724d7f-7e1b-48ce-bf2e-1db9386ebc14)
