Software Development Design and Coding With Patterns

Debugging Unit Testing and Refactoring 3rd Edition

John F. Dooley - Downloadable PDF 2025

https://ebookfinal.com/download/software-development-design-and-coding-
with-patterns-debugging-unit-testing-and-refactoring-3rd-edition-john-f-
dooley/

Visit ebookfinal.com today to download the complete set of

ebooks or textbooks
Here are some recommended products that we believe you will be
interested in. You can click the link to download.

Software Design and Development 2nd Edition Samuel Davis

https://ebookfinal.com/download/software-design-and-development-2nd-
edition-samuel-davis/

Testing IT An Off the Shelf Software Testing Process 2nd

Edition John Watkins

https://ebookfinal.com/download/testing-it-an-off-the-shelf-software-
testing-process-2nd-edition-john-watkins/

Model Based Software Testing and Analysis with C 1st

Edition Jonathan Jacky

https://ebookfinal.com/download/model-based-software-testing-and-
analysis-with-c-1st-edition-jonathan-jacky/

Automated Software Testing with Cypress 1st Edition

Narayanan Palani

https://ebookfinal.com/download/automated-software-testing-with-
cypress-1st-edition-narayanan-palani/
Object oriented software engineering using UML Patterns
and Java 3rd, intern. Edition Bruegge

https://ebookfinal.com/download/object-oriented-software-engineering-
using-uml-patterns-and-java-3rd-intern-edition-bruegge/

Head First Design Patterns Building Extensible and

Maintainable Object Oriented Software 2nd Edition Eric
Freeman
https://ebookfinal.com/download/head-first-design-patterns-building-
extensible-and-maintainable-object-oriented-software-2nd-edition-eric-
freeman/

The Art of Unit Testing with examples in C 2nd Edition Roy

Osherove

https://ebookfinal.com/download/the-art-of-unit-testing-with-examples-
in-c-2nd-edition-roy-osherove/

Pragmatic Unit Testing in C with NUnit Pragmatic

Programmers 1st Edition Andy Hunt

https://ebookfinal.com/download/pragmatic-unit-testing-in-c-with-
nunit-pragmatic-programmers-1st-edition-andy-hunt/

Server Component Patterns Component Infrastructures

Illustrated with EJB Wiley Software Patterns Series 1st
Edition Markus Volter
https://ebookfinal.com/download/server-component-patterns-component-
infrastructures-illustrated-with-ejb-wiley-software-patterns-
series-1st-edition-markus-volter/
Software Development Design and Coding With Patterns
Debugging Unit Testing and Refactoring 3rd Edition John
F. Dooley Digital Instant Download
Author(s): John F. Dooley , Vera A. Kazakova
ISBN(s): 9798868802850, 8868802856
Edition: 3rd
File Details: PDF, 11.33 MB
Year: 2024
Language: english
CHAPTER 1

Introduction to Software
Development
“Not only are there no silver bullets now in view, the very nature of software
makes it unlikely that there will be any—no inventions that will do for soft-
ware productivity, reliability, and simplicity what electronics, transistors,
and large-scale integration did for computer hardware. We cannot expect
ever to see twofold gains every two years.”
—Frederick J. Brooks, Jr.1

So, you might be asking yourself, why is this book called Software Development, Design,
and Coding? Why isn’t it called All About Programming or Software Engineering? After
all, isn’t that what software development is? Well, no. Programming is a part of software
development, but it’s certainly not all of it. Likewise, software development is a part of
software engineering, but it’s not all of it.
Here’s the definition of software development that we’ll use in this book: software
development is the process of taking a set of requirements from a user (a problem
statement), analyzing them, designing a solution to the problem, and then implementing
that solution on a computer.
But isn’t that programming? Well, no. Programming is really just the implementation
part, or possibly the design and implementation part, of software development.
Programming is central to software development, but it’s not the whole thing.
Well, then, isn’t it software engineering? Again, no. Software engineering also
involves a process and includes software development, but it also includes the entire
management side of creating a computer program that people will use. Software

1
Brooks, F. 1987. “No Silver Bullet.” IEEE Computer 20 (4): 10–19. www.inst.eecs.berkeley.
edu/~maratb/readings/NoSilverBullet.html.
1
© John F. Dooley and Vera A. Kazakova 2024
J. F. Dooley and V. A. Kazakova, Software Development, Design, and Coding,
https://doi.org/10.1007/979-8-8688-0285-0_1
Chapter 1 Introduction to Software Development

engineering includes project management, configuration management, scheduling

and estimation, baseline building and scheduling, managing people, and several other
things. Software development is the fun part of software engineering.
So software development is a narrowing of the focus of software engineering to just
that part concerned with the creation of the actual software. And it’s a broadening of the
focus of programming to include analysis, design, and release issues.

What We’re Doing

It turns out that, after 80 or so years of using computers, we’ve discovered that developing
software is hard. Learning how to develop software effectively, efficiently, and sustainably
is also hard. You’re not born knowing how to do it and many people, even those who take
programming courses and work in the industry for years, don’t do it particularly well.
It’s a skill you need to pick up and practice—a lot. You don’t learn programming and
development by reading books—not even this one. You learn it by developing software. That,
of course, is the attraction: to work on interesting and difficult problems. The challenge is to
work on something you’ve never done before, something you might not even know if you
can solve. That’s what has you coming back to create new programs again and again.
There are probably several ways to learn software development. But we think that all
of them involve reading excellent designs, reading a lot of code, writing a lot of code, and
thinking deeply about how to approach a problem and design a solution for it. Reading a
lot of code, especially really beautiful and efficient code, gives you lots of good examples
about how to think about problems and approach their solution in a particular style.
Writing a lot of code lets you experiment with the styles and examples you’ve seen in
your reading. Thinking deeply about problem solving lets you examine how you work
and how you do design, and lets you extract from your labors those patterns that work for
you; it makes your programming more intentional.

So, How to Develop Software?

Well, the first thing you should do is read this book. It certainly won’t tell you everything,
but it will give you a good introduction into what software development is all about and
what you need to do to write great code. It has its own perspective, but it’s a perspective
based on our combined 40 years or so of writing code professionally and another 24
years trying to figure out how to teach others to do it.
2
 Chapter 1 Introduction to Software Development

Despite the fact that software development is only part of software engineering,
software development is the heart of every software project. After all, at the end of the
day what you deliver to the user is working code. A team of developers working in concert
usually creates that code. So to start, maybe we should look at a software project from the
outside and ask, what does that team need to do to make that project a success?
In order to succeed at software development, you need the following:

To realize that you don’t know everything you need to know at the
beginning of the project. Software development projects just don’t
work this way. You’ll always uncover new requirements; other
requirements will be discovered to be not nearly as important
as the customer thought; still others that were targeted for the
next release are all of a sudden requirement number one. This is
known as churn. Managing requirements churn during a project
is one of the single most important skills a software developer
can have. If you are using new development tools (say a new
web development framework), you’ll uncover limitations you
weren’t aware of and side effects that cause you to have to learn,
for example, three other tools to understand them (e.g., that
web development tool you want to use is Ruby-based, requires a
specific relational database system to run, and needs a particular
configuration of Apache to work correctly.)

A small, well integrated team. Small teams have fewer lines

of communication than larger ones. It’s easier to get to know
your teammates’ strengths and weaknesses, understand their
personalities and preferences, and establish who is the go-to
person for particular problems or tools. Well-integrated teams
have usually worked on several projects together. Keeping a
team together across several projects is a major job of the team’s
manager and of the individual teammates themselves. Well-
integrated teams are more productive, better at holding to a
schedule, and more likely to produce code with fewer defects
at release. The key to keeping a team together is to give them
interesting work, give them the freedom to decide how to do the
work, and facilitate the process by removing barriers and helping
with conflict resolution.

3
Chapter 1 Introduction to Software Development

Good communication among team members. Continuous direct

communication among team members is critical to day-to-day
progress and successful project completion. Teams that are co-
located are generally better at communicating and communicate
more than teams that are distributed geographically (even if
they’re just on different floors or wings of a building) or that are
working virtually.2 This is a major issue with larger companies that
have software development sites scattered across the globe.

Good communication between the team and the customer.

Communication with the customer is essential to controlling
requirements and requirements churn during a project. On-
site or close-by customers allow for constant interaction
with the development team. Customers can give immediate
feedback on new releases and can be involved in creating
system and acceptance tests for the product. Agile development
methodologies strongly encourage customers to be part of the
development team and, even better, to be on site daily. See
Chapter 2 for a quick introduction to some agile methodologies.

A process that everyone buys into. Every project, no matter how

big or small, follows a process. Larger projects require more
coordination and tighter controls on communication and
configuration management. As a result, larger teams tend to
be more plan-driven and follow processes with more rules and
documentation required. Smaller projects and smaller teams will,
these days, tend to follow more agile development processes, with
more flexibility and less documentation required. This certainly
doesn’t mean there is no process in an agile project; it just means
you do what makes sense for the current stage of your project, so
that you can correctly uncover and satisfy all the requirements,
meet the schedule, and produce a quality product. See Chapter 2
for more details on process and software life cycles.

2
Note that teams that are distributed geographically can also be closer to clients and thus have
better communication with them. Also, the advent of easy and fast conferencing software can
mitigate the disadvantages of remote work.

4
 Chapter 1 Introduction to Software Development

The ability to be flexible about that process. No project ever

proceeds as you think it will on the first day. Requirements
change, people come and go, tools don’t work out or get updated,
and so on. This point is all about handling risk in your project.
If you identify risks, plan to mitigate them, and then have a
contingency plan to address the event where the risk actually
occurs, you’ll be in much better shape. Chapter 4 talks about
requirements and risk.

A plan that everyone buys into. You wouldn’t write a sorting

program without an algorithm to start with, so you shouldn’t
launch a software development project without a plan. The
project plan encapsulates what you’re going to do to implement
your project. It talks about process, risks, resources, tools,
requirements management, estimates, schedules, configuration
management, and delivery. It doesn’t have to be long, it doesn’t
need to contain all the minute details of the everyday life of the
project, and it doesn’t even need to be written down, but everyone
on the team needs to have input into it, they need to understand
it, and they need to agree with it. Unless everyone buys into the
plan, you’re doomed. See Chapter 3 for more details on project
planning.

To know where you are at all times. It’s that communication thing
again. Most projects have regular status meetings so that the
developers can “sync up” on their current status, get a feel for the
status of the entire project, and to create a sense of camaraderie
within the team. This works very well for smaller teams (say, up
to about 20 developers, many of which will have daily “stand-
up” meetings to sync up at the beginning of each day. Different
process models handle this “stand-up” meeting differently. For
instance, plan-driven models don’t require these meetings,
depending on the team managers to communicate with each
other. Agile processes often require all-hands daily meetings
to facilitate constant team communication in a highly dynamic
project environment.

5
Chapter 1 Introduction to Software Development

To be brave enough to say, “hey, we’re behind!” Nearly all software

projects have schedules that are too optimistic at the start. It’s
what clients want to hear, what companies want to offer, and
what managers and developers want to supply. “Sure, I can get
that done in a week!” “I’ll have it to you by the end of the day.”
“Tomorrow? Not a problem.” No, no, no, no, no. Just face it. At
some point you’ll be behind. And the best thing to do about it is
to tell your manager right away. Sure, they might be angry. But
they’ll be angrier when you end up a month behind and they
didn’t know it. Fred Brooks’ famous answer to the question of how
software projects get so far behind is “one day at a time.” The good
news, though, is that the earlier you figure out you’re behind, the
more options you have. These include lengthening the schedule
(unlikely, but it does happen), moving some requirements to a
future release, getting additional help, and so on. The important
part is to keep your manager informed.

The right tools and the right practices for this project. One of the
best things about software development is that every project is
different. Even if you’re doing version 8.0 of an existing product,
things change. One implication of this is that, for every project,
you need to examine and pick the right set of development tools.
Picking tools that are inappropriate is like trying to hammer nails
with a screwdriver; you might be able to do it eventually, but is
sure isn’t easy or pretty or fun, and you can drive a lot more nails
in a shorter period of time with a hammer than with a screwdriver.
Even if you have to first obtain a hammer and then learn how
to use it for the very first time, you are leveling up your toolkit
and your skills in the process, investing in your ability to work
more efficiently going forward. The three most important factors
in choosing tools are the application type you are writing, the
target platform, and the development platform. You usually can’t
do anything about any of these three things, so once you know
what they are, you can pick tools that improve your productivity.
A fourth and nearly as important factor in tool choice is the
composition and experience of the development team. If your

6
 Chapter 1 Introduction to Software Development

team are all experienced developers with facility on multiple

platforms, tool choice is much easier. If, on the other hand, you
have a bunch of fresh-outs and your target platform is new to all of
you, you’ll need to be careful about tool choice and fold in time for
training and practice with the new tools.

Conclusion
Software development is the heart of every software project, and it is the heart of
software engineering. Its objective is to deliver excellent, defect-free code to users on
time and within budget—all in the face of constantly changing requirements. This makes
development a particularly hard job to do. But finding a solution to a difficult problem
and getting your code to work correctly is just about the coolest feeling in the world.

“[Programming is] the only job I can think of where I get to be both an engi-
neer and an artist. There’s an incredible, rigorous, technical element to it,
which I like because you have to do very precise thinking. On the other
hand, it has a wildly creative side where the boundaries of imagination are
the only real limitation. The marriage of those two elements is what makes
programming unique. You get to be both an artist and a scientist. I like that.
I love creating the magic trick at the center that is the real foundation for
writing the program. Seeing that magic trick, that essence of your program,
working correctly for the first time, is the most thrilling part of writing a
program.”
—Andy Hertzfeld (designer of the first Mac OS)3

References
Brooks, F. 1987. “No Silver Bullet.” IEEE Computer 20 (4): 10–19. www.inst.eecs.
berkeley.edu/~maratb/readings/NoSilverBullet.html.
Lammers, Susan. 1986. Programmers At Work. Redmond, WA: Microsoft Press.

3
Lammers, Susan. 1986. Programmers At Work. Redmond, WA: Microsoft Press.

7
CHAPTER 2

Software Process Models

If you don’t know where you’re going, any road will do.
If you don’t know where you are, a map won’t help.
—Watts Humphrey

The process of developing software is commonly described as the Software

Development Lifecycle (SDLC). Every program, no matter how small, has a life cycle,
broadly composed of the following steps:

1. Conception

2. Requirements gathering/exploration/modeling

3. Design

4. Coding and debugging

5. Testing

6. Release
7. Maintenance/software evolution

8. Retirement

Your development process may combine multiple steps or iterate over a subset of steps
repeatedly between releases, but, in one form or another, all development should encompass
all of the above life cycle steps in order to create high-quality software. The two most
common variations are plan-based models1 and the newer agile development models.2

1
Paulk, Mark C. 1995. The Capability Maturity Model: Guidelines for Improving the Software
Process. The SEI Series in Software Engineering. Reading, Mass.: Addison-Wesley Pub. Co.
2
Martin, Robert C. 2003. Agile Software Development, Principles, Patterns, and Practices. Upper
Saddle River, NJ: Prentice Hall.
11
© John F. Dooley and Vera A. Kazakova 2024
J. F. Dooley and V. A. Kazakova, Software Development, Design, and Coding,
https://doi.org/10.1007/979-8-8688-0285-0_2
Chapter 2 Software Process Models

With plan-based development, the project team will generally do a complete life
cycle (at least steps 2 through 7) before going back in the SDLC to start working on the
next version of the product. In plan-driven models, the methodology tends to be stricter
in terms of process steps and when releases happen. Plan-driven models have more
clearly defined phases and more requirements for sign-off on completion of a phase
before moving on to the next phase. Plan-driven models require more documentation at
each phase and verification of completion of each work product. They tend to work well
for large contracts for new software with well-defined deliverables.
In agile development, which is more prevalent now, the project team will usually
iterate over a partial life cycle (usually steps 3 through 5) several times before proceeding
to the release step. The agile models are inherently incremental and operate under the
assumption that small, frequent releases produce a more robust product than larger, less
frequent ones. Phases in agile models tend to blur together more than in plan-driven
models, and there tends to be less documentation of work products required, the basic
idea being that code is what is being produced and so developer efforts should focus
there. See the Agile Manifesto web page at https://agilemanifesto.org to get a good
feel for the agile development model and goals.
There is no one best process for developing software. Each project must decide on
the model that works best for its particular application and base that decision on the
project domain, the scope of the project, the experience of the team, and the timeline
of the project. In this chapter, we begin by reviewing the shared variables of software
development projects, followed by a discussion of the different broadly defined
approaches, and finally we take a look at several prominent specific software model
implementations as well as how they can be hybridized together.

The 3(+3) Variables of Software Development

According to the Project Management Institute,3 the three main variables of software
development are cost, time, and scope.

• Cost (a.k.a. resources) is usually the most constrained; as a developer,

you have very limited control over cost and you cannot spend your
way to quality or to being on schedule. Cost can influence the size

3
Project Management Institute. 2021. A Guide to the Project Management Institute Body of
Knowledge. 7th ed. Project Management Institute, Inc. www.pmi.org.

12
 Chapter 2 Software Process Models

of the team or the types of tools available during development. For

small companies and startups, cost also influences the environment
where the developers will work.

• Time is your delivery schedule and is typically imposed on you

from the outside. For example, most consumer products (be they
hardware or software) will have a delivery date somewhere between
August and October in order to hit the holiday buying season. You
can’t move Christmas. If you are late, the only way to fix your problem
is to drop features or lessen quality, neither of which is pretty. Time is
also where Brooks’ Law gets invoked (adding programmers to a late
project just makes it later).

• Scope (a.k.a. features) is what the product actually does. This is what
developers should always focus on. It’s the most important of the
variables from the customer’s perspective and it is also the one you
as a developer have the most control over. Controlling scope allows
you to provide managers and customers control over quality, time,
and cost. If the developers don’t have control over the feature set for
each release, then they are likely to blow the schedule. This is why
developers should do the estimates for software work products.

Together, cost, time, and scope form the Iron Triangle of software development, in
which specifying two of the variables defines the third. In the real world, a customer will
often specify timeframe and budget for the task, which will then be your constraints to
estimate a realistic scope within the broader task.
Occasionally, a fourth variable is added (usually as the center of the triangle).

• Quality is the number/severity of defects, simplifications, or

functionality reductions you are willing to release with. Thus, quality
may be used to describe non-binary characteristics of features in
your scope (e.g. the time to respond to a user query should be no
more than n milliseconds, but the lower the better). This is not,
strictly speaking, an input variable like cost, time, and scope, but
rather a metric for the quality of your output. You can make short-
term gains in delivery schedules by sacrificing quality, but the cost

13
Chapter 2 Software Process Models

is enormous. It will take more time to fix the next release and your
credibility will be pretty well shot. More commonly, there is an
expected minimum expected quality for the product, fixing this
“variable”.

In some definitions, the scope of the task/product is considered to be fixed or,

otherwise, intertwined with quality, leading instead to an Iron Triangle consisting of
cost, time, and quality.4
More recently, two more variables have been defined as part of the new six-variable
set of constraints:5

• Benefit is the value delivered to the product provider and to the

client. With new information about the market, client needs, or target
audience, benefit may change, requiring changes to scope or to other
variables.

• Risk is the likelihood of not meeting expected values for the

other criteria (such as failing to implement features, increasing
development time, or exceeding the expected budget). Managing
one type of risk may increase another type of risk (e.g., increasing
time makes scope less risky, but is likely to increase cost). To
minimize risk, developers need to control as many of the variables as
possible, always keeping in mind that the only constant of software
development is change. If you pay attention and effectively cope
with change as it occurs, you can keep the risk and cost of change
manageable.

As shown in Figure 2-1, all constraints need to be balanced. Altering one will require
adjusting others to compensate.

4
https://ronjeffries.com/xprog/articles/practices/pracfourvariables/
5
Siegelaub, J. M. 2007. “Six (Yes Six!) Constraints: An Enhanced Model for Project Control.” In
Proceedings of the PMI Global Congress 2007. Atlanta, GA: Project Management Institute, Inc.
www.pmi.org/learning/library/six-constraints-enhanced-model-project-control-7294.
See also https://prince2.wiki/.

14
 Chapter 2 Software Process Models

Figure 2-1. The six variables of software development

A number of other expansions to the variables that define a software development

project have been suggested over the years. For example, The Square Route combines
the Iron Triangle with additional considerations of project evaluation at the delivery
stage and post-delivery stage.6 Additional constrains external to the organization and
the client may also play an important role in the creation of software products, including
social, economic, legislative, environmental, and other factors.7

Software Development Approaches

When it comes to developing software, there are several general approaches, which
can be employed separately or together within an organization or even within a single

6
Atkinson, Roger. 1999. “Project Management: Cost, Time, and Quality, Two Best Guesses and
a Phenomenon, It’s Time to Accept Other Success Criteria.” International Journal of Project
Management 17 (6): 337–42.
7
www.smartsheet.com/content/project-constraints

15
Chapter 2 Software Process Models

project. Below we discuss planning, reducing waste with lean methodologies, and
adapting by remaining agile.

Plan-Based Software Development

The main characteristic of plan-based software development is to make a plan and
then follow through with it. It seems simple enough...except that to make a reliable
plan you need to have all of the information AND that information must not change.
As we are neither omniscient nor clairvoyant, this poses a bit of a problem. We are at
the mercy of imprecise language describing poorly understood requirements that are
devised to solve problems for changing real-world scenarios by teams of predictably
unpredictable humans.
Still, plans are comforting. It allows the illusion that we know what is going to
happen. If we follow a plan and get a result, we hope that following the same plan in the
future will yield the same result. Of course, controlling for all variables (both internal and
external to the project) is impossible. Plans also allow for subplans and estimations for
the entire hierarchy of plans. Granted, the further away the step, the less accurate our
estimation. Plans also allow us to assess dependencies and schedule tasks accordingly.
Of course, any change can tumble the carefully scheduled house of cards which we
painstakingly designed, estimated, sorted, scheduled, and partially developed.
Let’s say we do have a plan: we have devised steps and we will complete them one
by one, in order. For a small project with a single developer, who is also the client, this
may very well work out. In a more realistic scenario, the client is not us, the project is
complex, and we have to coordinate with other stakeholders. Let’s say our basic plan
has a design phase, an implementation phase, a testing phase, and delivery. We take
several months to come up with a beautiful design and show our client, but the client
wants changes. We take a few weeks to make changes to the design; the client approves.
We make a development plan and attempt to implement our design over the next several
months. In that time, some of the libraries we were relying on have been deprecated,
some developers leave, new ones join the team, the market changes, causing the client to
request changes to the design, and ultimately our development plan and our design are
both obsolete. Do-over time... To make matters worse, so far we have delivered no value
to the client and they are starting to lose confidence that we ever will. To recap, making
reliable short plans for small projects is doable; anything else is wishful thinking.

16
 Chapter 2 Software Process Models

Agile Software Development

Starting in the mid-1990s, a group of process mavens began advocating a new model for
software development. Targeting medium-sized software projects and smaller teams of
developers, the new approach was intended to allow teams to quickly adjust to changing
requirements and customer demands, while also releasing functional software much more
quickly and frequently than under plan-driven models. The new model was, in a word, agile.8
In most agile process models, we start with the “known” requirements (a snapshot of
the requirements at some time early in the process) and prioritize them, typically based
on the customer’s ranking of what features are most important to deliver first. Keep in
mind that what we think we know or understand about these requirements is commonly
only somewhat accurate: natural language is imprecise; the understood meanings differ
based on communicator background, positionality, and other context; and clients often
do not necessarily understand what they want or need to solve their problem. Thus, one
of our most important challenges in software development is to iteratively approach an
accurate shared understanding of the problem and the prospective solution. According to
Tom DeMarco, iterative software development follows one basic rule:
Your project, the whole project, has a binary deliverable. On the scheduled
completion day, the project has either delivered a system that is accepted by
the user, or it hasn’t. Everyone knows the result on that day.
The object of building a project model is to divide the project into compo-
nent pieces, each of which has this same characteristic: each activity must
be defined by a deliverable with objective completion criteria. The deliver-
ables are demonstrably done or not done.9

Rather loosely, we can devise a series of iterations, where each iteration is a complete
Minimum Viable Product (MVP), working and robust, albeit with fewer features than
the final goal product. For each iteration, we will select a set of the next highest priority
requirements (including some you or the customer may have discovered during the
previous iteration), develop, test, and demo the MVP, and gather feedback. This feedback
may drastically alter our initial plan, which is why our initial plan is only a loose sketch of
future development iterations.

8
Cockburn, A. 2002. Agile Software Development. Boston, MA: Addison-Wesley.
9
DeMarco, Tom. 1983. Controlling Software Projects: Management, Measurement and Estimation.
Yourdon Press.

17
Chapter 2 Software Process Models

So what happens if you estimate wrong? What if you decide to include too many new
features in an iteration? What if there are unexpected delays? Well, if it looks as if you
won’t make your iteration deadline there are only two realistic alternatives: move the
deadline or remove features. We’ll come back to this problem later when we talk about
estimation and scheduling. The key to iterative development is “live a balanced life—
learn some and think some and draw and paint and sing and dance and play and work
every day some,”10 or in the software development world, analyze some and design some
and code some and test some every day. We’ll revisit this idea when we talk about the
agile development models later in this chapter.
Overall, agile is composed of ongoing short-term experiments, iteratively reviewed
to evaluate product and practices, and to find processes that work for the team and the
client. In other words, some good old-fashioned trial and error. While some failure is
inevitable, it is more informative and less costly to fail on small increments, to fail early,
and to learn from it quickly. Thus, we reduce the pressure of needing our intermediates
to be right, requiring only that these decision are useful in helping us learn more about
what was actually needed.
Agile development works from the proposition that the goal of any software
development project is working code. Consequently, the development team should spend
most of their time writing code, not documentation. As opposed to the heavyweight plan-
driven models mentioned above and espoused by groups like the Software Engineering
Institute (SEI) at Carnegie Mellon University,11 this new process model was lightweight,
requiring less documentation and fewer process controls. Lightweight methodologies
tend to emphasize writing tests before code, frequent product releases, significant
customer involvement in development, common code ownership, and refactoring
(rewriting code to make it simpler and easier to maintain). Lightweight methodologies do,
unfortunately, suffer from several myths, the two most pernicious being that lightweight
processes are only good for very small projects and that lightweight projects lack process
discipline. Both of these are incorrect. The truth is that lightweight methodologies have
been successfully used in many small and medium-sized projects (say up to about 500K
lines of code), as well as in very large projects. Larger projects can nearly always be
organized as a set of smaller projects, which together provide services to the single larger

10
Fulghum, Robert. 1986. All I Really Need to Know I Learned in Kindergarten. New York, NY:
Ivy Books.
11
(Paulk 1995)

18
 Chapter 2 Software Process Models

product. Lightweight methodologies also require process discipline, especially in the

beginning of a project, when initial requirements and an iteration cycle are created, and
in the test-driven-development used as the heart of the coding process.
In the remainder of the chapter, we will review the agile values, principles, and
activities that have been defined over the years. Note, however, that agility necessarily
extends to how these concepts and practices are ultimately incorporated into development
(i.e., to iteratively determine what works and what does not for each particular product/
organization/team/etc.).

Agile Values, Principles, and Activities

In early 2001, a group of experienced and innovative developers met in Snowbird, Utah,
to talk about the state of the software development process. All of them were dissatisfied
with traditional plan-driven models and had been experimenting with new lightweight
development techniques. Out of this meeting came the Agile Manifesto.12 The original
description proposed by the group included two parts: values (the manifesto itself ) and
principles.
The four Agile Values showcase that while the authors recognize the value of the
items on the right, they view the items on the left as the most crucial to successful
software development:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
The following 12 Agile Principles were defined by the authors to focus and guide
development:
• Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile
processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.

12
https://agilemanifesto.org/
19
Chapter 2 Software Process Models

• Business people and developers must work together daily throughout

the project.

• Build projects around motivated individuals. Give them the

environment and support they need, and trust them to get the job done.

• The most efficient and effective method of conveying information to

and within a development team is face-to-face conversation.

• Working software is the primary way to measure progress.

• Agile processes promote sustainable development. The sponsors,

developers, and users should be able to maintain a constant pace
indefinitely.

• Continuous attention to technical excellence and good design

enhances agility.

• Simplicity—the art of maximizing the amount of work not done—is

essential.

• The best architectures, requirements, and designs emerge from self-

organizing teams.

• At regular intervals, the team reflects on how to become more

effective, then tunes and adjusts its behavior accordingly.

The following four main Agile Activities (although originally defined as part of the
Agile variant called eXtreme Programming) are applicable for all Agile methodologies:
Design while you code. In real world domains, all the requirements aren’t
typically known or correctly understood in advance. Mistakes and oversights will
be made in architectural design, detailed design, and coding. Additionally, during
product development, requirements and constraints may change, as no project
exists in a vacuum, away from real world events such as turnover in the development
team, updates to customer needs due to market changes, the development of new
technologies, and so on. Agile software development models build products a piece
at a time, with each product increment allowing for several crucial events to happen
earlier and more frequently: delivery of value to the customer, feedback gathering,
and adaptation to changes. Designing while coding allows more developer freedom to
choose how to deliver on the tasks, promoting developer agency while increasing their
responsibility to self-manage.

20
 Chapter 2 Software Process Models

Direct communication is best, although what “direct” means has shifted greatly in
recent years. We see “direct communication” as happening in real time, with direct
exposure to both verbal and non-verbal cues, which would encompass in-person
discussions, video conferencing, and even advanced virtual environments. In any given
software development project, there are two types of knowledge: 1) the customer has
domain knowledge and what understanding of what the system is supposed to do and
2) the developers have technical knowledge about the target platform, programming
language(s), and possible implementation issues. The customer doesn’t know the
technical side and the developers don’t have the domain knowledge, so effective
communication—on both sides—is a key activity in developing the product. Frequent
communication means everyone is learning from everyone’s process, creating a more
well-rounded shared understanding faster.
Code is the main deliverable. The fundamental difference between plan-driven
models and agile models is this emphasis on the code, as code is where system
knowledge resides. In a plan-driven model, the emphasis is on producing a set of work
products that together represent the entire work of the project with code being just one
of the work products. In agile methodologies, the emphasis is placed squarely with code
as the deliverable; in addition, by structuring the code properly and keeping comments
up to date, the code itself becomes documentation for the project.
Test-driven development. Test cases for the required features are written before
development takes place and should all initially fail. Once all tests for a feature pass,
the feature implementation is completed. Test-driven development is instrumental for
managing change, as continuous testing tells you when a new feature is completed and
integrated into the system without breaking any of the pre-existing functionality.

Lean Software Development

Lean software development comes from the just-in-time manufacturing processes (also
known as the Toyota Production System, among other names), which were introduced
in Japan in the 1970s and then made their way around the world in the 1980s and 1990s,
encouraged by the publication in 1990 of The Machine That Changed The World13

Womack, James P., Daniel T. Jones, and Daniel Roos. 1990. The Machine That Changed the
13

World: The Story of Lean Production -- Toyota’s Secret Weapon in the Global Car Wars That Is Now
Revolutionizing World Industry. New York, NY: Simon and Schuster.

21
Chapter 2 Software Process Models

(Womack et. al.). Just-in-time manufacturing evolved first into lean manufacturing and
then into lean product management systems throughout the 1990s. The publication of
Poppendieck & Poppendieck’s Lean Software Development: An Agile Toolkit14 in 2003
marked the movement of lean into the agile development community.
Lean software development is a set of principles designed to eliminate waste in
order to improve productivity, quality, and customer satisfaction. Waste is anything that
does not add value to the product. Thus, lean emphasizes that the team should only be
focusing on activities that add immediate value to the product.
The Poppendiecks14 transformed the lean principles that started at Toyota into seven
key principles for software development:

• Eliminate waste

• Build quality in

• Create knowledge

• Defer commitment

• Deliver fast

• Respect people

• Optimize the whole

We will go through each of these principles briefly to illustrate how they apply to
software development.

Lean Principle 1: Eliminate Waste

The main goal of lean software development is to eliminate waste, defined as anything
that does not add value to the product or increases its cost or time. In software
development, the main sources of waste are the following:

• Partially done work, as it adds no immediate value and may become

obsolete before it is finished

Poppendieck, Mary, and Tom Poppendieck. 2003. Lean Software Development: An Agile Toolkit.
14

Upper Saddle River, NJ: Addison-Wesley Professional.

22
Another Random Scribd Document
with Unrelated Content
This book was produced in EPUB format by the Internet Archive.

The book pages were scanned and converted to EPUB format

automatically. This process relies on optical character recognition,
and is somewhat susceptible to errors. The book may not offer the
correct reading sequence, and there may be weird characters, non-
words, and incorrect guesses at structure. Some page numbers and
headers or footers may remain from the scanned page. The process
which identifies images might have found stray marks on the page
which are not actually images from the book. The hidden page
numbering which may be available to your ereader corresponds to
the numbered pages in the print edition, but is not an exact match;
page numbers will increment at the same rate as the corresponding
print edition, but we may have started numbering before the print
book's visible page numbers. The Internet Archive is working to
improve the scanning process and resulting books, but in the
meantime, we hope that this book will be useful to you.

The Internet Archive was founded in 1996 to build an Internet

library and to promote universal access to all knowledge. The
Archive's purposes include offering permanent access for
researchers, historians, scholars, people with disabilities, and the
general public to historical collections that exist in digital format. The
Internet Archive includes texts, audio, moving images, and software
as well as archived web pages, and provides specialized services for
information access for the blind and other persons with disabilities.

Created with hocr-to-epub (v.1.0.0)

The text on this page is estimated to be only 4.80%
accurate

; ... . fKS AND TRIBES (.;- f.O-irriJKKN INDIA Jt

 THE LIBRARY OF THE UNIVERSITY OF CALIFORNIA LOS
ANGELES
The text on this page is estimated to be only 0.00%
accurate

■;
CASTES AND TRIBES OF SOUTHERN INDIA
 Digitized by the Internet Archive in 2007 with funding from
Microsoft Corporation
http://www.archive.org/details/castestribesofso02thuriala
 CASTES AND TRIBES OF SOUTHERN INDIA BY EDGAR
THURSTON, c.i.e., Superintendent, Madras Government Museum ;
Correspondant Etranger, Socigte' d'Anthropologie de Paris ; Socio
Corrispondante, Societa Romana di Anthropologia. ASSISTED BY K.
RANGACHARI, m.a., of the Madras Government Museum. VOLUME II
— C to J GOVERNMENT PRESS, MADRAS 1909.
 College Library 450 T4^c CASTES AND TRIBES OF
SOUTHERN INDIA. VOLUME II. j^pftANJI (gruel). — An exogamous
sept of Padma m|||^ Sale. Canji is the word " in use all over India
for the water, in which rice has been boiled. It also forms the usual
starch of Indian washermen."* As a sept of the Sale weavers, it
probably has reference to the gruel, or size, which is applied to the
warp. Chacchadi.— Haddis who do scavenging work, with whom
other Haddis do not freely intermarry. Chadarapu Dhompti (square
space marriage offering).— A sub-division of Madigas, who, at
marriages, offer food to the god in a square space. Chakala.— See
Tsakala. Chakkan.— -Recorded in the Madras Census Report, 1 90 1,
as " a Malabar caste of oil-pressers (chakku means an oil-mill).
Followers of this calling are known also as Vattakkadans in South
Malabar, and as Vaniyans in North Malabar, but the former are the
higher in social status, the Nayars being polluted by the touch of the
Vaniyans and Chakkans, but not by that of the Vattakkadans.
Chakkans and Vaniyans may not enter Brahman temples. Their
customs and manners are similar to those of the Nayars, who will
not, however, * Yule and Burnell. Hobson-Jobson. 2005010
 CHAKKILIYAN 2 marry their women." Chakkingalavan
appears as a synonym for Chakkan. Chakkiliyan.— " The
Chakkiliyans," Mr. H. A. Stuart writes,* "are the leather-workers of
the Tamil districts, corresponding to the Madigas of the Telugu
country. The Chakkiliyans appear to be immigrants from the Telugu
or Canarese districts, for no mention is made of this caste either in
the early Tamil inscriptions, or in early Tamil literature. Moreover, a
very large proportion of the Chakkiliyans speak Telugu and
Canarese. In social position the Chakkiliyans occupy the lowest rank,
though there is much dispute on this point between them and the
Paraiyans. Nominally they are Saivites, but in reality devil-
worshippers. The avaram plant {Cassia auriculata) is held in much
veneration by them,t and the tali is tied to a branch of it as a
preliminary to marriage. Girls are not usually married before puberty.
The bridegroom may be younger than the bride. Their widows may
remarry. Divorce can be obtained at the pleasure of either party on
payment of Rs. 1 2-1 2-0 to the other in the presence of the local
head of the caste. Their women are considered to be very beautiful,
and it is a woman of this caste who is generally selected for the
coarser form of Sakti worship. They indulge very freely in
intoxicating liquors, and will eat any flesh, including beef, pork, etc.
Hence they are called, par excellence, the flesh-eaters (Sanskrit
shatkuli)." It was noted by Sonnerat, in the eighteenth century, J
that the Chakkiliyans are in more contempt than the Pariahs,
because • Manual of the North Arcot district. t The bark of the
avaram plant is one of the most valuable Indian tanning agents. %
Voyage to the East Indies, 1774 and 1781.
 3 CHAKKILIYAN they use cow leather in making shoes. "
The Chucklers or cobblers," the Abbe" Dubois writes,* "are
considered inferiors to the Pariahs all over the peninsula. They are
more addicted to drunkenness "and debauchery. Their orgies take
place principally in the evening, and their villages resound, far into
the night, with the yells and quarrels which result from their
intoxication. The very Pariahs refuse to have anything to do with the
Chucklers, and do not admit them to any of their feasts." In the
Madura Manual, 1868, the Chakkiliyans are summed up as " dressers
of leather, and makers of slippers, harness, and other leather
articles. They are men of drunken and filthy habits, and their morals
are very bad. Curiously enough, their women are held to be of the
Padmani kind, i.e., of peculiar beauty of face and form, and are also
said to be very virtuous. It is well known, however, that zamindars
and other rich men are very fond of intriguing with them, particularly
in the neighbourhood of Paramagudi, where they live in great
numbers." There is a Tamil proverb that even a Chakkili girl and the
ears of the millet are beautiful when mature. In the Tanjore district,
the Chakkiliyars are said t to be " considered to be of the very lowest
status. In some parts of the district they speak Telugu and wear the
namam (Vaishnavite sect mark) and are apparently immigrants from
the Telugu country." Though they are Tamil-speaking people, the
Chakkiliyans, like the Telugu Madigas, have exogamous septs called
gotra in the north, and kilai in the south. Unlike the Madigas, they do
not carry out the practice of making Basavis (dedicated prostitutes).
* Hindu Manners, Customs and Ceremonies, t Manual of the Tanjore
district, 1883. II— I B
 CHAKKILIYAN 4 The correlation of the most important
measurements of the Madigas of the Telugu country, and so-called
Chakkiliyans of the city of Madras, is clearly brought out by the
following figures : — Thirty Fifty Madigas. Chakkiliyans. cm. cm.
Stature ... ... ... ... 163*1 162*2 Cephalic length 18*6 18" 6 „
breadth ... ... 13*9 13*9 » index 75* 75* Nasal height 4*5 4*6 „
breadth 3*7 3*6 „ index ... ... ... 8o*8 78*9 The Chakkiliyan men in
Madras are tattooed not only on the forehead, but also with their
name, conventional devices, dancing-girls, etc., on the chest and
upper extremities. It has been noticed as a curious fact that, in the
Madura district, ''while the men belong to the righthand faction, the
women belong to and are most energetic supporters of the left. It is
even said that, during the entire period of a faction riot, the Chakkili
women keep aloof from their husbands and deny them their marital
rights." # In a very interesting note on the leather industry of the
Madras Presidency, Mr. A. Chatterton writes as follows.t " The
position of the Chakkiliyan in the south differs greatly from that of
the Madiga of the north, and many of his privileges are enjoyed by a
' sub-sect' of the Pariahs called Vettiyans. These people possess the
right of removing dead cattle from villages, and in return • Manual of
the Madura district. f Monograph of Tanning and Working in Leather,
1904.
 5 CHAKKILIYAN have to supply leather for agricultural
purposes. The majority of Chakkiliyans are not tanners, but
leatherworkers, and, instead of getting the hides or skins direct from
the Vettiyan, they prefer to purchase them readytanned from
traders, who bring them from the large tanning centres. When the
Chuckler starts making shoes or sandals, he purchases the leather
and skin which he requires in the bazar, and, taking it home, first
proceeds with a preliminary currying operation. The leather is
damped and well stretched, and dyed with aniline, the usual colour
being scarlet R.R. of the Badische Anilin Soda Fabrik. This is
purchased in the bazar in packets, and is dissolved in water, to which
a little oxalic acid has been added. The dye is applied with a piece of
rag on the grain side, and allowed to dry. After drying, tamarind
paste is applied to the flesh side of the skin, and the latter is then
rolled between the hands, so as to produce a coarse graining on the
outer side. In making the shoes, the leather is usually wetted, and
moulded into shape on wooden moulds or lasts. As a rule, nothing
but cotton is used for sewing, and the waxed ends of the English
cobler are entirely unknown. The largest consumption of leather in
this Presidency is for water-bags or kavalais, which are used for
raising water from wells, and for oil and ghee (clarified butter) pots,
in which the liquids are transported from one place to another. Of
irrigation wells there are in the Presidency more than 600,000, and,
though some of them are fitted with iron buckets, nearly all of them
have leather bags with leather discharging trunks. The buckets hold
from ten to fifty gallons of water, and are generally made from fairly
well tanned cow hides, though for very large buckets buffalo hides
are sometimes used. The number of oil and ghee pots in use in the
country is very large.
 CHAKKILIYAN 6 The use of leather vessels for this purpose
is on the decline, as it is found much cheaper and more convenient
to store oil in the ubiquitous kerosine-oil tin, and it is not improbable
that eventually the industry will die out, as it has done in other
countries. The range of work of the country Chuckler is not very
extensive. Besides leather straps for wooden sandals, he makes
crude harness for the ryot's cattle, including leather collars from
which numerous bells are frequently suspended, leather whips for
the cattle drivers, ornamental fringes for the bull's forehead, bellows
for the smith, and small boxes for the barber, in which to carry his
razors. In some places, leather ropes are used for various purposes,
and it is customary to attach big coir (cocoanut fibre) ropes to the
bodies of the larger temple cars by leather harness, when they are
drawn in procession through the streets. Drum-heads and tom-toms
are made from raw hides by Vettiyans and Chucklers. The drums are
often very large, and are transported upon the back of elephants,
horses, bulls and camels. For them raw hides are required, but for
the smaller instruments sheep-skins are sufficient. The raw hides are
shaved on the flesh side, and are then dried. The hair is removed by
rubbing with wood-ashes. The use of lime in unhairing is not
permissible, as it materially decreases the elasticity of the
parchment." The Chakkiliyans beat the tom-tom for Kammalans,
Pallis and Kaikolans, and for other castes if desired to do so. The
Chakkiliyans do not worship Matangi, who is the special deity of the
Madigas. Their gods include Madurai Viran, Mariamma, Muneswara,
Draupadi and Gangamma. Of these, the last is the most important,
and her festival is celebrated annually, if possible. To cover the
expenses thereof, a few Chakkiliyans dress up
 7 CHAKKIYAR so as to represent men and women of the
Marathi birdcatching caste, and go about begging in the streets for
nine days. On the tenth day the festival terminates. Throughout it,
Gangamma, represented by three decorated pots under a small
pandal (booth) set up on the bank of a river or tank beneath a
margosa (Melia azadirachta), or pipal (Ficus reli%iosa) tree, is
worshipped. On the last day, goats and fowls are sacrificed, and
limes cut. During the first menstrual period, the Chakkiliyan girl is
kept under pollution in a hut made of fresh green boughs, which is
erected by her husband or maternal uncle. Meat, curds, and milk are
forbidden. On the last day, the hut is burnt down. At marriages a
Chakkiliyan usually officiates as priest, or the services of a Valluvan
priest may be enlisted. The consent of the girl's maternal uncle to
the marriage is essential. The marriage ceremony closely resembles
that of the Paraiyans. And, at the final death ceremonies of a
Chakkiliyan, as of a Paraiyan, two bricks are worshipped, and thrown
into a tank or stream. Lean children, especially of the Mala, Madiga,
and Chakkiliyan classes, are made to wear a leather strap, specially
made for them by a Chakkiliyan, which is believed to help their
growth. At times of census, some Chakkiliyans have returned
themselves as Pagadaiyar, Madari (conceit or arrogance), and
Ranaviran (brave warrior). Chakkiyar. — The Chakkiyars are a class
of Ambalavasis, of whom the following account is given in the
Travancore Census Report, 1901. The name is generally derived from
Slaghyavakkukar (those with eloquent words), and refers to the
traditional function of the caste in Malabar society. According to the
Jatinirnaya, the
 CHAKKIYAR 8 Chakkiyars represent a caste growth of the
Kaliyuga. The offence to which the first Chakkiyar owes his position
in society was, it would appear, brought to light after the due
performance of the upanayanasamskara. Persons, in respect of
whom the lapse was detected before that spiritualizing ceremony
took place, became Nambiyars. Manu derives Suta, whose functions
are identical with the Malabar Chakkiyar, from a pratiloma union, i.e.,
of a Brahman wife with a Kshatriya husband.* The girls either marry
into their own caste, or enter into the sambandham form of alliance
with Nambutiris. They are called Illottammamar. Their jewelry
resembles that of the Nambutiris. The Chakkiyar may choose a wife
for sambandham from among the Nambiyars. They are their own
priests, but the Brahmans do the purification (punyaham) of house
and person after birth or death pollution. The pollution itself lasts for
eleven days. The number of times the Gayatri (hymn) may be
repeated is ten. The traditional occupation of the Chakkiyans is the
recitation of Puranic stories. The accounts of the Avataras have been
considered the highest form of scripture of the non-Brahmanical
classes, and the early Brahmans utilised the intervals of their Vedic
rites, i.e., the afternoons, for listening to their recitation by castes
who could afford the leisure to study and narrate them. Special
adaptations for this purpose have been composed by writers like
Narayana Bhattapada, generally known as the Bhattatirippat, among
whose works Dutavakya, Panchalisvayamvara, Subhadrahana and
Kaunteyashtaka are the most popular. In addition to these, standard
works like Bhogachampu and Mahanataka are often • Pratiloma, as
opposed to an anuloma union, is the marriage of a female of a
higher caste with a man of a lower one.
 9 CHAKKIYAR pressed into the Chakkiyar's service.
Numerous upakathas or episodes are brought in by way of
illustration, and the marvellous flow of words, and the telling
humour of the utterances, keep the audience spell-bound. On the
utsavam programme of every important temple, especially in North
Travancore, the Chakkiyarkuttu (Chakkiyar's performance) is an
essential item. A special building, known as kuttampalam, is
intended for this purpose. Here the Chakkiyar instructs and regales
his hearers, antiquely dressed, and seated on a threelegged stool.
He wears a peculiar turban with golden rim and silk embossments. A
long piece of cloth with coloured edges, wrapped round the loins in
innumerable vertical folds with an elaborateness of detail difficult to
describe, is the Chakkiyar's distinctive apparel. Behind him stands
the Nambiyar, whose traditional kinship with the Chakkiyar has been
referred to, with a big jar-shaped metal drum in front of him called
milavu, whose bass sound resembles the echo of distant thunder.
The Nambiyar is indispensable for the Chakkiyarkuttu, and sounds
his mighty instrument at the beginning, at the end, and also during
the course of his recitation, when the Chakkiyar arrives at the middle
and end of a Sanskrit verse. The Nangayar, a female of the Nambiyar
caste, is another indispensable element, and sits in front of the
Chakkiyar with a cymbal in hand, which she sounds occasionally. It is
interesting to note that, amidst all the boisterous merriment into
which the audience may be thrown, there is one person who has to
sit motionless like a statue. If the Nangayar is moved to a smile, the
kuttu must stop, and there are cases where, in certain temples, the
kuttu has thus become a thing of the past. The Chakkiyar often
makes a feint of representing some of his audience as his characters
 CHAKKIYAR lO for the scene under depictment. But he does
it in such a genteel way that rarely is offence taken. It is an
unwritten canon of Chakkiyarkuttu that the performance should stop
at once if any of the audience so treated should speak out in answer
to the Chakkiyar, who, it may be added, would stare at an admiring
listener, and thrust questions on him with such directness and force
as to need an extraordinary effort to resist a reply. And so realistic is
his performance that a tragic instance is said to have occurred when,
by a cruel irony of fate, his superb skill cost a Chakkiyar his life.
While he was explaining a portion of the Mahabharata with
inimitable theatrical effect, a desperate friend of the Pandavas rose
from his seat in a fit of uncontrollable passion, and actually knocked
the Chakkiyar dead when, in an attitude of unmistakable though
assumed heartlessness, he, as personating Duryodhana, inhumanely
refused to allow even a pin-point of ground to his exiled cousins.
This, it is believed, occurred in a private house, and thereafter kuttu
was prohibited except at temples. It is noted, in the Gazetteer of
Malabar, that " Chakkiyars or Slaghyar-vakukar are a caste following
makkattayam (inheritance from father to son), and wear the punul
(thread). They are recruited from girls born to a Nambudiri woman
found guilty of adultery, after the date at which such adultery is
found to have commenced, and boys of similar origin, who have
been already invested with the sacred thread. Boys who have not
been invested with the punul when' their mother is declared an
adulteress, join the class known as Chakkiyar Nambiyars, who follow
marumakkattayam (inheritance in the female line), and do not wear
the thread. The girls join either caste indifferently. Chakkiyars may
 1 1 CHALIYAN marry Nangiyars, but Chakkiyar Nambiyars
may not marry Illotammamar." Chaliyan.— The Chaliyans are a caste
of Malayalam cotton weavers, concerning whom Mr. Francis writes as
follows*: — " In dress and manners they resemble the artisan castes
of Malabar, but, like the Pattar Brahmans, they live in streets, which
fact probably points to their being comparatively recent settlers from
the east coast. They have their own barbers called Potuvans, who
are also their purohits. They do not wear the sacred thread, as the
Sale weavers of the east coast do. They practise ancestor worship,
but without the assistance of Brahman priests. This is the only
Malabar caste which has anything to do with the right and left-hand
faction disputes, and both divisions are represented in it, the left
hand being considered the superior. Apparently, therefore, it settled
in Malabar some time after the beginnings of this dispute on the east
coast, that is, after the eleventh century A. D. Some of them follow
the marumakkatayam and others the makkatayam law of
inheritance, which looks as if the former were earlier settlers than
the latter." The Chaliyans are so called because, unlike most of the
west coast classes, they live in streets, and Teruvan (teru, a street)
occurs as a synonym for the caste name. The right-hand section are
said to worship the elephant god Ganesa, and the left Bhagavati.
The following account of the Chaliyans is given in the Gazetteer of
the Malabar district : " Chaliyans are almost certainly a class of
immigrants from the east coast. They live in regular streets, a
circumstance strongly supporting this view. The traditional account *
Madras Census Report, 1901.
 CHALIYAN 12 is to the same effect. It is said that they were
originally of a high caste, and were imported by one of the
Zamorins, who wished to introduce the worship of Ganapathi, to
which they are much addicted. The latter's minister, the Mangatt
Acchan, who was entrusted with the entertainment of the new
arrivals, and was nettled by their fastidiousness and constant
complaints about his catering, managed to degrade them in a body
by the trick of secretly mixing fish with their food. They do not, like
their counterparts on the east coast, wear the thread ; but it is
noticeable that their priests, who belong to their own caste, wear it
over the right shoulder instead of over the left like the Brahman's
punul, when performing certain pujas (worship). In some parts, the
place of the regular punul is taken by a red scarf or sash worn in the
same manner. They are remarkable for being the only caste in
Malabar amongst whom any trace of the familiar east coast division
into right-hand and left-hand factions is to be found. They are so
divided ; and those belonging to the right-hand faction deem
themselves polluted by the touch of those belonging to the left-hand
sect, which is numerically very weak. They are much addicted to
devil-dancing, which rite is performed by certain of their numbers
called Komarams in honour of Bhagavathi and the minor deities
Vettekkorumagan and Gulikan (a demon). They appear to follow
makkatayam (descent from father to son) in some places, and
marumakkatayam (inheritance in the female line) in others. Their
pollution period is ten days, and their purification is performed by
the Talikunnavan (sprinkler), who belongs to a somewhat degraded
section of the caste." The affairs of the caste are managed by
headmen called Uralans, and the caste barber, or Pothuvan, acts as
 13 CHALIYAN the caste messenger. Council meetings are
held at the village temple, and the fines inflicted on guilty persons
are spent in celebrating puja (worship) thereat. When a girl reaches
puberty, the elderly females of Uralan families take her to a tank,
and pour water over her head from small cups made of the leaves of
the jak (Artocarpus integrifolia) tree. She is made to sit apart on a
mat in a room decorated with young cocoanut leaves. Round the
mat raw rice and paddy (unhusked rice) are spread, and a vessel
containing cocoanut flowers and cocoanuts is placed near her. On
the third evening, the washerman (Peruvannan) brings some newly-
washed cloths (mattu). He is presented with some rice and paddy,
which he ties up in a leaf, and does puja. He then places the cloths
on a plank, which he puts on his head. After repeating some songs
or verses, he sets it down on the floor. Some of the girl's female
relations take a lighted lamp, a pot of water, a measure of rice, and
go three times round the plank. On the following day, the girl is
bathed, and the various articles which have been kept in her room
are thrown into a river or tank. Like many other Malabar castes, the
Chaliyans perform the tali kettu ceremony. Once in several years, the
girls of the village who have to go through this ceremony are
brought to the house of one of the Uralans, where a pandal (booth)
has been set up. Therein a plank, made of the wood of the pala tree
(Alstonia scholaris), a lighted lamp, betel leaves and nuts, a measure
of raw rice, etc., are placed. The girl takes her seat on the plank,
holding in her right hand a mimic arrow (shanthulkol). The
Pothuvan, who receives a fanam (coin) and three bundles of betel
leaves for his services, hands the tali to a male member of an Uralan
family, who ties it on the girl's neck.
 CHALLA 14 On the day before the wedding-day the
bridegroom, accompanied by his male relations, proceeds to the
house of the bride, where a feast is held. On the following day the
bride is bathed, and made to stand before a lighted lamp placed on
the floor. The bridegroom's father or uncle places two gold fanams
(coins) in her hands, and a further feast takes place. In the seventh
month of pregnancy, the ceremony called puli kudi (or drinking
tamarind) is performed. The woman's brother brings a twig of a
tamarind tree, and, after the leaves have been removed, plants it in
the yard of the house. The juice is extracted from the leaves, and
mixed with the juice of seven cocoanuts. The elderly female relations
of the woman give her a little of the mixture. The ceremony is
repeated during three days. Birth pollution is removed by a barber
woman sprinkling water on the ninth day. The dead are buried. The
son carries a pot of water to the grave, round which he takes it
three times. The barber makes a hole in the pot, which is then
thrown down at the head of the grave. The barber also tears off a
piece of the cloth, in which the corpse is wrapped. This is, on the
tenth day, taken by the son and barber to the sea or a tank, and
thrown into it. Three stones are set up over the grave. Chaliyan also
occurs as an occupational title or subdivision of Nayars, and
Chaliannaya as an exogamous sept of Bant. In the Madras Census
Report, 1901, Chaliyan is given as a sub-caste of Vaniyan
(oilpressers). Some Chaliyans are, however, oilmongers by
profession. Challa. — Challa, meaning apparently eaters of refuse,
occurs as a sub-division of Yanadis, and meaning buttermilk as an
exogamous sept of Devanga. Challakuti,
 15 CHANDRA meaning those who eat old or cold food, is an
exogamous sept of Kapus. Chamar.— Nearly three hundred members
of this Bengal caste of tanners and workers in leather were returned
at the census, 1901. The equivalent Chamura occurs as the name of
leather-workers from the Central Provinces. Chandala.— At the
census, 1901, more than a thousand individuals returned themselves
as Chandala, which is defined as a generic term, meaning one who
pollutes, to many low castes. "It is," Surgeon- Major W. R. Cornish
writes,* " characteristic of the Brahmanical intolerance of the
compilers of the code that the origin of the lowest caste of all (the
Chandala) should be ascribed to the intercourse of a Sudra man and
a Brahman woman, while the union of a Brahman male with a Sudra
woman is said toi have resulted in one of the highest of the mixed
classes." By Manu it was laid down that " the abode of the Chandala
and Swapaca must be^out of the town. They must not have the use
of entire vessels. Their sole wealth must be dogs and asses. Their
clothes must be the mantles of the deceased ; their dishes for food
broken pots ; their ornaments rusty iron ; continually must they
roam from place to place. Let no man who regards his duty, religious
and civil, hold any intercourse with them, and let food be given to
them in potsherds, but not by the hand of the giver." Chandra
(moon). — An exogamous sept of Kuruba. The name
Chandravamsapu (moon people) is taken by some Razus, who claim
to be Kshatriyas, and to be descended from the lunar race of kings
of the Mahabharata. * Madras Census Report, 1871.
 CHANIPOYINA 1 6 Chanipoyina (those who are dead). —
An exogamous sept of Orugunta Kapu. Chapa (mat). — An
exogamous sept of Boya. Chappadi (insipid). — An exogamous sept
of Jogi. Chapparam (a pandal or booth). — An exogamous sept of
Devanga. Chappar band.— The Chapparbands are manufacturers of
spurious coin, who hail from the Bombay Presidency, and are
watched for by the police. It is noted, in the Police Report, 1904,
that good work was done in Ganjam in tracing certain gangs of
these coiners, and bringing them to conviction. For the following
note I am indebted to a report * by Mr. H. N. Alexander of the
Bombay Police Department. The name Chapparband refers to their
calling, chapa meaning an impression or stamp. " Among themselves
they are known as Bhadoos, but in Hindustan, and among Thugs
and cheats generally, they are known as Khoolsurrya, i.e., false
coiners. While in their villages, they cultivate the fields, rear poultry
and breed sheep, while the women make quilts, which the men sell
while on their tours. But the real business of this class is to make
and pass off false coin. Laying aside their ordinary Muhammadan
dress, they assume the dress and appearance of fakirs of the
Muddar section, Muddar being their Pir, and, unaccompanied by their
women, wander from village to village. Marathi is their language,
and, in addition, they have a peculiar slang of their own. Like all
people of this class, they are superstitious, and will not proceed on
an expedition unless a favourable omen is obtained. The following
account is given, showing how the false coin is manufactured. A *
Madras Police Gazette, 1902.
Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.

Let us accompany you on the journey of exploring knowledge and

personal growth!

ebookfinal.com