Posted on

HTML, Basics

In this post, you will learn the basic concepts for writing web pages.  This language used to create web pages is called HTML (Hypertext Markup Language).  Although the actual HTML file that you write may not look like much, it will appear much different when seen through a Web Browser, such as chrome or Microsoft Internet Explorer.

 

Before writing an HTML document, you must first decide how you want your information to look like when viewed in a web browser.  For instance, you do not want all of your information just simply printed on the page.  Rather, you will want to create headings to differentiate titles from normal text.  To distinguish between the styles of your information, you must use an HTML tag.  A tag simply denotes the style of the information you are writing.  The format usually follows as such:

 

<tag name>text</tag name>

 

The ending tag name is usually preceded by a ‘/’.  This indicates when you want your current style to end.  If you do not use an ending tag, your style will be carried out until the end of the HTML document.  An overview of this process includes the following things:

 

  1. First type in your document using a word processor. For this type of file, you only need to use Notepad for Windows.  To open Notepad, click on the start menu and select the Run option.  Type ‘notepad’ in the text box and then click OK.

 

  1. Once you have typed your HTML document, save it as a text file with the extension .html.

 

  1. To view your file, open it in a Web Browser

 

Your file will now appear on the browser as it would appear on the Internet.  If you want to view the changes you make to your file simply save your changes click on the refresh or reload button to see your updated file.  If you close your browser or save your file as a different name, you must repeat the steps above.
 

 

Now, lets try and create our first HTML document.

 

  1. First open Notepad. Now type in the text below:

<HTML><HEAD>

<TITLE>

Preparing a Document for the World Wide Web

</TITLE>

</HEAD>

<BODY>

<H1>Preparing a Document for the World Wide Web</H1>

</BODY></HTML>

 

  1. Save your file on your disk as ****.html where the **** represent the first four letters of your last name.
  2. Open your HTML file in a web browser.

 

The file that you have just created contains many important concepts in writing HTML documents.

 

  1. There are two parts to every HTML file name. The second part is the .html  Every HTML document must end like this.  The other is the first part, which in this case is the first four letters of your last name, but it could be any name that you can think of.

 

  1. You also witnessed the usage of HTML tags in an actual HTML document. For instance, every HTML file begins with <HTML> and ends with </HTML>.  Other tags that you used are the <HEAD>, <TITLE>, <BODY>, and <H1> tags.  The area inside the HEAD tags contains the Title and other information.  The title is not included in the document’s text, rather it appears in the browser window.  The title should be descriptive of your document due to the fact that many Internet Searches use the title in their document searches.

 

The BODY segment of your file contains the text and other information that you want displayed on the browser screen.  Headings are included in the BODY segment.  In HTML, there are six levels of headings.  They are numbered H1 through H6.  They are used just as H1 was in your first HTML document.  Heading H1 is the most important while H6 is the least important.  Headings usually appear larger and bolder than regular text when viewed on a web browser.  However, headings can appear differently on different computers since users have the ability to change how headings appear on their individual computers.

 

Also, when using headings, always use a more important heading before a less important heading (H2 before H3).  Headings are automatically followed by a blank line.

 

Another very important feature in HTML is the paragraph tag, <p>.  To mark a paragraph in HTML, use the <p> tag.  This tag is an exception in HTML.  While most other tags require an end tag, the paragraph tag does not.

 

With the introduction of the paragraph tag, we now must deal with the problem of multiple spaces, and blank lines in the text file.

 

  1. The paragraph tag indicates breaks between paragraphs by inserting a blank line between the text before and after the paragraph tag.
  2. Blank lines included in your text file are ignored when viewed on a browser.
  3. Multiple spaces in your text file are replaced by a single space.
  4. Even if your text file uses word wrapping, it will not affect its appearance on the browser.

 

Now lets modify our HTML document to try out the new concepts.

We want to edit the current HTML document so open your ****.html file:

  1. Insert the following including all blank lines and extra spaces between the </H1> and </BODY> tags:

 

Writing HTML documents takes some planning,

But the results are worthwhile.

 

Try to keep your Web documents simple and

short—not more than a           few screens

each.  You can link lots of information

together, so don’t worry about not being able

to cover everything you want to say in a few

screens. <p>

When you plan your document, remember that

Readers can jump       into it from

Anywhere.  For this reason, try not to use

Phrases             like “as we said earlier.”

Readers might not

have been there earlier! <p>

 

Following are some HTML features to help you

Convey your message.

This document prepared by (put your name here).

 

  1. Save your file.
  2. View your file in a browser
  3. Print both the text file and the file as viewed by a web browser.

 

 

 

Other interesting features in HTML are line breaks and lists.  A line break can be used when you want to include short lines of text without extra blank lines.  The tag for line break is <br>.  Like the paragraph tag, the line break tag does not have an end tag.

 

For example:

Dr. Schmidlap <br>

123 Loveless Street <br>

Wilmington, DE 19806 <p>

 

Produces:

Dr. Schmidlap

123 Loveless Street

Wilmington, DE 19806

 

Lists are a great way for displaying information in a clear an organized fashion on the Web.  The most common HTML lists are: ordered lists, unordered lists, and definition lists.

There are a few things that you should know before using lists:

  1. Lists can be nested. That is, you can have a list inside of a list.
  2. Lists can contain many paragraphs, separated by the <p> tag.
  3. Lists create their own blank lines before and after their location. Therefore, you do not have put insert your own blank lines.
  4. Individual list elements do not need an end tag.

 

The ordered list displays the information in the list in a numerical fashion.

For instance:

<ol>

<li>List item 1

<li>List item 2

<li>List item 3

</ol>

 

Produces:

  1. List item 1
  2. List item 2
  3. List item 3

 

The unordered list follows the same syntax as the ordered list.  The only difference in the two is that the unordered list uses bullets instead of numbers to mark each list item.  The tag for an unordered list is <ul> and the end tag is </ul>.

 

Definition lists are a slightly different from the ordered and unordered lists.  They have three tags, one to start the list, one to identify the definition term and one to identify the definition (<dl>, <dt>, <dd>).  For example:

 

<dl>

<dt>Definition term

<dd>Definition

<dt>Definition term

<dd>Definition

</dl>

 

Produces:

Definition term

Definition

Definition term

Definition

 

Next we will use our knowledge of lists in our HTML document.

  1. Open your ****.html file and insert the following just above the BODY end tag (</BODY>).

 

<H2>Design aids for HTML</H2>

<ol>

<li>Formatting tags

<li>Style tags

</ol>

 

  1. Save your file and view it on the browser.
  2. Print both the text file and the file as viewed in the browser.

 

It is important to have variety in your HTML document.  An easy way to make your text look better is to change the style of the text.  Four easy ways for modifying the style of the text is to use bold, underline, italics and typewriter.  These use the tags <b>, <u>, <i> and <tt> respectively with their proper end tags (</b>, </u>, </i>, </tt>).

 

These different styles can be nested.  This means that you could combine italics and underline to create a line of text which was both underlined and italicized.

 

Now modify your HTML document to apply the new styles.

  1. Open your file
  2. After the “<li>Formatting tags” line, insert the following:

<ul>

<li>Heading tags

<li>Paragraph tags

<li>Line breaks

</ul>

 

  1. After “Style tags” insert

<ul>

<li><b>Bold text</b>

<li><i>Italic text</i>

<li><u>Underlined text</u>

<li><tt>Typewriter text</tt>

</ul>

 

  1. Save your file and view it in the browser
  2. Print both your text file and the file as viewed in the browser

 

Finally you will need to take all the concepts that you have learned and create your own HTML document.  Create a class schedule real or imagined that includes at least 6 items, uses more than one heading, an itemized list and formatting of bold and italics in some way.  It should have your name, date, and section number as the title and first heading. Save this file as Schedule.html.

Print this file out both as text and as seen in the browser. Hand in all of your printouts from the lab and the above exercise.

Posted on

Singleton Class in Java

The Singleton’s purpose is to control object creation, limiting the number of objects to only one. Since there is only one Singleton instance, any instance fields of a Singleton will occur only once per class, just like static fields. Singletons often control access to resources, such as database connections or sockets.
For example, if you have a license for only one connection for your database or your JDBC driver has trouble with multithreading, the Singleton makes sure that only one connection is made or that only one thread can access the connection at a time

Implementing Singletons

The easiest implementation consists of a private constructor and a field to hold its result, and a static accessor method with a name like getInstance().
The private field can be assigned from within a static initializer block or, more simply, using an initializer. The getInstance( ) method (which must be public) then simply returns this instance −

 

// File Name: Singleton.java
public class Singleton {
private static Singleton singleton = new Singleton( );

/* A private Constructor prevents any other
* class from instantiating.
*/
private Singleton(){ }

/* Static ‘instance’ method */
public static Singleton getInstance( ) {
return singleton;
}
/* Other methods protected by singleton-ness */
protected static void demoMethod( ) {
System.out.println(“demoMethod for singleton”);
}
}

Here is the main program file, where we will create a singleton object:

// File Name: SingletonDemo.java
public class SingletonDemo {
public static void main(String[] args) {
Singleton tmp = Singleton.getInstance( );
tmp.demoMethod( );
}
}

This will produce the following result −

demoMethod for singleton

Posted on

Java Objects and Classes

Java is an Object-Oriented Language. As a language that has the Object-Oriented feature,
Java supports the following fundamental concepts:

  • Polymorphism
  •  Inheritance
  • Encapsulation
  •  Abstraction
  • Classes
  •  Objects
  •  Instance
  •  Method
  • Message Parsing

We will take a  look into the concepts – Classes and Objects.

  •  Object – Objects have states and behaviors. Example: A dog has states – color, name, breed as well as behaviors – wagging the tail, barking, eating. An object is an instance of a class.
  • Class – A class can be defined as a template/blueprint that describes the behavior/state that the object of its type support.

 

Objects in Java

Let us now look deep into what are objects. If we consider the real-world, we can find many objects around us, cars, dogs, humans, etc. All these objects have a state and a behavior.
If we consider a dog, then its state is – name, breed, color, and the behavior is – barking, wagging the tail, running.
If you compare the software object with a real-world object, they have very similar characteristics.
Software objects also have a state and a behavior. A software object’s state is stored in fields and behavior is shown via methods.
So in software development, methods operate on the internal state of an object and the object-to-object communication is done via methods.

Classes in Java

A class is a blueprint from which individual objects are created.
Following is a sample of a class.

public class Dog{
String breed;
int ageC
String color;
void barking(){
}

void hungry(){
}

void sleeping(){
}
}

A class can contain any of the following variable types.

  •  Local variables: Variables defined inside methods, constructors or blocks are called local variables. The variable will be declared and initialized within the method and the variable will be destroyed when the method has completed.
  •  Instance variables: Instance variables are variables within a class but outside any method. These variables are initialized when the class is instantiated. Instance variables can be accessed from inside any method, constructor or blocks of that particular class.
  •  Class variables: Class variables are variables declared within a class, outside any method, with the static keyword.
    A class can have any number of methods to access the value of various kinds of methods. In the above example, barking(), hungry() and sleeping() are methods.
Posted on

Basic Syntax in Java

When we consider a Java program, it can be defined as a collection of objects that communicate via invoking each other’s methods. Let us now briefly look into what do class, object, methods, and instance variables mean.

  • Object – Objects have states and behaviors. Example: A dog has states – color, name, breed as well as behavior such as wagging their tail, barking, eating. An object is an instance of a class.
  • Class – A class can be defined as a template/blueprint that describes the behavior/state that the object of its type supports.
  •  Methods – A method is basically a behavior. A class can contain many methods. It is in methods where the logics are written, data is manipulated and all the actions are executed.
  •  Instance Variables – Each object has its unique set of instance variables. An object’s state is created by the values assigned to these instance variables

The Basic Syntax

About Java programs, it is very important to keep in mind the following points.

  • Case Sensitivity – Java is case sensitive, which means identifier Hello and hello would have different meaning in Java.
  • Class Names – For all class names the first letter should be in Upper Case. If several words are used to form a name of the class, each inner word’s first letter should be in Upper Case.
    Example: class MyFirstJavaClass
  • Method Names – All method names should start with a Lower Case letter. If several words are used to form the name of the method, then each inner word’s first letter should be in Upper Case.
    Example: public void myMethodName()
  •  Program File Name – Name of the program file should exactly match the class name. When saving the file, you should save it using the class name (Remember Java is case sensitive) and append ‘.java’ to the end of the name (if the file name and the class name do not match, your program will not compile).
    Example: Assume ‘MyFirstJavaProgram’ is the class name. Then the file should be saved as ‘MyFirstJavaProgram.java’
  • public static void main(String args[]) – Java program processing starts from the main() method which is a mandatory part of every Java program.

Java Identifiers

All Java components require names. Names used for classes, variables, and methods are called identifiers.
In Java, there are several points to remember about identifiers. They are as follows:

  •  All identifiers should begin with a letter (A to Z or a to z), currency character ($) or an underscore (_).
  • After the first character, identifiers can have any combination of characters.
  •  A key word cannot be used as an identifier.
  • Most importantly, identifiers are case sensitive.
  •  Examples of legal identifiers: age, $salary, _value, __1_value.
  •  Examples of illegal identifiers: 123abc, -salary

Java Modifiers

Like other languages, it is possible to modify classes, methods, etc., by using modifiers.
There are two categories of modifiers:

  • Access Modifiers: default, public , protected, private
  •  Non-access Modifiers: final, abstract, strictfp

Java Variables

Following are the types of variables in Java:

  • Local Variables
  • Class Variables (Static Variables)
  •  Instance Variables (Non-static Variables)
Posted on

Best Java Editors and Compilers

To write your Java programs, you will need a text editor. There are even more sophisticated IDEs available in the market. But for now, you can consider one of the following:

  •  Notepad: On Windows machine, you can use any simple text editor like Notepad
    (Recommended for this tutorial), TextPad.
  •  Netbeans: A Java IDE that is open-source and free, which can be downloaded
    from http://www.netbeans.org/index.html.
  •  Eclipse: A Java IDE developed by the eclipse open-source community and can be
    downloaded from http://www.eclipse.org/.
Posted on

Overview of Java Programming Language

Java programming language was originally developed by Sun Microsystems which was initiated by James Gosling and released in 1995 as core component of Sun Microsystems’ Java platform (Java 1.0 [J2SE]).
The latest release of the Java Standard Edition is Java SE 8. With the advancement of Java and its widespread popularity, multiple configurations were built to suit various types of platforms. For example: J2EE for Enterprise Applications, J2ME for Mobile Applications.
The new J2 versions were renamed as Java SE, Java EE, and Java ME respectively. Java is guaranteed to be Write Once, Run Anywhere.

Characteristics of JAVA

  •   Object Oriented: In Java, everything is an Object. Java can be easily extended since it is based on the Object model.
  •  Platform Independent: Unlike many other programming languages including C and C++, when Java is compiled, it is not compiled into platform specific machine, rather into platform independent byte code. This byte code is distributed over the web and interpreted by the Virtual Machine (JVM) on whichever platform it is being run on.
  • Simple: Java is designed to be easy to learn. If you understand the basic concept of OOP Java, it would be easy to master.
  •  Secure: With Java’s secure feature it enables to develop virus-free, tamper-free systems. Authentication techniques are based on public-key encryption.
  •  Architecture-neutral: Java compiler generates an architecture-neutral object file format, which makes the compiled code executable on many processors, with the presence of Java runtime system.
  •  Portable: Being architecture-neutral and having no implementation dependent aspects of the specification makes Java portable. Compiler in Java is written in ANSI C with a clean portability boundary, which is a POSIX subset.
  • Robust: Java makes an effort to eliminate error prone situations by emphasizing mainly on compile time error checking and runtime checking.
  • Multithreaded: With Java’s multithreaded feature it is possible to write programs that can perform many tasks simultaneously. This design feature allows the developers to construct interactive applications that can run smoothly.
  • Interpreted: Java byte code is translated on the fly to native machine instructions and is not stored anywhere. The development process is more rapid and analytical since the linking is an incremental and light-weight process.
  • High Performance: With the use of Just-In-Time compilers, Java enables high performance.
  •  Distributed: Java is designed for the distributed environment of the internet.
  •  Dynamic: Java is considered to be more dynamic than C or C++ since it is designed to adapt to an evolving environment. Java programs can carry extensive amount of run-time information that can be used to verify and resolve accesses to objects on run-time.
Posted on

History of Scrum

Scrum is an iterative and incremental Agile software development framework for managing product development. It defines a flexible, holistic product development strategy where a development team works as a unit to reach a common goal. Scrum is an agile way to manage a project, usually software development. In the Scrum world, instead of providing complete detailed descriptions about how everything is to be done on a project, much of it is left up to the software development team. This is because the team will know better how to solve the problem they are presented with.
Scrum relies on a self-organizing, cross-functional team. The Scrum team is self-organizing in that there are no overall team leaders who decide which person will be doing which task and how the problem will be solved. Those are issues that are decided by the team as a whole.
Scrum was conceived by Ken Schwaber and Jeff Sutherland in the early 1990s, who published a paper to describe the process. The term “scrum” is borrowed from the game of rugby to stress the importance of teams, and illustrates some analogies between team sports like rugby, and being successful in the game of new product development.
The research described in their paper showed that outstanding performance in the development of new, complex products is achieved when teams (small, self-organizing groups of people) are fed with objectives, not with tasks. The best teams are those that are given direction within which they have room to devise their own tactics on how to best move towards their shared objective.
Teams require autonomy to achieve excellence. The Scrum framework for software development implements these principles for developing and sustaining complex software projects. In February of 2001, Jeff and Ken were among 17 software development leaders who created a manifesto for Agile software development.
In 2002, Ken Schwaber founded the Scrum Alliance with Mike Cohn and Esther Derby, with Ken chairing the organization. In the years to follow, the highly successful, certified Scrum Master programs and its derivatives were created and launched In 2006. Jeff Sutherland created his own company, Scrum Inc., while continuing to offer and teach certified Scrum courses. Ken left the Scrum Alliance in the fall of 2009 and founded scrum.org to further improve the quality and effectiveness of Scrum, mainly through the Professional Scrum series. With the first publication of the Scrum Guide in 2010, and its incremental updates in 2011 and 2013, Jeff and Ken established a globally recognized body of knowledge.

Posted on

Coding Rules

Code must be formatted to agree to coding standards. It’s these coding standards that keep the code consistent and easy for the entire team to read and refactor. Code that looks the same also helps to encourage collective code ownership. It used to be quite common for a team to have a coding standards document that defined how the code should look, including the team’s best practices for styling and formatting. The problem with this is that people rarely read them, let alone follow them. These days, it’s much more common to use a developer productivity tool to automatically guide the user in best practices.

Popular tools in use today, certainly from a .NET perspective, are ReSharper from JetBrains, CodeRush from Dev Express, and JustCode from Telerik. These are all paid-for solutions, though. If you want to use a free alternative, then you can look at StyleCop for the .NET platform. Visual Studio also has its own versions of some of these tools built in, but it’s quite common to supplement Visual Studio with an additional add-on.
Other development platforms will have their own variants of these tools, either as separate additions to their environments, or built in to their IDEs. These tools are so unbelievably powerful that it really makes it frictionless to write code that conforms to a set of coding standards.
When you create a unit test before writing out your code, you’ll find it much easier and faster to create the code. The combined time it takes to create a unit test, and then create some code to make it pass that test, is about the same as just coding it out straightaway. Creating unit tests helps the developer to really consider what needs to be done, and then the system’s requirements are firmly nailed down by the tests. There can be no misunderstanding the specification written in the form of executable code, and you have immediate feedback while you work.
It’s often not clear when a developer has finished all the necessary functionality, and scope creep can occur as extensions and error conditions are considered, but if you create your unit tests first, then you know when you are done.

A common way of working while pairing with another developer is to have one developer write a failing test, and then the other developer to write just enough code to make that test pass. Then, the second developer writes the next failing test, and the first programmer writes just enough code to make that test pass. It almost feels like a game when you work in this way. I worked this way for quite a while when I was working for an internet bank, and once you get a good pace with your programming pair, you can become really productive really quickly.
Under XP, all code to be sent to production should be created by two people working together at a single computer. Pair programming increases software quality without impacting delivery time. It can feel counter-intuitive at first, but two people working at a single computer will add as much functionality as two people working separately, except that it will be much higher in quality, and with increased code quality comes big savings later on. The best way to pair programming is just to sit side-by-side in front of the monitor, and slide the keyboard back and forth between the two. Both programmers concentrate on the code being written.
Pair programming is a social skill that takes time to learn when you’re striving for a cooperative way to work that includes give and take from both partners, regardless of corporate status.
Without force-controlling the integration of code, developers test their code and integrate on their machines, believing all is well. But because of parallel integration with other programming pairs, there’s a combination of source code that has not been tested together, which means integration problems can happen without detection. If there are problems, and there is no clear-cut, latest version of the entire source tree, this applies not only to the source code, but to the unit test suite, which must verify the source code’s correctness.

If you cannot get your hands on a complete, correct, and consistent test suite, you’ll be chasing bugs that do not exist and overlooking bugs that do. It is now common practice to use some form of continuous integration system integrated with your source control repository. When a developer checks in some code, the code is integrated with the main source code tree and built, and the tests are executed. If any part of this process fails, the development team will be notified immediately so that the issue can be resolved.
It’s also common to have a source control system fail at check-in if the compile and test run fails. In Team Foundation Server, for example, this is called a gated build. Once you submit your code to the repository, the code is compiled on a build server and the tests are executed. If this process fails for any reason, the developer would not be able to check-in their code. This process helps to ensure your code base is in a continual working state, and of high quality. Developers should be integrating and committing code into the source code repository at least every few hours, or when they have written enough code to make their whole unit test pass. In any case, you should never hold onto changes for more than a day.
Continuous integration often avoids diverging or fragmented development methods, where developers are not communicating with each other about what can be reused or can be shared. Everyone needs to work with the latest version, and changes should not be made to obsolete code, which causes integration headaches. Each development pair is responsible for integrating their own code whenever a reasonable break presents itself.
A single machine dedicated to sequential releases works really well when the development team is co-located. Generally, this will be a build server that is controlled by checking commits from a source control repository like Team Foundation Server. This machine acts as a physical token to control releasing, and also serves as an objective last word on what the common build contains. The latest combined unit test suite can be run before releasing, when the code is integrated on the build machine, and because a single machine is used, the test suite is always up-to-date. If unit tests pass 100 percent, the changes are committed. If they fail for any reason, then the check-in is rejected, and the developers have to fix the problem.
Collective code ownership encourages everyone to contribute new ideas to all segments of the project. Any developer can change any line of code to add functionality, fix bugs, improve designs, or refactor. No one person becomes a bottleneck for changes. This can seem hard to understand at first, and it can feel inconceivable that an entire team can be responsible for systems design, but it really makes sense not to have developers partitioned their own particular silos. For starters, if you have developers who only own their part of the system, what happens if that developer decides to leave the company? You have a situation where you have to try and cram a transfer of a lot of knowledge into a short space of time, which in my experience never works out too well, as the developers taking over are not building up a good level of experience in the new area.
By spreading knowledge throughout the team, regularly swapping pairs, and encouraging developers to work on different parts of the system, you minimize risks associated with staff member unavailability.

Posted on

History of Extreme Programming

Extreme Programming is a software development methodology that is intended to improve software quality and responsiveness to changing customer requirements. As a type of Agile software development, it advocates frequent releases and shorter development cycles, which are intended to improve productivity and introduce checkpoints where new customer requirements can be adopted. Other elements of XP include programming in pairs or doing extensive code reviews, unit testing all of the code and avoiding programming of features until they are actually needed. XP has a flat management structure with simplicity and clarity in code, and a general expectation that customer requirements will change as time passes. The problem domain will not be understood until a later point, and frequent communication with the customer will be required at all times.
Extreme Programming takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to extreme levels. As an example, code reviews are considered a beneficial practice. Taken to the extreme, code can be reviewed continuously with the practice of pair programming.
XP was created by Kent Beck during his work at the struggling Chrysler Comprehensive Compensation System payroll project, or C3, as it was known. In 1996, Chrysler called in Kent Beck as an external consultant to help with its struggling C3 project. The project was designed to aggregate a number of disparate payroll systems into a single application.
Initially, Chrysler attempted to implement a solution, but it failed because of the complexity surrounding the rules and integration. From this point of crisis, Kent Beck and his team took over, effectively starting the project from scratch. The classic Waterfall development approach had failed, so something drastic was required. In Kent Beck’s own words, he just made the whole thing up in two weeks with a marker in his hand and a white board. Fundamentally, the C3 team focused on the business value the customer wanted, and discarded anything that did not work towards that goal. Extreme Programming was created by developers for developers.
34
The XP team at Chrysler was able to deliver its first working system within a year. In 1997, the first 10,000 employees were paid from the new C3 system. Development continued over the next year, with new functionality being added through smaller releases. Eventually, the project was cancelled because the prime contractor changed, and the focus of Chrysler shifted away from C3. When the dust settled, the eight-member development team had built a system with 2,000 classes and 30,000 methods. Refined and tested, XP was now ready for the wider development community.

Posted on

History of Agile Software Development Process

There have been many attempts to try and improve software development practices over the years, and many of these have looked at working in a more iterative way. These new practices didn’t go far enough when trying to deal with changing requirements of customers.
In the 1990s, a group of industry software thought leaders met at a ski resort in Utah to try and define a better way of developing software. The term “Agile software development” emerged from this gathering. The term was first used in this manner and published in the now-famous
Agile Manifesto. The Agile Manifesto was designed to promote the ideas of delivering regular business value to your customers through the work of a collaborative, cross-functional team.

The Agile Manifesto Core Values

The Agile Manifesto is built upon four core values:
 Individuals and interactions over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan

Individuals and interactions over processes and tools

Software systems are built by people, and they all need to work together and have good communications between all parties. This isn’t just about software developers, but includes QA, business analysts, project managers, business sponsors, senior leadership, and anyone else involved in the project at your organization. Processes and tools are important, but are irrelevant if the people working on the project can’t work together effectively and communicate well.

Working software over comprehensive documentation

Let’s face it—who reads hundred-page collections of product specs? I certainly don’t. Your business users would much prefer to have small pieces of functionality delivered quickly so they can then provide feedback. These pieces of functionality may even be enough to deployto production to gain benefit from them early. Not all documentation is bad, though. When myteams work on a project, they use Visio or a similar tools to produce diagrams of employment environments, database schemas, software layers, and use-case diagrams (and this is not an
exhaustive list). We normally print these out on an A3 printer and put them up on the wall so they are visible to everyone. Small, useful pieces of documentation like this are invaluable.

Hundred-page product specs are not. Nine times out of 10, large items of documentation are invalid and out-of-date before you even finish writing them. Remember, the primary goal is to develop software that gives the business benefit—not extensive documentation.

Customer collaboration over contract negotiation

All the software that you develop should be written with your customer’s involvement. To be successful at software development, you really need to work with them daily. This means inviting them to your stand-ups, demoing to them regularly, and inviting them to any design meetings. At the end of the day, only the customer can tell you what they really want. They may not be able to give you all the technical details, but that is what your team is there for: to
collaborate with your customers, understand their requirements, and to deliver on them.

Responding to change over following a plan

Your customer or business sponsor may change their minds about what is being built. This may be because you’ve given them new ideas from the software you delivered in a previous iteration. It may be because the company’s priorities have changed or new regulatory changes come into force. The key thing here is that you should embrace it. Yes, some code might get thrown away and some time may be lost, but if you’re working in short iterations, then the time lost is minimized. Change is a reality of software development, a reality that your software process must reflect. There’s nothing wrong with having a project plan; in fact, I’d be worried about any project that didn’t have one. However, a project plan must be flexible enough to be changed. There must be room to change it as your situation changes; otherwise, your plan quickly becomes irrelevant.