| I have created this site to develop the concept of an Agile Hacker. My
vision of an agile hacker is someone who follows a set of principles, which are
designed to maximize their ability to create useful, reliable software.
The software must also be capable of evolving quickly under changing
requirements. The agile hacker will not create discreet applications
which are shipped and forgotten about. All software will be written from
the point of view that it is to be used and extended forever. There are several
ideas which go into making an agile hacker, but it is really about finding what
works for you. In the process of finding what works for you, you will be
exploring what works for others, and contributing to the body of knowledge
which exists on the web. If you have done some reading about Complex
Adaptive Systems, you will have a better idea, about how many independent
agents can lead to some interesting phenomenon. This is nothing new to
the Hacker community. Many of them have contributed to what has emerged
as the phenomenon that we call the "Internet".
I will maintain a list of resources, which I have found to be useful for
learning how to be an agile hacker. The essential resources, will be
listed as primary resources. Over time I will develop a list of
additional resources.Primary Resources:
The idea for this site came to me after reading,
Hacking and Refactoring by Eric S Raymond.
If you know of the term Agile Hacker being used anywhere else please let me
know. If this term has been used by others prior to Aug 29, 2003, I will
consider coming up with a new name.
I am not trying to redefine what a hacker is, but I am trying to extent the
concept. If any of my definitions or recommendations contradict, with how
Hackers see themselves, I am hoping that they will contribute to debugging what
I have to say here.The purpose for the Agile Hacker concept is to have some fun
while learning how to maximizing our ability to write software. The ideas
presented on this page are far from being complete, but will continue to
evolve. Consider this page to be the primordial soup for what is to come
next. Everything on this page is subject to change. In the spirit
of releasing early and often, I will post these half baked ideas. With
more eyes and brains looking at them the debugging will go much more quickly.
Agile Hacking, is an attempt to turn the informal process of hacking into a
formal process, to improve your productivity and enjoyment. The
difference between a typical process and the Agile Hacking process is that each
Agile Hacker has their own personal process. The Agile Hacking process is
whatever works for you. You will be constantly evaluating your own
successes and failures, to obtain information about how to improve your
process.
Whenever you find something that works share it, so others can try it out.
Your personal process for how you get things done and how you focus your
thinking is independent of whatever process is used in your workplace.
Your co-worker have no need to know that you are training you mind, so that you
can move on to bigger and better things. If your co-workers are receptive
to new ideas then share them, otherwise keep them to yourself. The
internet is the place to look for finding others receptive to your ideas.
Don't force your ideas on others, but find appropriate discussion groups.
The Agile and Extreme Programming community are a great bunch of people who are
happy to help out newcomers. Public forums are preferred over sending
your questions directly to the gurus. If your question is something the
guru is interested in they will provide an answer, and others will add their
bit of wisdom. I don't know of any discussion groups where hackers
discuss how to improve their hacking skills. You can find them by
participating in their open source projects. Be wary of groups and
individuals that call themselves hackers, they will often be crackers and other
low life. The trick here is to find people that are smarter and more
knowledgably then you, to hang out with, and avoid annoying them.
After becoming familiar with the ideas in the Primary Resources, the next step
is to start experimenting with applying those ideas to open-source
projects. You can contribute to existing projects, by debugging,
testing, writing test programs, documentation, tutorials, add-ons, and sample
programs. Your contributions can then be posted on your own
website. When appropriate, inform the maintainers of the existing project
about your work by sending them your URL. If you spot a question in a
public forum which can be answered by the content on your website, respond and
give your URL. Contribute more directly to open source projects when
appropriate, by following whatever guidelines are on the project's website.
Any code that you have written which might be useable by others should be posted
to your website. Accept feedback, and use that information to improve
your code. Ignore flames and useless criticism by hitting the delete
button.
Over time I will develop a set of principles to be used as the starting point
for creating your own principles. The reason for listing your principles
is so that you always have a way to judge your own work. Every time you
are about to violate one of your principles, you need to explain to yourself
the reason for this exception. If you find the constant need to violate a
principle, you need to consider refining or discarding that principle.Start with
a set of principles derived from the agile software development and hacker
communities. Here I will list a few that come to mind.
Principles to code by:
-
give away your source code
-
make your code as reusable as possible
-
use test driven development, and refactoring as much as possible
-
include unit tests with your source code
-
release your code early and often
Giving away your source code is an important principle for all aspiring agile
hackers, but one that you often have to set aside. For example if you
don't own the code you can't give it away.
There are several techniques that can be used to improve the reusability of your
code. Keep system, database, and GUI code isolated from the business
logic. The business logic also needs to be made modular. For
example, you are writing a program which uses genetic algorithms to train
neural networks for recognizing features in photographs. To maximize
reusability, you need several independent modules, any of which can be
extracted and reused or replaced without affecting the other modules.
Some modules that come to mind are the GUI, file I/O, genetic algorithm, neural
network, graphics for displaying performance statistics, image processing, and
unit tests. Each of these modules needs to be done as independent
libraries. If there is common code used by 2 or more of these modules it
will exist in additional libraries. Avoid circular dependencies. If your
design requires class B to pass a pointer to class A, so that it can call back
into class B, you have a circular dependency. To break this dependency
create an interface. This way class A can be written without any
knowledge of what class B will look like. Class B would implement the
interface, which enables A to call it.
Test Driven Development and Refactoring are techniques used to help keep your
code in a clean reusable state. If you have used Test Driven Development,
then you will have the unit tests for your code. If you try to add unit
tests after the fact, you will likely be faced with an impossible task, since
you will likely have created un-testable code.
By releasing your code early and often, you will have many other people to
discover bugs that you missed, and come up with things you didn't think
about. Others will gladly contribute their time and knowledge for free,
since you have done the same by giving away your source code.
|