Twenty Dirty Tricks to Train Software Engineers

1
Twenty Dirty Tricks to Train Software Engineers
2
Twenty Dirty Tricksto Train Software Engineers

• Originally a paper presented at ICSE2000, held in
  Limerick, Ireland, by one Ray Dawson, of
  Loughborough University, Leicestershire, England
• Summary (and slight abbreviation) by yours truly
• Employers always complain that graduate students
  come to them poorly prepared for everyday
  problems encountered at the workplace (takes six
  months at least to train them to become
  productive)
• To overcome this, Loughborough U. has teamed up
  with Plessey Telecommunications, to create a
  slightly different software development course

3
A New Course?

• Two weeks intensive course, half-a-day lecture at
  the start, half-a-day review session at the end,
  and a team project to simulate realistic working
  environment
• A similar course organized at the University as
  well
• Main distinctive feature
• deliberate "action was taken to disrupt the
  students' software development progress
• The action(s) may appear mean and vindictive, but
  their value was recognized by students and
  employers alike

4
What's Wrong WithStandard Group Projects?

• Well, nothing ...
• Except that they do not give adequate preparation
  for real life situations
• Nasty surprises abound in your job environment,
  and software development is probably somewhere
  among the worst possible environments
• Tricks have been played in industry and/or
  university courses, and each has been found to
  offer valuable experience

5
Trick 1 Give an Inadequate Specification

• Students should be given a "specification" of no
  more than two or three pages
• At first, it should appear sufficient for the
  purpose on a more detailed analysis, it should
  be at times vague, inconsistent, and incomplete
• Why? good specifications rarely (if ever) exist
• Lessons good communication with customers is the
  only way you can get REAL requirements

6
Trick 2 Make Sure All Assumptions Are Wrong

• If the students have not sought clarification
  when the specification is ambiguous, the
  "customer" should make sure that the assumptions
  they have made are all wrong
• Applies to what's in the specs, as well as what
  the students have added on their own (hoping that
  the customers would like to receive a "superior"
  product)
• Why? It is common to make assumptions, but that's
  not how the world works
• Lessons (quality) communication with the
  customer is essential in every stage of
  development
• Never assume anything ask instead

7
Trick 3 Present an Uncertainand Naive Customer

• Customer representative should not be too sure
  about what she wants, or she may have little or
  no experience with computers whatsoever
• Why? students usually assume that the "customer"
  (i.e., the teacher) knows far more than they do,
  and consequently they expect to get help when in
  doubt
• Lessons communication with customers requires a
  great deal of tact and patience, and customer
  education and training can be as significant a
  deliverable as the software itself

8
Trick 4 Change Requirementsand Priorities

• Once the project is set, it should be changed on
  a regular basis
• The goal is to change requirements in ways that
  appear perfectly reasonable
• Why? nothing stands still in the real world, and
  requirements and priorities change all the time
  students must be ready to deal with this
• Lessons things change, and your design must be
  made flexible enough to survive those changes
  (Univ. version change every week for eight
  successive weeks)

9
Trick 5 Have Conflicting Requirements and
Pressures

• Introduce students to a no-win situation where it
  is impossible to satisfy two conflicting
  requirements
• For example, a customer may want a certain
  graphical output while the manager prescribes the
  use of an incompatible software package
• Why? the nature of education tends to classify
  answers as "right" or "wrong" ... in real life,
  there may be no perfect answer to many problems
• Lessons compromise is often the only way out,
  and negotiation is the way to attain compromise
  (especially valuable for perfectionists)

10
Trick 6 Present Customerswith Conflicting Ideas

• A particular example of conflict can be created
  by introducing more than one customer with more
  than one solution idea
• Students would be given quite different messages
  from different customer roles, and it may be made
  more difficult by making sure that the two
  personalities are never available at the same
  time
• Why? students rarely encounter such problems in
  the course of their regular studies, but they are
  quite frequent in real life
• Lessons satisfying one person does not guarantee
  that the solution offered will be acceptable, and
  politics of dealing with people make requirements
  analysis a rather complex task

11
Trick 7 Present Customerswith Different
Personalities

• It is instructive to provide customers with
  different personalities as well as viewpoints
  for example, one who enthusiastically accepts
  most suggestions put forward, another one who is
  reluctant to deviate from his original ideas
• The first type gives the most problems, leading
  the students into commitments they could never
  achieve ("Oh yes, that is a very good idea -- we
  could do the same thing with X, Y, and X too,
  couldn't we?)
• Why? each person is different, and negotiating
  style has to account for different personalities
• Lessons it is the people that complicate the
  analysis of requirements ... negotiation is a
  necessary skill, and care and caution are just as
  important as your enthusiasm and willingness to
  please the customer

12
Trick 8 Ban Overtime

• Students should be restricted to a strict number
  of hours, no extra time overnight or during lunch
  breaks
• Why? students regularly take extra time to finish
  their assignments, over nights and weekends,
  ending up putting far too much time into it than
  their original estimates predicted
• Lessons make your time management and estimation
  more realistic

13
Trick 9 Give Additional Tasksto Disrupt the
Schedule

• In addition to the project, the students should
  be given further activities which are not known
  about in advance
• The extra assignment could affect the whole team,
  or maybe just the key player
• Why? in real life, meetings, training,
  administration, even coffee breaks all take time,
  which can rarely be planned ahead
• Lessons be more realistic in your time
  estimation and planning

14
Trick 10 Change the Deadlines

• Students should be told half-way through the
  project that the customer requires the product at
  an earlier date than originally specified
• There should be room for negotiation with scope
  reduction some of the deliverables are to be
  delivered at the earlier date, while the others
  should be delivered at the original date, or
  dropped altogether
• However, the students should not be offered any
  compromise in the first instance, all flexibility
  only coming through negotiation
• Why? in real life deadlines change but the actual
  dates/cost are usually negotiable (role
  reversal!)
• Lessons deadlines are subject to a number of
  influences, learn to negotiate and plan flexibly

15
Trick 11 IntroduceQuality Inspection

• Introduce roles other than managers and customers
• Role of a quality auditor requiring inspections
  at very short notice can be useful, and it is
  particularly effective when team is feeling most
  vulnerable, such as when the project is about two
  thirds complete and the first signs of
  integration problems start to appear
• Why? many students pride themselves in being able
  to produce "high quality" software" and
  customers wont take your word for it
• Plus, comments and documentation should not be an
  afterthought produced at the end of the project
• Lessons real world requires standards that must
  be maintained throughout a project, not handled
  as an afterthought

16
Trick 12 Presenta "Different Truth

• The customer should say one thing one day and
  something else the next, and then deny that
  anything different has been said (in other words
  lie!)
• The different statements should not be obviously
  contradictory, but should be disguised in a
  different emphasis or in a different context
  (e.g., "only manager will use the software" vs.
  "the management team will use the software")
• Why? students need to appreciate that in the real
  world mistakes are being made, but not everyone
  will own up to them (or indeed even realize that
  they have made a mistake at all)
• Lessons mistakes can be made, and agreements are
  more valuable when put on paper

17
Trick 13 Change the Team

• Team membership should be changed in mid-project
  if at all possible
• When there are several teams, just swap some
  members (if possible, change one member at a
  time, several times and make sure you change the
  key players)
• Why? it is unreasonable to assume that the team
  membership will remain stable ... esp. for
  projects that take more than a few weeks
• Lessons communication among team members can
  alleviate most of the personnel problems know
  what you do and what others do

18
Trick 14 Changethe Working Procedures

• The project manager should lay down the working
  practices expected of the student team
• However, these should be occasionally changed
  (explain that the project manager is not here, or
  has been replaced, and the new one requires
  significant changes in procedure and the product
  produced)
• Why? such changes are quite common in real life,
  but not very common in university studies
• Lessons teams need to be flexible, time must be
  planned to the inevitable disruption caused, and
  the importance of quality in both product and
  development process is emphasized (teams who are
  well organized and actively promote quality can
  adapt better to externally imposed changes)

19
Trick 15 Upgrade the Software

• If possible, the software used for the project
  should be upgraded to a later version during the
  project life
• The upgrade should be claimed to be fully
  backward compatible and the students should be
  told that it should not affect them
• Why? To dampen the students' enthusiasm and
  desire for all the latest software and gadgetry
  (students tend to believe that being up to date
  with the latest fashion is the only real measure
  of quality)
• Lessons take the whole picture into account
  every new acquisition has a price in terms of
  time and effort and money, which must be balanced
  against the gains obtained plus, a healthy
  skepticism of manufacturer's claims learn to
  always allow extra contingency time whenever such
  upgrade occurs

20
Trick 16 Change the Hardware

• Towards the end of the project, the customer
  should announce that they have just decided to
  standardize on a particular hardware platform
  (which is, of course, different from the one used
  for development)
• Make the changes possible, though at a price
• Why? if handled correctly, this will be the
  students' first introduction to legacy systems
  they have to decide whether to make the switch
  and lose some functionality through the time
  lost, or to continue with the current legacy
  platform and make changes later (when it may be
  more expensive)
• Lessons try to stick with the standard features
  of your development (hardware and software)
  platform learn about the portability issues

21
Trick 17 Crash the Hardware

• This trick may be held in reserve in case any
  project team appears to be doing too well
• The customer should not be too sympathetic about
  the problem and the delays incurred
• Why? hardware crash is a typical disaster
• Lessons disasters happen, not everything will go
  smoothly universities tend to encourage students
  to always have an excuse -- but such behavior has
  limits in the real world

22
Trick 18 Slow the Software

• When the project is in the late stages of
  development, the demand for resources tends to
  grow, and performance starts to suffer if at all
  possible, try to burden the computers or network
  with unrelated activity such that everything
  slows down
• Why? the slowing down of a system under load is a
  common event and so it cannot be acceptable as an
  excuse
• Lessons be realistic in your planning, little
  thought beforehand can help a lot to minimize the
  effects of disasters

23
Trick 19 Disrupt the File Store

• If possible, disrupt the file store the students
  are using (at Plessey, this was done over a lunch
  period by replacing the students file area with a
  copy made on the previous evening)
• This sort of disruption is relatively common (and
  easy to do as long as the file store area is kept
  on a central machine)
• Why? such things do happen, and effects may vary
  enormously from one team to another
• Lessons pay attention to configuration
  management, particularly when the effect on
  competing teams can be demonstrated a well
  organized team with good configuration management
  can recover quickly, while some teams may never
  recover

24
Trick 20 Say "I Told You So!

• Probably the most infuriating trick of all
• At the start of the project the students can be
  told many things, yet the project will still
  follow the same pattern
• The course leader can then give a very snug
  expression and declare "I told you so!
• Why? the expression is so annoying yet nothing
  works better to drive the point home!
• Lessons the students learn much about
  themselves, in particular, their own limitations
  they learn to become much more realistic, and
• above all they learn they still have much to
  learn!

25
Student Reactions

• Whenever the approach has been described, the
  first reaction is surprise that the author has
  ever lived to tell the tale!
• Reactions have been favorable, provided the
  students were told about the aims and objectives
  at the beginning, and having the lessons reviewed
  at the end
• Many students have found that they enjoyed the
  challenge, and that the course has proved to give
  one of their most interesting and rewarding
  learning experiences
• In sixteen years, only two students have declared
  the actions totally unfair and left ... and both
  later proved to be unable to fit in the company's
  software development team and left after only a
  short period

26
Summary

• A course giving valuable real life experiences
• Limitation not every trick can be used in the
  university environment (industry-based short
  course is a different beast altogether)
• As many other things in Software Engineering, the
  approach described cannot be proved to work --
  yet employers praise graduates from Loughborough
  as being particularly well adapted to real life
  environment
• Maybe use some of them in our next Software
  Engineering course?!