Thursday, March 31, 2005

Ok, so in my search of the religion that is right for me, I take this quiz and find that I am a satanist agnostic with Athiestic, Buddhist and Jewish values. As I suspected. Satanist? wait a minute. I dont worship the devil, although I did go to ASU, oh no, Sun Devils. Ah crap, I'm cursed! What to do?

You scored as agnosticism. You are an agnostic. Though it is generally taken that agnostics neither believe nor disbelieve in God, it is possible to be a theist or atheist in addition to an agnostic. Agnostics don't believe it is possible to prove the existence of God (nor lack thereof).

Agnosticism is a philosophy that God's existence cannot be proven. Some say it is possible to be agnostic and follow a religion; however, one cannot be a devout believer if he or she does not truly believe.

agnosticism

92%

Satanism

88%

atheism

63%

Buddhism

42%

Judaism

33%

Islam

33%

Paganism

25%

Christianity

21%

Hinduism

13%

Which religion is the right one for you? (new version)
created with QuizFarm.com

Tuesday, March 22, 2005

I should probably take this again, just to be sure, but until then:

Sunday, March 20, 2005

See if you can find waldo:

http://soccerforadults.com/hotshots02.php

Sunday, March 06, 2005

SAD - Solitary Agile Develop(er|ment)

Part 3

Gather » Iterate » Repeat

This third installation looks at a strategy for gathering and managing the requirements of a project using SAD. If you read the back of any shampoo bottle, you'll see the instructions "Lather, Rinse, Repeat." In case you hadn't already figured it out, that is an effective way to wash your hair. In SAD, I propose a similar strategy, "Gather, Iterate, Repeat" to effectively analyze and implement the requirements of a complex system with vague or unclear requirements.


Gather
With constant feedback from he stakeholders and users, the developer can begin to formalize use cases or user stories. Doing so yields many benefits. First, the stakeholder can help to prioritize the features so the developer knows what they need most. Second, it forces the developer to focus on and contemplate the behavior of the system. Thirdly, the developer is human, and as such can forget or confuse the details. A written record gives the developer a written reference of the requirements for the system.


Iterate
Any agile software development methodology will strongly emphasize the notion of short iterations or cycles of analyzing, designing, implementing and testing your code. XP (The Bob Martin flavor) for example suggests 1 week iterations whereas Scrum and others might suggest 2 to 4 week iterations. In SAD, the actual duration of the iteration is left up to the developer. The only stipulation is that the iteration should be kept short.

Other than that, the iterations consist of analysis, design, testing, implementation, communication (with stakeholders and users) and releases. All of these except Releases are all done at the same time. Analysis is continuously integrated during design. Design is continuously modified during implementation. Implementation is analyzed and refactored after testing. Communication is done throughout to maintain the open nature of Agile development. The last part of the iteration is the release. Which may be as simple as a demo to a client, not necessarily a full production release.

Short iterations allow the lone developer to effectively manage releases, and the more releases the more feedback the developer will get from the stakeholders and users. These iterations can vary, there's no reason to spend one month on an iteration you feel only requires 1 week. Likewise, if an iteration is more complex it may require a full month to complete. However, iterations of more than 5 weeks start to become dangerous and more difficult to manage.
Repeat
Consider the following code:

...
LoneCoder geek = new LoneCoder();
while(1)
{
geek.GatherRequirements();
geek.Iterate();
}
...


Again, open and free communication with stakeholders and users is critical in this entire process. Often times, the customer doesn't really know what they want until they see a working prototype. So I encourage you to show them demos as much as possible, have them look over your user stories or use cases and ask them to rank them on a scale of 1 to 10. Put up a suggestion page on your website, where users can submit their feedback and request new features. After all, they are the ones who will use your software, and they have the most to gain from the features you implement.