 |
It is my hobby to be writing codes of program (software design) not until when I’ have joined IEEE computer society, that I realized that software design is more than staying in isolation and be writing C++ codes or V.B codes. Any time I go through the monthly magazine of the society, I always come across something innovative (genuine). On every innovation found in the magazine, I go on research. Part of the research coming from the E-voting system current used in India and partly uses in America. It was discovered that different designer/engineer came up with different method of designing E-voting machine and not any has been proved standard because each of them has one or more deficiency. This brought about the heading of an article in one of the IEEE monthly magazine that reads “E-voting technology is not ready for us”. I on my own idea believe that the best E-voting system can be achieved by following the sample factorization methodology.
In my own factorization methodology, I started from the computer with the following stages.
1. Using Logical & Arithmetic capability of computer, to design software that can store and manipulate the posts and names of contestants. Fore example, In C++:
Struct {
(String names [50];
int each result [50];
} (strings posts[30];
Where each constant can be identified by posts [post name index]. Names [contestant index] also the result of each contestant by posts [post name index]. Each result [contestant index].
2. Choosing the style of voting (i.e. how the user can cast his/her vote). At this stage I split my decision/ choice in to 2.
For example: F1=President cand 1
F1=President cand 2
TO COMPUTER
Another innovation I got from one of the computer society book is the Internet forum rather than Internet chatting. I discovered that each time embark on my research I encountered many misfortune. Some of the common ones are:
1. Stop Producing Code: It is a common action that the researchers would always be engaged in documentation. This documentation could district the attention of a problem solver from producing working code. I quote Victor Skowrounski (Northrop Grumman information Technology) who said “A problem solver who chooses to do research stops producing code. The problem solver could even prevent others from producing codes”. Not until when it’s becoming too long, I would not be encouraged to write any code. The result of which could be disastrous.
2. Interaction with people over the idea: It is discovered that discussing something genuine (innovative) with the common friends even collogues in the school makes them to have new impression either good or bad such as “You are not talking of this generation” or “You better go and sit down, do you think its possible to do such and such”. All these kinds of responses weaken the moral of a problem solver.
3. Demonstration of Prototype Software: The developer demonstrates the prototype software to their customer with the expectation that the customer will provide them with useful feedback. In the case of newly formulated ideas, if the prototype is given to just anybody, with the expectation of useful feedback. Some of them come back to say “Ah! You seriously tried” with no comment. This cannot help in advancement.
All these problems and more are such encountered by an isolated programmer. Victor Skowronski analyzes the solution to many of these problems in his article titled “Do Agile Methods Marginalize problem solvers?”-Computer (Oct. 2004,pg 120).
When I read through the article written by Victor, I took my time to ponder on the way forward. At last, I remember the saying of an innovator in my school Dr. A.C.T. Briggs. Anything I presented my work to him, he will say, “Let’s form a computer club in order that we can bring together deferent ideas to make something genuine. Apart, anybody who is willing and ready to become an innovator but with little knowledge will have an avenue to be informed”. And now I agree with the saying of a wise man.
The characteristics of a good Agile programmer is recorded in a paper “Empirical Finding in Agile Methods” (Proc. Extreme programming and Agile Methods; http://fc-md. umd.edu/mikli/lindvall_agile_unverse_eworkshop.pdf) as follows:
“It is agreed that a certain percentage of experienced people are needed for a successful Agile project.
There was some consensus that 25%-33% of the project personnel must be competent and experienced”. By competent and experience personnel, it was meant that the programmer possesses real-word experience in the technology domain, has built similar systems in the post, and has good people and communication skills.
Currently, many Agile methodologies have become popular. However, all advocate the same principles as follows:
v Individuals and interactions over process and tolls: To implement this principle, the club moves programmers out of their offices and cubicles into open-floodplain offices. This minimizes privacy so that programmers can see and hear what everyone else is doing.
v Working software over comprehensive documentation: The project/club leadership discourages programmers from writing documentation and encourages them to produce software instead.
v Custom collaboration over contract negotiation: Having achieved something, the developers/programmers demonstrate the prototype software to their customers with the expectation of a useful feedback from the customers.
v
Responding to charge –over following a plan: The
developers immediately use the customer feedback to guide development of the
project’s next phase.
Exceptional personnel (Never an
Agile programmer)
Since Agile Method requires the sharing of work, knowledge and what so ever, an Agile programmer should be collaborating rather than quarrelling with Co-workers- a case of Isaac Newton. If Isaac Newton were to be an Agile programmer