development

1. Deciding what to do (see User Requirements)
   • investigate the problem that needs to be solved by discussions with those parties suffering the problem
   • write down what they expect a solution to provide
   • do NOT write down how the solution should be provided
   • postulate a number of alternative solutions that could be employed
   • discuss these alternatives with the parties involved
   • select the most promising alternative for further investigation
   • make sure the parties want a solution and get some idea how much benefit they expect to get from it
2. Working out the details (See System Proposal)
   • break down the problem into more manageable parts
   • write down what these parts should achieve and what they contribute to solving the problem
   • discuss the parts (and the whole) with the parties involved
   • agree that all the parts are required
   • work out how to describe the problem in essential terms
   • discuss this model with the parties involved
   • apply the real world to the model and fix the bits that break
   • discuss the result with the parties involved
3. Working out how to do it (See Analysis and Design)
   • look at what's currently in use by the parties suffering the problem
   • decide whether it can be used - or modified - to fix the problem
   • if not, look for other existing systems that could be used - or modified - to fix the problem
   • if you fail, look for existing systems that fix some of the problem
   • work out what needs to be modified or created to fix the whole problem
   • write down how to prove the problem has been fixed
   • knock up a quick schedule of works and get tenders
   • discuss the costs with the parties involved and confirm the problem is worth fixing
4. Build the system
   • This is generally considered the easy bit
5. Making sure it does what it's meant to do (See "v model".)
   • collect all that writing down done earlier
   • demonstrate that the system does what you said it would
   • debug any faults (see also Debugging techniques)
6. Sending it off out into the big wide world
   • This may be considered passe... but even the Linux kernel has releases.

Never forget to go back to the top and repeat the process as often as you can.

"Parties involved" will tend to grow over time and must include the people who'll be using the system and the people who'll be supporting the system, otherwise you're going to be hated by one or other (or probably both) groups.

Little and often is a good motto - people get used to continuous improvement and start looking for things to make their lives better. This keeps you in work and them happy.

In chess, development refers to the movement of pieces in the initial stages of the game. When a piece moves for the first time, it is said to have been 'developed', and in most chess openings, the idea is to develop all one's pieces before forming a plan for the rest of the game. The first player, therefore, to complete the development of his pieces has an advantage because he can start active operations sooner. The rules of development, or rather guidelines, since in chess there are numerous exceptions to almost every rule, are as follows:

• Don't make too many pawn moves. This wastes time and may allow your opponent to complete development before you. Generally two or three pawn moves are sufficient to allow all pieces to be developed.
• Don't move a piece twice. This also wastes time. Move your pieces to their best squares first time.
• Try to develop knights before bishops. The best square for a knight is usually obvious earlier than the best square for a bishop.
• Castle early. This is very important in open games (for example, double king pawn or e4 e5 openings). It is less important in closed openings, for example certain variations of the King's Indian Defence, but it is still wise to castle before forming a plan, unless you have a good reason to delay it. A king exposed in the center of the board can lead to all kinds of problems.
• Control the center. Knights, for example, are far more powerful in the middle of the board than at the edge, which is why, for White, the move Nf3 (or Nc3) in the first few moves is almost always better than Nh3 (or Na3). There's no advantage to developing quickly if your opponent controls the center completely, as the center is the base for most attacking and defensive plans.
• Don't move your queen out too early. Moving the queen out in the first few moves can often lead to it being attacked by the opponent's pieces, and because the queen is the most valuable piece, it almost always has to move when being attacked. This allows the other player to gain time. Only develop the queen the minor pieces have already moved, and (usually) only develop it one square forward (to c2, d2 or e2, or for Black, c7, d7 or e7).
• Make development difficult for your opponent. If he violates one of the above rules, see if you can exploit it, for instance by attacking an exposed queen. If he has left a weak square in the center, develop your pieces so that they focus on the weakness.
• Development is finished, as a rule of thumb, when the rooks are connected along the back rank. In other words, if the minor pieces are developed and the king is castled, then once the queen moves forward, development is finished and you can start trying to formulate a plan.

Development is so important in chess that many players will sacrifice a pawn or even more in order to develop quickly. This is called a gambit, and a player who accepts gambited material needs to be very careful - an advantage of only two or three moves of development can lead to a very quick attack. Gambits were extremely popular in the first decades of the modern chess era, producing many brilliant and short games, before defensive play became an art in itself. Nowadays, a grandmaster has to be adept at both attack and defense, and gambits are much rarer, though some gambits, because of their strength, and the lead in development that they confer, will never become extinct (see Benko Gambit for an example).

The above guidelines can be and regularly are violated by individual chess openings - this does not mean that they are wrong, merely that there is room in chess for experimentation and innovation. There have been long periods in the world history of chess where one particular style of play was more fashionable or more highly regarded than another - see hypermodern chess. Today's top grandmasters, such as Garry Kasparov and Vladimir Kramnik play with a style that includes the lessons learned from all previous eras and masters

De*vel"op*ment (?), n. [Cf. F. d'eveloppement.] [Written also developement.]

1.

The act of developing or disclosing that which is unknown; a gradual unfolding process by which anything is developed, as a plan or method, or an image upon a photographic plate; gradual advancement or growth through a series of progressive changes; also, the result of developing, or a developed state.

A new development of imagination, taste, and poetry. Channing.

2. Biol.

The series of changes which animal and vegetable organisms undergo in their passage from the embryonic state to maturity, from a lower to a higher state of organization.

3. Math. (a)

The act or process of changing or expanding an expression into another of equivalent value or meaning.

The equivalent expression into which another has been developed.

4. mus.

The elaboration of a theme or subject; the unfolding of a musical idea; the evolution of a whole piece or movement from a leading theme or motive.

Development theory Biol., the doctrine that animals and plants possess the power of passing by slow and successive stages from a lower to a higher state of organization, and that all the higher forms of life now in existence were thus developed by uniform laws from lower forms, and are not the result of special creative acts. See the Note under Darwinian.

Syn. -- Unfolding; disclosure; unraveling; evolution; elaboration; growth.

© Webster 1913.