FY10 performance review

[http://dummy.us.eu.org/robert (Robert)]

2010 Annual Performance Review (8/26/2010) for Robert    
Printing Tip: You are able to format the way the Performance Assessment
prints by right clicking anywhere below and selecting the Print Preview
option in the menu.  

 
Title:  SDE 2 
Department Name:  US-Business Solutions Engineering 
Personnel Number:  
 Fiscal Year:  2010 
Updated by:  ro 8/26/2010 10:19 AM PDT 
Posted by:  RO 8/26/2010 10:19 AM PDT 
 
1.  Tell_me Analytics Infrastructure Improvement project   
 
Execution Plan:  
1) Guide design and lead implementation of the major software components
for the Analytics Infrastructure Improvement.  This includes 
 a) the redesigned tmlog_pusher process that forwards binary logs to
Cosmos, and 
 b) network connectivity of new log_pushers to Cosmos. 
2) Ensure reliability of data handling. 
3) Integrate redesigned log_pusher into fail-over design. 
4) Facilitate the move of legacy applications to the new Cosmos logging
infrastructure (e.g. utterance capture) resulting in the gradual
phasing-out of the existing Tell_me dblog infrastructure.  
Accountabilities:  
A) Smooth deployment with no client-impacting outages (data accuracy &
completeness) 
B) Deploy log pusher (log_pusher) cluster with automatic failover in Q4
FY2010 

Alignment:  Not Aligned 
 
Employee's Comment on Results Against this Commitment: 
Accountabilities achieved: A
Accountabilities shortfall: B
 
Below are how #1 and #3 measured up against the SDE2 career stage profile
competencies.
 
Design and architecture tradeoffs. The log_pusher redesign was a
learning process and everyone thought it went well, but some felt it took
too long and may have been dragged out longer than needed. The design was
surprisingly robust through its implementation -- only a few details
changed.  The big concepts seemed to live through. 
Risks & dependencies.  Risks and dependencies in the schedule were not
fully developed and this was definitely a shortcoming.  After lots of
slippage of previous tasks, the log_pusher redesign implementation began
in March 2010 and, due to the time constraints, others were added to the
project to try to get it finished on time. 
Code quality.  Code reviews were regular, but only 1 unit test for 1
component was ever completed. 
Customer & partner quality resolution.  In general, very little of this
was done.  There could have been better communication overall, especially
with the NOC and operations generally. 
 
For #2, there was a major data problem during DBC13 deployment in J anuary
2010.  It took several weeks to resolve but thankfully there was no
revenue loss due to the lossage. 
 
There were few explicitly legacy application moves done and, of those that
were, I had very little role in.  So, #4 was a nonstarter.  
Manager's Comment on Results Against this Commitment: 
The log_pusher redesign was a learning process for Robert. He worked
very hard on the design and led peer and cross-team reviews, revising the
design until it satisfied all requirements and integrated well with
dependent components. As Robert alludes to, this process took almost twice
as long as originally estimated and put the project's schedule at risk.
 
The implementation phase of this project got off to a very rocky start.
Robert struggled to deliver against his assigned tasks on-time with
acceptable quality. Late code drops and lengthy Test cycles caused by
buggy code further jeopardized this commitment's schedule. The data
problems caused by the DBC13 maintenance delayed development work for
nearly a month, most of which Robert could have avoided.
 
After a bumpy start, Robert was able to improve during the second half of
the implementation phase. In March, another engineering resource was
acquired to help recover this project's schedule (Corby). Robert started
creating detailed designs, task lists, estimations and implementation
schedules. As a result he "met his target dates (working late hours when
needed) reliably through both phases of the project". The project was
completed in the Q4 FY2010 accounted for in Robert's commitments, but only
because extra resources were added.
 
Robert's comment regarding "legacy applications" isn't accurate. The
purpose of the log_pusher redesign/rebuilding task was to enable
utterance capture to be migrated to Cosmos. This is an example of how
Robert sometimes has a hard time seeing how his work fits into the "bigger
picture", an observation also reflected in peer feedback. 

 
2.  Near-Real Time project   
 
Execution Plan:  
1) Participate in the design and implementation of the major software
components for Near-Real Time.  
Accountabilities:  
A) Help with design and implementation with specified schedule. 

Alignment:  Not Aligned 
 
Employee's Comment on Results Against this Commitment: 
Accountabilities shortfall: A
 
No near-real time work was done. 
Manager's Comment on Results Against this Commitment: 
A factors prevented Robert from working on near real-time:
performance issues relating to commitment #1 
other team members working ahead to implement parts of near real-time 
near real-time monitoring being de-prioritized for favor of new Platform
Central reports 
 

 
3.  Code Quality   
 
Execution Plan:  
1) Review code for my team members upon request. 
2) Assign buddies for all filed bugs. 
3) Ensure code review standards are consistent throughout the team and
that the quality bar is high. 
4) Create opportunistically 
  a) monitors, 
  b) monitor unit tests, and 
  c) specific unit tests 
 for the software components that comprise Tell_me Analytics.  
Accountabilities:  
A) Create an evolving "cvs commit" check-list for all documents, code, and
verdad changes, including monitors and unit tests. 
B) 80% of new code written, including monitors, have associated unit tests 
C) No more than 25% of bugs are reopened after passed to QA 
D) Each major (> 1 week) bug has an associated design doc, used when
buddying and QA. 
E ) Test plans are reviewed before the code complete date for my
components. 

Alignment:  Not Aligned 
 
Employee's Comment on Results Against this Commitment: 
Accountabilities achieved: A
Accountabilities shortfall: B, C, D, E
 
For #1, code was reviewed left and right.  I think some of the reviews
were too cursory and I hope future reviews to be more thorough.  (Greg
Szorc's install of Review Board has helped and I also plan to do more
in-person code reviews.)
 
For #2, in late 2009, buddy assignments was robust, but, when Review Board
arrived, this started slipping a bit since Review Board allows for
multiple person-buddy requests. 
 
for #3, I did not ensure consistent code review standards throughout the
team, but I feel I have improved over the last 3 or 4 months. 
 
For #4a, monitors were not as thoroughly scoped out in the log_pusher
redesign and therefore there was very little need to create them.
Unfortunately. 
 
For #4b, lack of unit tests for monitor resulted in many shortcomings.
Some status checks had to be reworked later.  Communication and
cooperation with the NOC might have been better if there were some unit
tests in place since it would be clear what the division of
responsibilities were. 
 
For #4c, a unit test was written for tmLogDiskCache.  This worked out
well, 'tho it may have been slightly overdesigned and implementation
probably lasted longer than it should have. 
 
Although a unit test for CosmosBlockPusher was started, no other unit
tests were completed. 
 
Although not included in the above Execution Plan, I did develop a set of
checklists which are used to develop and improve my personal software
process.  I needed to develop these lists since I found it was impossible
to change my modus-operandi without such a disciplined approach.  Certain
times of the day and week are reserved for reviewing these checklists.
The checklists are continuing to evolve as my process is refined. 
 
  
Manager's Comment on Results Against this Commitment: 
Robert does a good job making sure all his code is reviewed before it is
committed into source control. 
 
Robert's development schedule fell behind quite a bit this year. At times
this caused the "cursory" reviews and almost always lead to unit tests
being dropped. As Robert continues to improve his process and efficiency,
I expect that he will be able to properly allocate time for code reviews
and unit test development.
 
Robert struggled with high reopen rates early in the year. As he started
thinking through a problem before coding, his quality really improved and
his bug reopen rates dropped into acceptable ranges.
 
Although not mentioned in his accountability for this commitment, Robert
does a good job working with Test to create test plans, review bugs and
come up with testing strategy. He is "very thorough, [analyzing] each bug
carefully, [testing] the code himself." He is "always there for us (QA)
whenever we need his assistance." 

 
4.  Process Improvement   
 
Execution Plan:  
1) Meet with Analytics colleagues for peer and immediate supervisor
feedback 
2) Identify test dependencies and ensure QA is properly testing my
components.  
Accountabilities:  
A) 80% of DBC release cycles schedule estimates are within 10% of my
actual time spent with no major feature or reliability cuts 
B) Get supervisor feedback at least once per month.
C) Get peer and QA feedback at least once every quarter. 

Alignment:  Not Aligned 
 
Employee's Comment on Results Against this Commitment: 
Accountabilities achieved: B, C
Accountabilities shortfall: A
 
I met with peers regularly for feedback and have had minor improvements in
my personal software process through that. 
Manager's Comment on Results Against this Commitment: 
I would say that the improvements Robert made in his process were more
than "minor". As explained in my comments for commitment #1, the changes
in Robert's process got his performance back on track after a very rocky
start.  

 
5.  Technical Growth   
 
Execution Plan:  
1) Own more software components through a full software lifecycle
including requirements definition, design, implementation, test, and
production deployment. 
2) Mentor/onboard peers to code as needed.  
Accountabilities:  
A) Own one other component besides log pusher (log_pusher) and pdsp
feeds. 
B) Mentoree (if any) takes no more than 5% of time after brought
up-to-speed (~6 months). 

Alignment:  Not Aligned 
 
Employee's Comment on Results Against this Commitment: 
Accountabilities achieved: B
Accountabilities shortfall: A
 
For #1, I was not able to "own" any other components.  Due to time
slippages, it was nearly impossible to do so.
 
For #2, I helped Corby understand the existing design and code of
tmlog_pusher and the new design (what became tmlog_pusher).  This goal
was accomplished, 'tho Corby is Senior SDE and this wasn't exactly the
circumstances the original execution plan was describing.  
Manager's Comment on Results Against this Commitment: 
The spirit of this commitment was to build a component through a full
lifecycle. Robert was able to do that as part of log_pusher
redesign/rebuild in commitment #1.
 
Robert was able to help Corby quickly ramp up as he transitioned onto our
development team to help with the log_pusher design/rebuild work. 

 
Overall Assessment 
Employee's Self-Assessment of Results Against Commitments: 
Only 42% of accountabilities were achieved.  There are no good excuses for
the poor outcome, so I will provide none.
 
I think I can continue to improve my performance through continual
personal process improvements (via the checklists and other techniques). 
Manager's Overall Assessment of Employee's Results Against all
Commitments: 
Robert did not perform well during the first half of the year, but he
worked extremely hard to make necessary corrections. 
 
Robert continues to improve his involvement in team development as
reflected by peer feedback:
"he was very patient in explaining each and every [detail] of the bugs" 
"works with people in a professional manner and is an excellent team
player" 
"maintains an even keel and is easy to communicate with" 
"willing to help" 
 
Robert has the potential to contribute at his current level. On small and
well-defined tasks Robert has created "designs [that] were straightforward
and clear". To apply this to larger more abstract tasks Robert will have
to improve on his ability to "step back and consider the big picture".
Additionally, Robert tends to rely too heavily on others to help make
decisions for him. Peers would like to be able to see Robert "say with
conviction 'this is a good design'", "build technical confidence", and not
be "afraid of being wrong". 
 

 Employee's Self-Assessment of Commitment Rating: Underperformed Submitted
by: ro 7/8/2010 12:19 PM PDT

Manager's Commitment Rating: Underperformed 
Manager's Contribution Ranking: 10% 

 Manager's Contribution Ranking Comments:
Robert's performance the first half of this year put him a hole that he
could not recover from. As such he was not able to accomplish his
committed tasks without additional resources. A 10% ranking here reflects
that Robert "Underperformed" this year, but his solid second half
indicates that he is not "underperforming". 

Employee "Robert" signed on 8/26/2010 10:19 AM PDT
Manager "Joshua" signed on 8/25/2010 4:47 PM PDT

  Application Timeout
 The page has timed out.

--------------------------------------------------------------------------------

Reload Application
To view the information again, you can close the current browser and
restart the application in a new browser window or reload
Performance@Macrosoft