Secrets%20of%20Top%20Notch%20Development%20Teams

1
Secrets of Top Notch Development Teams

• Maxim Porges
• Lead Software Architect
• CFI/Westgate Resorts

2
Great Software Teams In A Nutshell
3
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

4
Creating the Environment
5
Techies are Creative Types

• Technology has moved to the mainstream - techies
  are cool
• Software is more art than science

6
A Quote

• What hackers and painters have in common is
  that theyre both makers. Along with composers,
  architects, and writers, what hackers and
  painters are trying to do is make good things.
• Paul Graham, Hackers Painters

7
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

8
Placement of Team Values

• Team Values shape the team
• Where you place Team Values determines your
  reward systems

9
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

10
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/tech
  niques
• Time spent away from projects allows
  decompression
• New skills will contribute to future
  projects/productivity

11
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

12
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

13
How to Collaborate

• Peer Reviews
• Spec/Prototype
• Architecture/Design
• Code
• Reviews create learning/sharing opportunities
• Improves productivity end product will always be
  higher quality

14
How to Collaborate

• Meet after each project to discuss successes and
  failures
• Determine solutions to problems during these
  meetings to shape the next project
• Youre automatically one step ahead for your next
  project!

15
Development Standards
16
Why Theyre 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

17
How to Create Standards

• Several methods
• Embrace an existing standards document
• Brute Force
• Develop Standards As Needed

18
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

19
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

20
3 Develop Standards As Needed

• Create standards on the fly
• Stop what youre doing and bring team together as
  you go
• Look at a specific problem and determine a
  standard with team suggestions
• Document it right away!

21
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
• Dont forget to put standards in source control
  (if you can)

22
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 doesnt make
  sense in a given scenario

23
On the Job

• Work Distribution
• Growing Your Developers
• Documentation

24
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

25
Handling Experienced Techies

• Most developers dont 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

26
Avoid Knowledge Silos

• Knowledge silos are a dangerous, irresponsible
  scenario
• Steady rotation of work eliminates knowledge
  silos/prima donnas

27
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

28
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

29
Proven Work Distribution Strategy

• Rotate developers between short
  maintenance/enhancement work and longer projects

30
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

31
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

32
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!

33
Interviewing and Hiring
34
You Are What You Eat

• Who you bring on your team affects the entire
  teams performance
• Be selective, be protective
• Adding a bad apple WILL spoil the bunch
• Dont be afraid to terminate employment for
  resources who damage the team environment you are
  trying to create

35
Developer Interviews

• Where to place value
• Avoid random technical questions that probe
  candidates 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

36
Avoid Random Tech Questions

• Which question will give you useful insight in to
  the candidates thought process?
• Whats the argument list to StructFind?
• or
• How do you like to take requirements and turn
  them in to a working software solution?

37
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?

38
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

39
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

40
Sample Phone Interview Questions

• Tell us briefly about your experience
• What do you consider to be your strongest skills?
• Whats 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?

41
30 Minute Technical Screening Exercise

• Use an exercise - not technical questions
• Exercises demonstrate the candidates
  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 QA
  session

42
Example

• In-Person OO Design Exercise

43
1 Hour In-Person Interview

• Evaluate candidate on
• Personality
• Professionalism
• Development Philosophy
• Work Ethic
• Relate back to notes taken from initial phone
  interview

44
Example

• In-Person Programmer Interview

45
Questions and Answers
46
Thank You For Watching!

• maxim_porges_at_wgresorts.com
• http//www.maximporges.com