The Art Of Software Development

1
The Art Of Software Development

• By Aditya Yadav

2
Some statistics

• 28 of software projects succeeded outright
• 23 were cancelled
• The remainder (late by 63, over budget by 45,
  lacking features by 33)

3
Software Development is complex
4
What is Project management

• Scope Management
• Time Management
• Quality Management
• Cost Management
• Risk Management

Experienced project managers know when to bend
and when to break the rules.
5
False assumptions

• The scope can be completely defined
• Scope definition can be done before the project
  starts
• Software development consists of distinctly
  different activities which can be measured and
  estimated
• Software development activities can be sequenced
• There is always a way to produce meaningful
  estimates
• The size of the project team doesnt affect the
  development process. The mythical Man-Month

6
False assumptions

• Team members can be individually allocated to
  activities
• One developer is equivalent to another
• Metrics are sufficient to assess the quality of
  software. (Except for Bug Metrics all measure the
  process not the product.)
• Quality checklists solve all problems. (Problems
  happen due to non-repetitive tasks.)

7
Alistair Cockburns Crystal

• Crystal Clear (2-8 developers)
• Crystal Yellow (9-20 developers)
• Crystal Orange (21-50 developers)

People centric methodologies do better than
process centric methodologies
8
Common 7 properties in all crystal projects

• Frequent Delivery
• Reflective Improvement
• Osmotic Communication
• Personal Safety
• Focus
• Easy Access to Expert Users
• A Technical Environment with Automated Tests,
  Configuration Management, and Frequent Integration

All projects have properties. More properties
more chances of success
9
Patterns

• Exploratory 360
• Early Victory
• Blitz Planning
• Process Miniature
• Side-by-Side Programming
• Walking Skeleton (aka Tracer Bullet or Spanning
  Application)
• Incremental Rearchitecture
• Information Radiators
• Methodology Shaping
• Reflection Workshop
• Daily Stand-Up Meetings, and
• Burn Charts

10
Exploratory 360

• Simply put the Exploratory 360 strategy means
  that the project team should perform a gap
  analysis on all that is required to run a project
  successfully. In particular it also means to
  cover topics that really are the responsibility
  of others outside the development team, like the
  fact that there is proper funding and that the
  proposed project really has a clear recipient who
  wants the project to succeed. Cockburn supplies a
  list of the most common things to check for but
  there may be additional things particular to the
  organization or the projects circumstances. If
  the gaps revealed are too wide or many the
  project can (and probably should) be terminated
  early and if nobody else have brought this to
  managements attention it is the responsibility
  of the development team.The Exploratory 360
  strategy is something that is close to being self
  evident but I would guess often forgotten when
  starting a new project.

11
Early Victory

• Many projects start out with the most difficult
  tasks first in order to minimize the risks. While
  this may be sound in theory, giving the team
  members an easy task to start with will boost
  morale when the team succeeds in it as well as
  show the sponsor(s) that the team is performant.
  Addressing the most difficult task first and then
  failing can be catastrophic for the teams
  spirits and very late first delivery may erode
  the teams credibility. While I have given teams
  easier tasks to start with in order to get things
  going I have never thought of it in terms of an
  Early Victory and as a reason to celebrate.

12
Blitz Planning

• The Blitz Planning technique is similar to XPs
  planning game or Scrums Sprint Planning but
  Blitz Planning uses index cards in a new,
  creative way. The project sponsor, developers and
  end users gather together and brainstorm on all
  the tasks that need to be done to deliver the
  system. Cards are collated and duplicates
  removed. The developer most likely to perform a
  task should make estimate on how long it will
  take to perform it. The tasks are then arranged
  in sequence on a large table parallel tasks are
  placed side-by-side and sequential tasks top to
  bottom. The sequence is divided in iterations and
  releases and cards are moved around to optimize
  development, to fit the sponsors priorities,
  make an Early Victory or a Walking Skeleton and
  so on. The planning may very well reveal the need
  for additional resources, change in scope etc.
  The outcome of the Blitz planning is a draft
  project plan.What I like with the Blitz Planning
  is the simple and cooperative fashion in which
  the project plan is derived. Using index cards on
  a table makes changes easy and the result is very
  graphical.

13
Process Miniature

• In order to learn a lengthy and/or complicated
  process a miniature version of the process may be
  run in a few minutes to a few days depending on
  the process being learned. If it is a development
  process, only trivial functionality may be
  developed or what is being built may simply be
  faked. Using Process Miniature is a variation of
  learning by doing but where the learning is
  substantially accelerated.

14
Side-by-Side Programming

• In Pair Programming is a controversial technique
  in Extreme Programming. Some people find Pair
  Programming wasteful though proponents of XP
  claims it saves time in the end due to the lesser
  number of defects found in the final product.
  While this may be true some people simply do not
  like to program in pairs. An alternative to Pair
  Programming is Side-by-Side Programming where two
  developers sitting side-by-side with workstation
  of their own, helping out and reviewing code
  continuously. A similar effect as with Pair
  Programming is achieved but possibly with less
  wasted time.

15
Walking skeleton

• A Walking Skeleton is a tiny implementation of
  the system that performs a small end-to-end
  function. It need not use the final architecture,
  but it should link together the main
  architectural components. The architecture and
  the functionality can then evolve in parallel.

16
Incremental rearchitecture
My point is that the architecture of a system can
be slowly and incrementally evolved, and that TDD
(including both unit tests and acceptance tests)
is the enabler. Without the ability to run those
tests and ensure that I have not broken
something, I'd be very reluctant to continuously
meddle in the guts of the architecture month
after month. But since I have the tests, it's a
complete no-brainer. I don't mind leaving the
architecture half-way between the old and the
new, because I know nothing is broken and I can
easily pick up the thread of my thoughts by
looking at the tests I've written and the current
state of the interface. For years now skeptics
of Agile methods have predicted that rules like
YAGNI and practices like The Simplest Thing would
lead to architectures that are stuck in a local
minimum. These skeptics predicted that once
locked into the local minimum, agile teams would
have no way to make bigger architectural changes.
For years the agile community has rebutted this
by saying that big architecture changes can be
done incrementally over many iterations and
releases. Long term incremental architecture
evolution works, and works well.

17
Information Radiators

• An information radiator is a large display of
  critical team information that is continuously
  updated and located in a spot where the team can
  see it constantly. Information radiators are
  typically used to display the state of work
  packages, the condition of tests or the progress
  of the team. Team members are usually free to
  update the information radiator. Some information
  radiators may have rules about how they are
  updated.

18
Methodology Shaping

• A methodology is nothing more than the
  conventions people agree to follow ! They
  naturally drift over time. How do we make
  methodology construction so cheap that we can
  reconstruct it each month? Answer The
  Reflection technique

Keep These
Try These
Problems
19
Reflection Workshop

• 2 hours / month (or 30 minutes per week)

Keep These
Try These
Problems
20
Daily Stand-Up Meetings, and

• At a typical project meeting most attendees do
  not contribute, but attend just to hear the
  outcome. A large amount of developer time is
  wasted to gain a trivial amount of communication.
  Having many people attend every meeting drains
  resources from the project and also creates a
  scheduling nightmare.Communication among the
  entire team is the purpose of the stand up
  meeting. A stand up meeting every morning is used
  to communicate problems, solutions, and promote
  team focus. Everyone stands up in a circle to
  avoid long discussions. It is more efficient to
  have one short meeting that every one is required
  to attend than many meetings with a few
  developers each.When you have daily stand up
  meetings any other meeting's attendance can be
  based onwho will actually be needed and will
  contribute. Now it is possible to avoid even
  scheduling most meetings. With limited attendance
  most

21
Burn Charts