The Art Of Software Development

THE ART OF SOFTWARE DEVELOPMENTBy Aditya Yadav

SOME STATISTICS

28% of software projects succeeded outright 23% were cancelled The remainder (late by 63%, over budget by

45%, lacking features by 33%)

SOFTWARE DEVELOPMENT IS COMPLEX

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.

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 doesn’t affect the development process. The mythical Man-Month

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.)

ALISTAIR COCKBURN’S 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

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

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

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 project’s 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 management’s 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.

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 team’s spirits and very late first delivery may erode the team’s credibility. While I have given team’s 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.

BLITZ PLANNINGThe Blitz Planning technique is similar to XP’s planning game or Scrum’s 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 sponsor’s 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.

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.

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.

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.

INCREMENTAL REARCHITECTUREMy 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.

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.

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

REFLECTION WORKSHOP

2 hours / month (or 30 minutes per week)

Keep These

Try These Problems

DAILY STAND-UP MEETINGS, ANDAt 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

BURN CHARTS