if your web application is using ReportViewer web control, it will throw the exception:The type Microsoft.ReportingServices.UI.WebControlConnection, ReportingServicesWebUserInterface, Version=188.8.131.52, Culture=neutral,
PublicKeyToken=89845dcd8080cc91 does not implement IReportServerConnection or could not be found
its your application inheriting appSettings from parent’s site web.config.
To resolve this, modify your applications’ web.config as
<remove key ="ReportViewerServerConnection"/>
<remove key ="ReportViewerTemporaryStorage"/>
In the The Mythical Man-Month, Fred Brooks highlights an eye opening disparity in productivity between good and poor programmers (emphasis mine).
managers have long recognized wide productivity variations between good
programmers and poor ones. But the actual measured magnitudes have
astounded all of us. In one of their studies, Sackman, Erickson, and
Grant were measuring performance of a group of experienced programmers. Within
just this group the ratios between the best and worst performances
averaged about 10:1 on productivity measurements and an amazing 5:1 on
program speed and space measurements!
Robert Glass cites research that puts this disparity even higher in his book Facts and Fallacies of Software Engineering.
The best programmers are up to 28 times better than the worst programmers,
according to “individual differences” research. Given that their pay is
never commensurate, they are the biggest bargains in the software field.
In other words, the best developers are generally underpaid and the worst developers overpaid.
don’t leave your job just yet. This is not to say that there should be
a 1 to 1 correlation between productivity and pay. People should be
paid by the value they bring and productivity is only part of the value
proposition, albeit a big part of it. Even so, we’d expect to see some
amount of correlation in pay with such a drastic productivity
difference. But in general, we don’t. Why is that?
It’s because most managers don’t believe this productivity disparity despite repeated verification by multiple studies. Why should they let facts get in the way of their beliefs? That would only mean the factonistas have won.
aside, why is this productivity difference so hard to believe? Allow me
to put words in the mouth of a straw-man manager.
Well how in the world can one developer write code 28 times faster than another developer?
This sort of thinking represents a common fallacy when it comes to measuring developer productivity. Productivity is not about the lines of code.
A huge steaming pile of code that doesn’t get the job done is not
productive. There are many aspects to developer productivity, but they
all fall under one main principle (borrowing a term from the finance industry), TCO.
In general, I’ve tried to always hire the best developers I can find. But I’ve made mistakes before. Yes, even me.
that comes to mind was with a developer I had hired (under a lot of
pressure to staff up I might add) at a former company. I handed off a
project to this erstwhile coworker to take over. A few days go by and I
don’t hear anything from the guy, so I assume things are humming along
Fast forward another few days and I swing by to see how
it’s going and the developer tells me he doesn’t understand a few
requirements and has been spinning his wheels trying to figure it out
this whole time.
is one of the first ways that good developers are more productive than
average developers. They take ownership of a project. Rather than spend
a week spinning wheels because they don’t understand a requirement, a
good developer will go and grab the decision maker and squeeze out some
Likewise, a good developer doesn’t require you to prod
them every few moments to make sure they are progressing. If they get
overly stuck on a problem, they’ll come to you or their coworkers and
resolve the problem.
A developer who can write code fast, but
doesn’t take ownership of their projects is not very productive because
they end up wasting your time.
once worked with a developer who was praised by my boss for being
extremely fast at writing code. He sure was fast! He was also fast at
introducing bugs into code. His code was sloppy and hard to understand.
key measure that wasn’t figured into his productivity measurement was
the amount of productivity lost by the QA team attempting to reproduce
bugs introduced by his code, along with the time spent fixing those
bugs by this developer or other developers.
Everyone focused on
his time to “completion”, but not on the total cost of ownership of
that code. Code is not complete when a developer says it is complete.
That is not the time to stop the stopwatch. It’s when QA has had its say that you can put the stopwatch away for the moment.
I like to say, productivity is not about speed. It’s about velocity.
You can be fast, but if you’re going in the wrong direction, you’re not
in hand with writing less bugs is writing understandable maintainable
code. As soon as a line of code is laid on the screen, you’re in
maintenance mode on that piece of code.
Code that is brittle and
difficult to change wastes hours and hours of developer cycles when
trying to amend a system with updates and new features. By writing
maintainable code, a good developer can make these changes more quickly
and also improves the productivity of his or her team members who later
have to work on such code.
Another hallmark of a good developer is that they know when not to write code. As a friend always tells me
Why build what you can buy? Why buy what you can borrow? Why borrow what you can steal?
a few exceptions, the NIH (Not Invented Here) syndrome is a
pathological productivity killer. I’ve seen developers start out to
write their own form validation framework until I point out that there
is already one built in to ASP.NET that does the job (It’s not perfect,
but it’s better than the one I saw being written).
All of that
time spent reinventing the wheel is wasted because someone else has
already written that code for you. And in many cases, did a better job
as it was their only focus. In such a situation, finding an existing
library that gets the job done can provide a huge productivity boost.
caveat in this case is to be careful to avoid non-extensible and rigid
3rd party libraries, especially for very specialized requirements. You
might a lot of time trying to fit a round peg in a square box.
when you must invent here, good developers tend to write less (but
still readable) code that does more. For example, rather than build a
state machine to parse out text from a big string, a good developer
might use a regular expression (ok, some will say that a regex is not readable. Still more readable than hundreds of lines of text parsing code).
Back to TCO
Each of these characteristics I’ve listed keeps the total cost of ownership of a good developer low. Please don’t let the term ownership distract you. What I mean here is the cost to the company for having such a developer on the payroll.
writing less code that does more, and by writing maintainable code that
has fewer bugs, a good developer takes pressure off of the QA staff,
coworkers, and management, increasing productivity for everyone around.
This is why numbers such as 28 times productivity are possible and
might even seem low when you look at the big picture.
seeing this perspective will convince managers that good developers
really are as productive as the studies show. Negotiating a 28x pay
increase on the other hand, is an exercise left to the reader.
Powered by ScribeFire.
Singing and speaking have everything in common—except for maybe really
good tunes. The main goal is to engage your audience and make them
listen to you, so everything a singer does, a speaker ought to do too.
Here are the absolute necessities of an engaging performance or
presentation that Doug compiled for me:
Circulate with your audience. Before every concert,
speech, and seminar, I try to mingle with the crowd, ask questions, and
let them know I’m glad they came. This isn’t always possible in the
real world, but when it is, I have an opportunity to feel a bond with
the people I’m about to perform for and undo some of the jitters that
are a natural part of being “on.”
Command attention. The breastbone (sternum) has to be
high if you want to project authority. You might want to pretend you’re
a rooster showing off. Relaxed sternum = loser, high sternum = winner!
Snarl. If people can’t hear you, they won’t listen to
you. Add some nasal resonance to your voice, but keep smiling. Snarl is
that nasal sound you get when you speak partially from your nose
instead of your mouth. It generates overtones above 2,800 cycles per
second that make any room “sing.” Pretend you’re trying to yell/warn a
child that’s about to run out in front of a bus—like yelling, “STOP!”
This works whether you’re using a microphone or speaking without one
Bite your tongue. If your mouth gets dry in the middle of
your presentation, try gently biting your tongue. Opera singers use
this all the time to release saliva which moistens your mouth.
Always perform a sound check before you speak. A good
sound person will adjust the EQ to your voice and its idiosyncrasies.
If you’re comfortable using a hand mike, do so—work close to the mike
and you’ll have a better chance of being heard. If you turn your head,
make sure you turn the mike with your head. Lapel mikes usually work
fine, but for softer speakers they’re very frustrating. Wrap-around
mikes (such as the AKG C520L—$159) that fit over your ear are the best
for intelligibility. If you speak often and you know your venues will
support this technology, buy a really good one and take it with you.
Use your eyes all the time. Hand gestures, pacing around
the platform can all be useful tools in presentation, but the eyes…ah,
the eyes have it! If you can’t engage people with your eyes you will
eventually lose your audience’s attention. Your eyes always tell people
whether or not you believe in what you’re saying! Scan the room, select
a person to make a point to, and look right at them. It’s a little
intimidating for them, but it keeps you focused on the individuals who
make up your audience. Keep moving to new people—right, left, middle—it
works! If all else fails, look at each person as though you’ve loved
him or her all your life—like mom, or your child.
Move away from center to make your point. When you come
to a place in your presentation where you really want people’s
attention, move to the left or right of your primary speaking position.
This will always make people look up at you. If you are a constant
mover or shaker, stand still for a few moments—it will have the same
Get quiet. If you really want to get people’s attention,
get quiet suddenly. It will scare the sound guy to death, but I
guarantee the audience will pay attention. Singers use this trick all
the time. That’s the “you could hear a pin drop” effect. Believe me,
that’s what sells your talk!
“Underline” certain words with a pause or repetition. If
you really want to make a point, slow down, pause, and say the word or
phrase that you most want people to hear with a calculated emphasis on
each word. The sudden switch in style gets attention. Also try
repeating a word or phrase before you make your big point. For example:
“You know (pause) you know (pause) you know, the thing I want you to
remember is…” Songs are full of repeated text, a device that locks down
Take a risk and be vulnerable. Say or do something that’s
totally out of character for you. Use a “pretend” voice like Mickey
Mouse or Barry White for effect while you’re telling a joke or saying
something shocking or humorous. Whether your persona is reserved or
funny, it’s endearing to have a little fun. This trick humanizes the
most serious topics.
Tee it higher. Raising the overall pitch of your voice
for a few seconds will create urgency. It shows your passion for the
subject matter and also relaxes your exhausted larynx. Low pitched
voices relax the room—high pitched voices increase the adrenaline flow
of the audience.
Know when it’s time to go. You don’t have to be a genius
to know you’ve overstayed your welcome. Check your “presentation
barometer” often to see if everyone is still with you. Change
something—anything—if you’re starting to lose the crowd. If all else
fails, stop talking, start thanking, and get off the platform. People
will love you more for knowing when to stop than for all the wonderful
content you brought to your topic!
Use Q and A as an “encore.” Singers usually prepare an
encore because this practice makes the audience feel special and makes
them think you like them more than other audiences you’ve encountered.
Q and A functions something like an encore. You may think you told them
stuff they needed to know, but questions often reveal the important
things you left out of your content. Where this opportunity exists, use
it as a tool for picking up the pieces you left dangling in your talk
and warm the crowd to your candor and self-effacing graciousness.
Rehearse, rehearse, rehearse. That’s how I got to
Carnegie Hall! Where possible, memorize your material like singers
memorize their songs. Remember, the more you rehearse, the freer you
will be to make your talk fresh and engaging.
Perform for a hero. Several years ago I was asked to sing
a command performance for the Queen of Spain. I worked harder on that
concert than any I have ever sung. It was very successful and I was
proud of my preparation. From that time on I imagined I was about to
sing for the queen, it made me twice the performer I had been
previously. Pick a hero, and give them your best shot!