Programming Methodologies Explained

There are many forms of Programming Methodologies. The purpose of recording methodology is to ensure awareness among program writers, so that they are aware of the processes and procedures used by them when constructing programs. It is to increase this self-conscious degree of awareness among the best authors and programmers that this short article on programming methodologies explained has been undertaken.

Types Of Methodologies

The program writers may be writing large software systems, with team-work in big teams a part of the conditionality of cooperative effort, and may be expected to conform with standard practices within their own teams as well as across other teams. Yet others may be writing small programs for themselves. Being aware of the process of programming is to be able to improve the process itself, with the following objectives:

  • To achieve better acceptance of the Specification.
  • To create Faster production of the Final Product.
  • To ensure better Quality Control in the Final product.
waterfall development process

The “Waterfall” Method has been the preferred technique over earlier generations of programming, and the typical approach steps have been as follows:

  • The Requirement Gathering
  • Problem Definition
  • System Design
  • Implementation
  • Testing
  • Documentation
  • Training and Support
  • Maintenance

Traditions are now being bypassed, by a new generation of Methods of Programming. In the last few years, the New Age has dawned in this field, which we will now discuss.

The New Age

Traditionally, the “Waterfall” Method has been in use, but in the last decade, most quality-conscious programmers have adopted RapidPrototyping Methodology for Programming. Some of the other methods adopt ProgramReuse Methodology, which in effect simply re-apply existing large programs by , modification. Finally, ComponentBased Programming is used.

In the Waterfall Model, each step provides the most reasonable platform for the next step. But problems tend to be fractal, and solving them tends to reveal sub-problems, which may then reveal sub-sub-problems. So approximations are used to simply the solution, leading to approximate answers which are not fully correct, but correct only up to the extent of the approximation. The other Methodologies noted above tend to avoid such simplistic solutions. In recent years, research into replacement of full-cycle methodologies with “AgileProcesses” typically aim to reduce the amount of non-programming related overhead. This allows increased accuracy in estimation and improved efficiency of code.

The Authors of some of the most exciting new programming languages such as DSDM, XP, Episodes, Scrum and Adaptive Software Development and Experts from the field all came together to create a new Methodology which they called “Agile”. The name was chosen in view of the qualities of the new entrant/s, such as high maneuverability and rapid reaction. AgileProcesses include some of the following:

  • Open Source As Agile Process
  • Extreme Programming
  • Episodes Pattern language
  • Scrum Process
  • DSDM (Dynamic Systems development Method)
  • XBreed
  • Alistair Cockburn’s Crystal Methodologies
  • Jim Highsmith’s Adaptive Software development
  • FDD
  • Shai Ben Yehuda’s Tgp Methodology

But how to define this new group of Programming Methodologies? Agile process is basically a highly disciplined approach to Constant Unexpected Change. In fact, the difference between classic development methodology and Agile development has been described as the difference between a Boxer and a Street-fighter. The Boxer can only follow rules (Marquis of Queensberry) when the opponent is down, but the Street-fighter will hit you with a brick if you are not watching! Traditionally, using Waterfall or similar Processes, the attempt has been to Eliminate Change or Anticipate Change by abstraction or configurability. But in the long run, this Methodology has only led to approximations (which deny accuracy), as well as prevent the “Agility” necessary to keep up on programming software to today’s high level of speed and accuracy.

The Approach

There are basically two types of approaches to programming, referring to the two strategies for developing a computer program.

  • Top-Down approach: This starts by implementing the most general modules, and works towards implementing those that provide specific functionality.
  • Bottoms-Up approach: This implements the modules that provide the specific functionality first, and then integrates them by implementing the more general modules.

Most programs are developed by using combinational techniques incorporating both strategies. There are similarities in both strategies. Both employ unit testing methods, which simply means testing each component separately before moving on to the next. Both are based on incremental development. In other words, programs are built up piece by piece. Actually, incremental development with unit testing tries to simulate artificially imposed proximity of cause and effect onto the software testing process. This methodology mimics hardware behavior and testing, where a failure is generally found to be in close proximity of the cause, obeying the Law of Proximity of Cause and Effect. For example, wobbling of the front wheel is in all certainty caused by failure of the shock absorber closest to it, i.e. mounted on the same wheel strut.

Skills For Agile

There is a relative paucity of theory behind Agile. This again reinforces the Street-fighter image of Agile. But slowly, intensely analytical experts have postulated the following technical skill sets that are necessary to successfully practice the Agile Method:

  • The programmer should be able to easily create domain specific languages.
  • He (or she) should know truly effective performance tuning methods, which should not be just profiling.
  • Partial evaluation methods must be part of the skill set, whenever the problem demands it.
  • He should be able to invent new data structures or control techniques whenever required to solve the problem.

Methodologies must be adaptable. They must be able to differ by criticality, size, optimized quality, scope and the basic grounding of the authors. Any comparison of Methodologies must concentrate on these different facets, and their inter-relationships with the requirements of the project or the organization. The “Waterfall” Method has been the preferred technique over earlier generations of programming, and the typical approach steps should be followed.