Transcript Secrets of Top Notch Development Teams Maxim Porges Lead Software Architect

Secrets of Top Notch
Development Teams
Maxim Porges
Lead Software Architect
CFI/Westgate Resorts
CFUNITED – The premier ColdFusion conference
www.cfunited.com
Great Software
Teams In A Nutshell
CFUNITED – The premier ColdFusion conference
www.cfunited.com
Attributes of Great Software Teams
 Environment
• Open forum
• Collaborative
• Academic
 High level of professional respect
between team members
 Evenly distributed work load
 Clear, well-documented expectations
June 28th – July 1st 2006
Creating the
Environment
CFUNITED – The premier ColdFusion conference
www.cfunited.com
Techies are Creative Types
 Technology has moved to the
mainstream - techies are “cool”
 Software is more art than science
June 28th – July 1st 2006
A Quote

“What hackers and painters have
in common is that they’re both
makers. Along with composers,
architects, and writers, what hackers
and painters are trying to do is make
good things.”
 Paul Graham, “Hackers & Painters”
June 28th – July 1st 2006
Things Developers Value

Being a part of the solution
(whatever the problem)
Learning/Sharing

•
•



Peers
Software Communities
Working on “well-designed” systems
Clean Requirements
Clear Expectations
June 28th – July 1st 2006
Placement of Team Values
 Team Values shape the team
 Where you place Team Values
determines your reward systems
June 28th – July 1st 2006
8
Where To Place Values
 Place high value on
• Community Decision Making
 Technology Choices
 Development Standards
 Disagreement Resolution (e.g. Code Reviews, Best
Practices)
• Peer Review and Approvals
 All work touched by at least two sets of hands/eyes
 Review Cycles
 Promotion of work through software lifecycle
June 28th – July 1st 2006
Where To Place Values
 Place high value on
• New Ideas
 Developers hate stale environments
 Give them a positive way to own/change their workplace
 Allow developers to bring new technologies to their projects
 Be responsible: use proofs of concept to mitigate the risk of
new ideas
• Tinkering
 Create scheduled time for developers to experiment with
sanctioned technologies/tools/techniques
 Time spent away from projects allows “decompression”
 New skills will contribute to future projects/productivity
June 28th – July 1st 2006
Benefits of Openness/Collaboration
 Collaboration moves responsibility to the
team (not the individual) when mistakes
are made
 Mistakes become successes when the
team gathers to fix them
 An open environment builds professional
respect through interaction: everybody
brings something to the table
June 28th – July 1st 2006
How to Collaborate
 Team meetings
• Regular (at least weekly)
• Brief (30-60 minutes)
 Go around the room having developers
describe what they are working on
 (Larger Teams) Keep everybody in the loop
on all projects in progress
 Encourage suggestions and feedback in
every meeting
June 28th – July 1st 2006
How to Collaborate
 Peer Reviews
• Spec/Prototype
• Architecture/Design
• Code
 Reviews create learning/sharing
opportunities
 Improves productivity: end product will
always be higher quality
June 28th – July 1st 2006
How to Collaborate
 Meet after each project to discuss
successes and failures
 Determine solutions to problems
during these meetings to shape the
next project
• You’re automatically one step ahead for
your next project!
June 28th – July 1st 2006
Development
Standards
CFUNITED – The premier ColdFusion conference
www.cfunited.com
Why They’re Needed
 Standards are part of “clear
expectations”
 Standards resolve all disputes with
regard to work quality
 When created by the team, they
create a “code of honor” for members
to adhere to
June 28th – July 1st 2006
How to Create Standards
 Several methods:
• Embrace an existing standards
document
• Brute Force
• Develop Standards “As Needed”
June 28th – July 1st 2006
#1: Embrace Existing
Standards
 Take an existing documented
standard and apply it
 Pitfalls
• Not many documents of this nature exist
• Most teams operate differently based
upon the specific nature of their
clients/projects
• If standards are not created by the team,
there is no sense of ownership
June 28th – July 1st 2006
#2: Brute Force
 Sit down and figure out all of your
standards at once
 Requires a good deal of time
 Requires seasoned team members to
bring experience to the table
 Can be difficult to relate to
examples/speak from experience in
new teams
June 28th – July 1st 2006
#3: Develop Standards “As Needed”
 Create standards on the fly
 Stop what you’re doing and bring
team together as you go
 Look at a specific problem and
determine a standard with team
suggestions
 Document it right away!
June 28th – July 1st 2006
How to Document Standards
 Wikis are great
•
•
•
•
Web accessible
Searchable
Easily edited/marked up
Support media for better examples
 Short of a Wiki, regular word
processors/web pages can do the job
 Don’t forget to put standards in source
control (if you can)
June 28th – July 1st 2006
Standards Enforcement
 Un-enforced standards are non-existent
standards
 All review cycles should be based on
standards
 Review cycle “check lists” are a good way
to go
 Make sure developers are comfortable
bringing a standard back to the team when
it doesn’t make sense in a given scenario
June 28th – July 1st 2006
On the Job
Work Distribution
Growing Your Developers
Documentation
CFUNITED – The premier ColdFusion conference
www.cfunited.com
On The Job
 Good work distribution techniques:
• Allow junior developers to tackle new
challenges
• Promote mentoring and knowledge sharing
• Prevent “Knowledge Silos”
• Avoid “go to” guys who know/do everything
 Even work distribution results in:
• Low levels of “prima donna” syndrome
• High quality, persistent documentation
June 28th – July 1st 2006
Handling Experienced Techies
 Most developers don’t want to be
managers. Make them mentors instead!
 Allow your experienced developers to
mentor your junior developers
• Creates opportunity for Team Lead positions
as the team grows
• Senior techies are rewarded through the
professional respect of their junior peers
June 28th – July 1st 2006
Avoid Knowledge Silos
 Knowledge silos are a dangerous,
irresponsible scenario
 Steady rotation of work eliminates
knowledge silos/prima donnas
June 28th – July 1st 2006
Making Time for Documentation
 Documentation is important; shoot for “just
enough”
 How much is “just enough”?
• Should abstract the essential details of the code
• Should be a combination of visual (e.g. UML) and
written
• (Generally) Fewer words/more pictures is better
• Should create a mental starting point for understanding
the business problem and working on the actual code
 Documentation should always be a current
snapshot
June 28th – July 1st 2006
Making Time for Documentation
 Steady work rotation promotes good
documentation
• Developers new to a system will ask
similar questions - these are the bits that
need to be externally documented!
• When new developers can start work on
the system easily without asking these
questions, the documentation is
“enough”
June 28th – July 1st 2006
Proven Work Distribution Strategy
 Rotate developers between short
maintenance/enhancement work and
longer projects
June 28th – July 1st 2006
Maintenance Work
 Maintenance teams are usually rapid
pace, varied diet
• Creates the opportunity to see systems
in action
• Small problems
• Short time frames
• Keeps debugging skills sharp
• Good break from “long project
monotony”
June 28th – July 1st 2006
Longer Term Project Work
 Creates opportunity to apply new
ideas/technologies/techniques
 Exercises application design skills
 Longer term, more focused work
 Promotes team work/communication
in parallel development environments
June 28th – July 1st 2006
Things To Avoid
 Partitioned Shops are bad
 “Maintenance only” Developers
• Creates stale skills
• Promotes boredom
 “Project Only” Developers
• Maintenance gives developers the opportunity
to see how well their work scales in reality
(ease of maintenance)
• The last 5% of long projects are draining; switch
developers to maintenance of other systems
ASAP after their project ends!
June 28th – July 1st 2006
Interviewing and
Hiring
CFUNITED – The premier ColdFusion conference
www.cfunited.com
You Are What You Eat
 Who you bring on your team affects the
entire team’s performance
• Be selective, be protective
• Adding a bad apple WILL spoil the
bunch
 Don’t be afraid to terminate employment
for resources who damage the team
environment you are trying to create
June 28th – July 1st 2006
Developer Interviews
 Where to place value
• Avoid random technical questions that
probe candidate’s general knowledge;
instead, focus on personality/philosophy
• Engage in exercises that demonstrate
communication and team work
capabilities
• Involve team members in the hiring
process and selection of new team
members
June 28th – July 1st 2006
Avoid Random Tech Questions
 Which question will give you useful insight in
to the candidate’s thought process?
• “What’s the argument list to StructFind?”

or
• “How do you like to take requirements and
turn them in to a working software
solution?”
June 28th – July 1st 2006
Random Tech Questions
 Another example
• “What are valid attributes of the
CFCOMPONENT tag?”

or
• “What can a development team do to
work smarter instead of harder?”
June 28th – July 1st 2006
Proven Interview Process
 Steps
• 20 Minute Phone Interview
• 30 Minute Technical Screening
Exercise
• 1 hour In-Person Interview
•
Each step must be completed
successfully for a candidate to proceed
June 28th – July 1st 2006
20 Minute Phone Interview
 Conduct with interviewer and at least one other
team member
 Ask high level, open ended questions
 Evaluate that:
• Candidate has desired experience/capabilities
• Candidate can communicate clearly and
professionally
• Candidate is not a serial killer
 Take note of candidate answers to supplement
their potential in-person interview
June 28th – July 1st 2006
Sample Phone Interview Questions
•
•
•
•
•
•
•
•
•
Tell us briefly about your experience
What do you consider to be your strongest skills?
What’s your [technology x] experience?
What is your level of experience with object oriented
development and design?
What size team have you worked on previously?
When working in a team environment, what role do
you usually fill?
What are your career aspirations?
What are your reasons for leaving your present
employer?
Do you have any questions for us?
June 28th – July 1st 2006
30 Minute Technical Screening Exercise
 Use an exercise - not technical questions
• Exercises demonstrate the candidate’s
communication and explanation skills (essential
to strong developers)
 Give the candidate an abstract
development scenario that probes their
thought process
• Make sure that the exercise probes the qualities
that you desire in a candidate
• Make the candidate present the solution to the
interviewer and several team members in a
Q&A session
June 28th – July 1st 2006
Example
 In-Person OO Design Exercise
June 28th – July 1st 2006
1 Hour In-Person Interview
 Evaluate candidate on:
•
•
•
•
Personality
Professionalism
Development Philosophy
Work Ethic
 Relate back to notes taken from initial
phone interview
June 28th – July 1st 2006
Example
 In-Person Programmer Interview
June 28th – July 1st 2006
Questions and Answers
CFUNITED – The premier ColdFusion conference
www.cfunited.com
Thank You For Watching!
[email protected]
http://www.maximporges.com
CFUNITED – The premier ColdFusion conference
www.cfunited.com